GitHub フロー

はじめに

GitHub フローは、軽量のブランチ ベースのワークフローです。 GitHub フローは、開発者だけでなくすべてのユーザーに役立ちます。 たとえば、ここ GitHub では、サイト ポリシー、ドキュメント、ロードマップに GitHub フローを使用します。

前提条件

GitHub フローに従うには、GitHub アカウントとリポジトリが必要です。 アカウントの作成方法については、「GitHub でのアカウントの作成」を参照してください。リポジトリを作成する方法については、「リポジトリのクイック スタート」を参照してください。コントリビュートする既存のリポジトリを見つける方法については、「GitHub でオープンソースにコントリビュートする方法を見つける」を参照してください。

GitHub フローに従う

分岐を作成する

リポジトリにブランチを作成します。 短くわかりやすいブランチ名を使用すると、コラボレーターは進行中の作業を一目で確認できます。 たとえば、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をIssueにリンクする」を参照してください。

pull request の本文を入力するだけでなく、pull request の特定の行にコメントを追加して、レビュー担当者に何かを明示的に指摘することができます。

pull request の作成時に特定のチームまたはユーザーからレビューを自動的に要求するようにリポジトリを構成できます。 手動で @mention を入力し、特定のユーザーまたはチームに対してレビューを要求することもできます。

リポジトリに pull request で実行するように構成されたチェックがある場合は、pull request で失敗したチェックが表示されます。 これにより、ブランチをマージする前にエラーを把握できます。 詳しくは、「ステータスチェックについて」を参照してください。

レビュー コメントに対応する

レビュー担当者は質問、コメント、提案を残す必要があります。 レビュー担当者は、pull request 全体にコメントしたり、特定の行またはファイルにコメントを追加したりすることができます。 ユーザーとレビュー担当者は画像やコード提案を挿入して、コメントを明確にすることができます。 詳しくは、「pull request での変更をレビューする」を参照してください。

レビューに応じて、引き続き変更をコミットしプッシュすることができます。 pull request は自動的に更新されます。

pull request をマージする

pull request が承認されたら、pull request をマージします。 これにより、ブランチが自動的にマージされ、変更が既定のブランチに表示されます。 GitHub は、コメントとコミットの履歴を pull request に保持し、今後の共同作成者が変更を理解できるようにします。 詳しくは、「pull request のマージ」を参照してください。

GitHub は、pull request にマージ前に解決する必要がある競合があるかどうかを示します。 詳しくは、「マージ競合への対処」を参照してください。

pull request が特定の要件を満たしていない場合、ブランチ保護設定によってマージがブロックされる可能性があります。 たとえば、特定の数の承認レビューや特定のチームからの承認レビューが必要です。 詳しくは、「保護されたブランチについて」を参照してください。

ブランチを削除する

pull request をマージした後、ブランチを削除します。 これは、ブランチでの作業が完了したことを示し、ユーザーや他のユーザーが誤って古いブランチを使用するのを防ぎます。 詳しくは、「pull request 中のブランチの削除と復元」を参照してください。

情報が失われる心配はありません。 pull request とコミットの履歴は削除されません。 必要に応じて、いつでも削除したブランチを復元し、pull request を元に戻すことができます。