# GitHub フロー

GitHub フローに従って、プロジェクトで共同作業を行います。

## はじめに

GitHub フローは、軽量のブランチ ベースのワークフローです。 GitHub フローは、開発者だけでなくすべてのユーザーに役立ちます。 たとえば、ここ GitHub では、[サイト ポリシー](https://github.com/github/site-policy)、[ドキュメント](https://github.com/github/docs)、[ロードマップ](https://github.com/github/roadmap)に GitHub フローを使用します。

## 前提条件

GitHub フローに従うには、GitHub アカウントとリポジトリが必要です。 アカウントの作成方法については、「[GitHubでのアカウントの作成](/ja/get-started/start-your-journey/creating-an-account-on-github)」を参照してください。リポジトリを作成する方法については、「[リポジトリのクイック スタート](/ja/repositories/creating-and-managing-repositories/quickstart-for-repositories)」を参照してください。コントリビュートする既存のリポジトリを見つける方法については、「[GitHubのopen sourceに貢献する方法を見つける](/ja/get-started/exploring-projects-on-github/finding-ways-to-contribute-to-open-source-on-github)」を参照してください。

## GitHub フローに従う

> \[!TIP]
> GitHub フローの全ての手順は、GitHub Web インターフェイス、コマンド ラインと [GitHub CLI](https://cli.github.com)、または [GitHub Desktop](/ja/desktop) で実行できます。 GitHub に接続するために使用できるツールに関する詳細は。「[GitHubへの接続](/ja/get-started/using-github/connecting-to-github)」を参照してください。

### 分岐を作成する

リポジトリにブランチを作成します。 短くわかりやすいブランチ名を使用すると、コラボレーターは進行中の作業を一目で確認できます。 たとえば、`increase-test-timeout` または `add-code-of-conduct` です。 詳しくは、「[リポジトリ内でブランチを作成および削除する](/ja/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-and-deleting-branches-within-your-repository)」をご覧ください。

ブランチを作成することで、既定のブランチに影響を与えずに作業するスペースを作成します。 さらに、コラボレーターに作業をレビューする機会を与えます。

### 変更を加える

あなたのブランチで、リポジトリに望む変更を加えます。 詳細については、「[新しいファイルの作成](/ja/repositories/working-with-files/managing-files/creating-new-files)」、「[ファイルを編集する](/ja/repositories/working-with-files/managing-files/editing-files)」、「[ファイル名を変更する](/ja/repositories/working-with-files/managing-files/renaming-a-file)」、「[ファイルを新しい場所に移動する](/ja/repositories/working-with-files/managing-files/moving-a-file-to-a-new-location)」、または「[リポジトリのファイルを削除する](/ja/repositories/working-with-files/managing-files/deleting-files-in-a-repository)」を参照してください。

ブランチは、変更を加えるのに安全な場所です。 間違えた場合は、変更を元に戻すか、追加の変更をプッシュして間違いを修正できます。 ブランチをマージするまで、変更は既定のブランチに反映されません。

変更をブランチにコミットしてプッシュします。 コミットに含まれる変更について、自分と今後の共同作成者が理解できるように、各コミットにわかりやすいメッセージを付けます。 たとえば、`fix typo` または `increase rate limit` です。

理想的には、各コミットには分離された完全な変更が含まれます。 これにより、別の方法を使用する場合に変更を簡単に元に戻せます。 たとえば、変数の名前を変更し、いくつかのテストを追加する場合は、変数の名前変更をあるコミットに配置し、テストを別のコミットに配置します。 後でテストを保持し、変数の名前を元に戻す場合は、変数の名前変更を含む特定のコミットを元に戻すことができます。 変数の名前変更とテストを同じコミットに配置したり、変数の名前変更を複数のコミットに分散させたりすると、変更を元に戻す労力が増えます。

変更をコミットしてプッシュすることで、作業をリモート ストレージにバックアップします。 つまり、任意のデバイスから作業にアクセスできます。 また、コラボレーターが作業を確認したり、質問に回答したり、提案や投稿を行ったりすることもできます。

フィードバックを求める準備ができるまで、引き続きブランチに変更を加え、コミットし、プッシュします。

> \[!TIP]
> 一連の関連のない変更ごとに個別のブランチを作成します。 これにより、レビュー担当者がフィードバックを提供しやすくなります。 また、ユーザーと将来のコラボレーターが変更を理解し、変更を元に戻し、変更をさらに加えることもできます。 さらに、ある一連の変更に遅延があっても、他の変更には遅延が発生しません。

### pull request を作成する

変更に関するフィードバックをコラボレーターに依頼する pull request を作成します。 pull request のレビューは非常に重要なため、一部のリポジトリでは、pull request をマージする前に承認レビューが必要になります。 変更を完了する前に早期のフィードバックやアドバイスが必要な場合は、pull request を下書きとして表示できます。 詳しくは、「[pull request の作成](/ja/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request)」をご覧ください。

pull request を 作成する場合は、変更の概要と変更が解決する問題を含めます。 この情報を伝えるために役立つ画像、リンク、テーブルを含めることができます。 pull request が特定の問題に関係している場合、問題へのリンクを設定して、関係者が pull request を認識しやすくします。これにより、関係者が pull request の詳細を確認でき、必要な対処が行えます。 キーワードを使用してリンクを表示すると、pull request がマージされると問題は自動的に終了します。 詳細については、「[基本的な書き込みと書式設定の構文](/ja/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax)」および「[プルリクエストを課題にリンクする](/ja/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue)」を参照してください。

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

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

リポジトリに pull request で実行するように構成されたチェックがある場合は、pull request で失敗したチェックが表示されます。 これにより、ブランチをマージする前にエラーを把握できます。 詳しくは、「[ステータスチェックについて](/ja/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/about-status-checks)」をご覧ください。

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

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

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

### pull request をマージする

pull request が承認されたら、pull request をマージします。 これにより、ブランチが自動的にマージされ、変更が既定のブランチに表示されます。 GitHub は、コメントとコミットの履歴を pull request に保持し、今後の共同作成者が変更を理解できるようにします。 詳しくは、「[pull request のマージ](/ja/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/merging-a-pull-request)」をご覧ください。

GitHub は、pull request にマージ前に解決する必要がある競合があるかどうかを示します。 詳しくは、「[マージ競合への対処](/ja/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts)」をご覧ください。

pull request が特定の要件を満たしていない場合、ブランチ保護設定によってマージがブロックされる可能性があります。 たとえば、特定の数の承認レビューや特定のチームからの承認レビューが必要です。 詳しくは、「[保護されたブランチについて](/ja/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches)」をご覧ください。

### ブランチを削除する

pull request をマージした後、ブランチを削除します。 これは、ブランチでの作業が完了したことを示し、ユーザーや他のユーザーが誤って古いブランチを使用するのを防ぎます。 詳しくは、「[プルリクエスト中のブランチの削除と復元](/ja/repositories/configuring-branches-and-merges-in-your-repository/managing-branches-in-your-repository/deleting-and-restoring-branches-in-a-pull-request)」をご覧ください。

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