ブランチの概要

ブランチの概要

ブランチを使用すると、リポジトリ内の領域で機能を開発したり、バグを修正したり、新しいアイデアを安全に試したりすることができます。

ブランチは常に既存のものから作成します。 通常、リポジトリのデフォルトブランチから新しいブランチを作成します。 その後、他の人がリポジトリに加えた変更とは別に、新しいブランチで作業できます。 機能を構築するために作成するブランチは、通常、フィーチャブランチまたはトピックブランチと呼ばれます。 詳しくは、「リポジトリ内でブランチを作成および削除する」を参照してください。

また、GitHub Pagesサイトを公開するためにブランチを使うこともできます。 詳しくは、「GitHub Pages について」を参照してください。

ブランチの作成、プルリクエストのオープン、プルリクエスト中でのブランチの削除とリストアを行うためには、リポジトリへの書き込みアクセスを持っていなければなりません。 詳しくは、「GitHub 上のアクセス権限」を参照してください。

デフォルトブランチについて

GitHub でコンテンツを含むリポジトリを作成すると、GitHub Enterprise Server によって 1 つのブランチを持つリポジトリが作成されます。 リポジトリ内のこの最初のブランチがデフォルトブランチです。 デフォルトブランチは、誰かがあなたのリポジトリにアクセスしたときに GitHub が表示されるブランチです。 また、デフォルトブランチは、誰かがリポジトリのクローンを作成したときに Git がローカルでチェックアウトする最初のブランチでもあります。 異なるブランチを指定しないかぎり、リポジトリ内のデフォルトブランチが新しいPull Requestやコードコミットのベースブランチになります。

既定では、すべての新しいリポジトリの既定のブランチに、GitHub Enterprise Server によっては 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 ブランチにマージされます。

保護されたブランチでの作業

リポジトリ管理者または "リポジトリ ルールの編集" アクセス許可を持つカスタム ロールは、ブランチで保護を有効にすることができます。 保護されたブランチで作業しているなら、ブランチを削除したり、ブランチにフォースプッシュしたりすることはできません。 リポジトリ管理者は、保護されたブランチの他の設定を有効化し、ブランチがマージできるようになる前に様々なワークフローを適用できます。

pull request をマージできるかどうかを確認するには、pull request の [会話] タブの下部にあるマージ ボックスを確認します。詳細については、「保護されたブランチについて」を参照してください。

ブランチが保護されていると、以下のようになります。

• ブランチの削除やブランチへのフォースプッシュはできません。
• ブランチでステータスチェック必須が有効化されていると、必要なCIテストがすべてパスするまで、変更をブランチにマージできません。 詳しくは、「ステータスチェックについて」を参照してください。
• ブランチでプルリクエストレビュー必須が有効化されている場合、プルリクエストレビューポリシー中のすべての要求が満たされるまでは、ブランチに変更をマージできません。 詳しくは、「pull request のマージ」を参照してください。
• ブランチでコードオーナーからの必須レビューが有効化されており、プルリクエストがオーナーを持つコードを変更している場合、コードオーナーがプルリクエストを承認しなければ、そのプルリクエストはマージできません。 詳しくは、「コードオーナーについて」を参照してください。
• ブランチでコミット署名必須が有効化されている場合、署名および検証されていないコミットはブランチにプッシュできません。 詳細については、「コミット署名の検証について」および「保護されたブランチについて」を参照してください。
• GitHub のコンフリクトエディタを使用して、保護されたブランチから作成したプルリクエストのコンフリクトを修正する場合、GitHub はプルリクエストの代替ブランチを作成して、コンフリクトの解決をマージできるようにします。 詳しくは、「GitHub でのマージ コンフリクトを解決する」を参照してください。

参考資料

• pull requests について
• GitHub 用語集の「GitHub 用語集」
• Git ドキュメントの "Nutshell でのブランチ"