Skip to main content

このバージョンの GitHub Enterprise はこの日付をもって終了となります: 2022-10-12. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの向上、新機能の向上を図るために、最新バージョンの GitHub Enterprise にアップグレードします。 アップグレードに関するヘルプについては、GitHub Enterprise サポートにお問い合わせください

GitHub フロー

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

はじめに

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 を問題にリンクする」を参照してください。

pul 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 を元に戻すことができます。