はじめに
GitHub フローは、軽量のブランチ ベースのワークフローです。 GitHub フローは、開発者� けでなくすべてのユーザーに役立ちます。 たとえば、ここ GitHub では、サイト ポリシー、ドキュメント、ロードマップに GitHub フローを使用します。
前提条件
GitHub フローに従うには、GitHub アカウントとリポジトリが必要です。 アカウントを作成する方法については、「GitHub へのサインアップ」を参照してく� さい。 リポジトリを作成する方法については、「リポジトリの作成」を参照してく� さい。
GitHub フローに従う
ヒント: GitHub フローのすべての手� �は、GitHub Web インターフェイスか、コマンド ラインと GitHub CLI を介して実行できます。
分岐を作成する
リポジトリにブランチを作成します。 短くわかりやすいブランチ名を使用すると、コラボレーターは進行中の作業を一目で確認できます。 たとえば、increase-test-timeout または add-code-of-conduct です。 詳細については、「リポジトリ内でブランチを作成および削除する」を参照してく� さい。
ブランチを作成することで、既定のブランチに影響を与えずに作業するスペースを作成します。 さらに、コラボレーターに作業をレビューする機会を与えます。
変更を� える
ブランチで、リポジトリに必要な変更を� えます。 詳細については、「新しいファイルの作成」、「ファイルの編集」、「ファイルの名前変更」、「新しい� �所へのファイルの移動」、「リポジトリ内のファイルの削除」を参照してく� さい。
ブランチは、変更を� えるのに安全な� �所です。 間違えた� �合は、変更を元に戻すか、追� の変更をプッシュして間違いを修正できます。 ブランチをマージするまで、変更は既定のブランチに反� されません。
変更をブランチにコミットしてプッシュします。 コミットに含まれる変更について、自分と今後の共同作成者が理解できるように、各コミットにわかりやすいメッセージを付けます。 たとえば、fix typo または increase rate limit です。
理想的には、各コミットには分離された完全な変更が含まれます。 これにより、別の方法を使用する� �合に変更を簡単に元に戻せます。 たとえば、変数の名前を変更し、いくつかのテストを追� する� �合は、変数の名前変更をあるコミットに配置し、テストを別のコミットに配置します。 後でテストを保持し、変数の名前を元に戻す� �合は、変数の名前変更を含む特定のコミットを元に戻すことができます。 変数の名前変更とテストを同じコミットに配置したり、変数の名前変更を複数のコミットに分散させたりすると、変更を元に戻す労力が増えます。
変更をコミットしてプッシュすることで、作業をリモート ストレージにバックアップします。 つまり、任意のデバイスから作業にアクセスできます。 また、コラボレーターが作業を確認したり、質問に回答したり、提案や投稿を行ったりすることもできます。
フィードバックを求める準備ができるまで、引き続きブランチに変更を� え、コミットし、プッシュします。
ヒント： 一連の関連のない変更ごとに個別のブランチを作成します。 これにより、レビュー担当者がフィードバックを提供しやすくなります。 また、ユーザーと将来のコラボレーターが変更を理解し、変更を元に戻し、変更をさらに� えることもできます。 さらに、ある一連の変更に遅延があっても、他の変更には遅延が発生しません。
pull request を作成する
変更に関するフィードバックをコラボレーターに依� �する pull request を作成します。 pull request のレビューは非常に重要なため、一部のリポジトリでは、pull request をマージする前に承認レビューが必要になります。 変更を完了する前に早期のフィードバックやアドバイスが必要な� �合は、pull request を下書きとして表示できます。 詳細については、「プルリクエストの作成方法」を参照してく� さい。
pull request を作成する� �合は、変更の概要と変更が解決する問題を含めます。 この情� �を伝えるために役立つ画像、リンク、テーブルを含めることができます。 pull request が問題に対応するは、問題へのリンクを表示し、問題の関係者が pull request を認識できるようにします。また、このリンクを表示することで、pull request への問題の対応ができるようになります。 キーワードを使用してリンクを表示すると、pull request がマージされると問題は自動的に終了します。 詳細については、「基本的な書き込みと書式の構文」および「pull request を問題にリンクする」を参照してく� さい。
pull request の本文を入力する� けでなく、pull request の特定の行にコメントを追� して、レビュー担当者に何かを明示的に指摘することができます。
pull request の作成時に特定のチー� またはユーザーからレビューを自動的に要求するようにリポジトリを構成できます。 手動で @mention を入力し、特定のユーザーまたはチー� に対してレビューを要求することもできます。
リポジトリに pull request で実行するように構成されたチェックがある� �合は、pull request で失敗したチェックが表示されます。 これにより、ブランチをマージする前にエラーを把握できます。 詳細については、「ステータスチェックについて」を参照してく� さい。
レビュー コメントに対応する
レビュー担当者は質問、コメント、提案を残す必要があります。 レビュー担当者は、pull request 全体にコメントしたり、特定の行にコメントを追� したりできます。 ユーザーとレビュー担当者は画像やコード提案を挿入して、コメントを明確にすることができます。 詳細については、「pull request での変更のレビュー」を参照してく� さい。
レビューに応じて、引き続き変更をコミットしプッシュすることができます。 プルリクエストは自動的に更新されます。
pull request をマージする
pull request が承認されたら、pull request をマージします。 これにより、ブランチが自動的にマージされ、変更が既定のブランチに表示されます。 GitHub は、コメントとコミットの履歴を pull request に保持し、今後の共同作成者が変更を理解できるようにします。 詳細については、「プル リクエストをマージする」を参照してく� さい。
GitHub は、pull request にマージ前に解決する必要がある競合があるかどうかを示します。 詳細については、「マージ コンフリクトに対処する」を参照してく� さい。
pull request が特定の要件を満たしていない� �合、ブランチ保護設定によってマージがブロックされる可能性があります。 たとえば、特定の数の承認レビューや特定のチー� からの承認レビューが必要です。 詳細については、「保護されたブランチについて」を参照してく� さい。
ブランチを削除する
pull request をマージした後、ブランチを削除します。 これは、ブランチでの作業が完了したことを示し、ユーザーや他のユーザーが誤って古いブランチを使用するのを防ぎます。 詳細については、「pull request 内のブランチの削除と復元」を参照してく� さい。
情� �が失われる心配はありません。 pull request とコミットの履歴は削除されません。 必要に応じて、いつでも削除したブランチを復元し、pull request を元に戻すことができます。