ブランチの概要
ブランチを使用すると、リポジトリ内の領域で機能を開発したり、バグを修正したり、新しいアイデアを安全に試したりすることができます。
ブランチは常に既存のものから作成します。 通常、リポジトリのデフォルトブランチから新しいブランチを作成します。 その後、他の人がリポジトリに加えた変更とは別に、新しいブランチで作業できます。 機能を構築するために作成するブランチは、通常、フィーチャブランチまたはトピックブランチと呼ばれます。 詳しくは、「リポジトリ内でブランチを作成および削除する」をご覧ください。
また、GitHub Pagesサイトを公開するためにブランチを使うこともできます。 詳しくは、「GitHub Pages について」をご覧ください。
ブランチの作成、プルリクエストのオープン、プルリクエスト中でのブランチの削除とリストアを行うためには、リポジトリへの書き込みアクセスを持っていなければなりません。 詳しくは、「GitHub 上のアクセス権限」をご覧ください。
デフォルトブランチについて
GitHub でコンテンツを含むリポジトリを作成すると、GitHub Enterprise Cloud によって 1 つのブランチを持つリポジトリが作成されます。 リポジトリ内のこの最初のブランチがデフォルトブランチです。 デフォルトブランチは、誰かがあなたのリポジトリにアクセスしたときに GitHub が表示されるブランチです。 また、デフォルトブランチは、誰かがリポジトリのクローンを作成したときに Git がローカルでチェックアウトする最初のブランチでもあります。 異なるブランチを指定しないかぎり、リポジトリ内のデフォルトブランチが新しいPull Requestやコードコミットのベースブランチになります。
既定では、すべての新しいリポジトリの既定のブランチに、GitHub Enterprise Cloud によっては main
という名前が設定されます。
新しいリポジトリのためのデフォルトブランチの名前を設定できます。 詳しくは、「リポジトリのデフォルトブランチ名を管理する」、「Organization のリポジトリのデフォルブランチ名を管理する」、「Enterprise でリポジトリ管理ポリシーを適用する」をご覧ください。
新しいリポジトリのためのデフォルトブランチの名前を設定できます。 詳しくは、「リポジトリのデフォルトブランチ名を管理する」、「Organization のリポジトリのデフォルブランチ名を管理する」、「Enterprise でリポジトリ管理ポリシーを適用する」をご覧ください。
ブランチを使用する
作業が満足できる状態になったら、pull request を開いて、現在のブランチ (ヘッド ブランチ) の変更を別のブランチ (ベース ブランチ) にマージできます。 詳しくは、「pull requests について」をご覧ください。
プルリクエストがマージまたはクローズされた後、head ブランチは不要になり削除できます。 ブランチを削除するには、リポジトリへの書き込みアクセスが必要です。 オープンなプルリクエストに直接関連付けられているブランチは削除できません。 詳しくは、「pull request 中のブランチの削除と復元」をご覧ください。
プルリクエストがマージされた後にheadブランチを削除すると、GitHubは同じリポジトリ内に削除されたブランチをベースブランチと指定しているオープンなプルリクエストがないかをチェックします。 GitHubはそういったプルリクエストを自動的に更新し、ベースブランチをマージされたプルリクエストのベースブランチに変更します。次の図は、これを示したものです。
ここでは、他のユーザーが main
ブランチから feature1
という名前のブランチを作成しており、自分は feature1
から feature2
という名前のブランチを作成しました。 両方のブランチにオープンなプルリクエストがあります。 矢印は、各プルリクエストの現在のベースブランチを示します。 この時点で、feature1
は feature2
のベース ブランチになります。 ここで feature2
に対する pull request がマージされた場合、feature2
ブランチは feature1
にマージされます。
次の図では、他のユーザーが feature1
に対する pull request を main
ブランチにマージし、feature1
ブランチを削除しました。 その結果、feature2
に対する pull request は GitHub によって自動的にターゲット変更されて、ベース ブランチが main
になります。
ここで feature2
の pull request をマージすると、main
ブランチにマージされます。
保護されたブランチでの作業
リポジトリ管理者または "リポジトリ ルールの編集" アクセス許可を持つカスタム ロールは、ブランチで保護を有効にすることができます。 保護されたブランチで作業しているなら、ブランチを削除したり、ブランチにフォースプッシュしたりすることはできません。 リポジトリ管理者は、保護されたブランチの他の設定を有効化し、ブランチがマージできるようになる前に様々なワークフローを適用できます。
Note
ブランチ保護が [Include administrators] に設定されていない場合、リポジトリ管理者は、pull request が要件を満たしていなくても、ブランチ保護が有効になっているブランチに pull request をマージできます。
Pull request をマージできるかどうかを調べるには、pull request の [Conversation] タブの下部にあるマージ ボックスを確認します。詳しくは、「保護されたブランチについて」をご覧ください。
ブランチが保護されていると、以下のようになります。
- ブランチの削除やブランチへのフォースプッシュはできません。
- ブランチでステータスチェック必須が有効化されていると、必要なCIテストがすべてパスするまで、変更をブランチにマージできません。 詳しくは、「ステータスチェックについて」をご覧ください。
- ブランチでプルリクエストレビュー必須が有効化されている場合、プルリクエストレビューポリシー中のすべての要求が満たされるまでは、ブランチに変更をマージできません。 詳しくは、「pull request のマージ」をご覧ください。
- ブランチでコードオーナーからの必須レビューが有効化されており、プルリクエストがオーナーを持つコードを変更している場合、コードオーナーがプルリクエストを承認しなければ、そのプルリクエストはマージできません。 詳しくは、「コードオーナーについて」をご覧ください。
- ブランチでコミット署名必須が有効化されている場合、署名および検証されていないコミットはブランチにプッシュできません。 詳細については、「コミット署名の検証について」および「保護されたブランチについて」を参照してください。
- GitHub のコンフリクトエディタを使用して、保護されたブランチから作成したプルリクエストのコンフリクトを修正する場合、GitHub はプルリクエストの代替ブランチを作成して、コンフリクトの解決をマージできるようにします。 詳しくは、「GitHub でのマージ コンフリクトを解決する」をご覧ください。
参考資料
- pull requests について
- GitHub 用語集の「GitHub 用語集」
- Git ドキュメントの「Branches in a Nutshell」(ブランチの要点)