ブランチの概要
ブランチを使用すると、リポジトリ内の� �域で機能を開発したり、バグを修正したり、新しいアイデアを安全に試したりすることができます。
ブランチは常に既存のものから作成します。 通常、リポジトリのデフォルトブランチから新しいブランチを作成します。 その後、他の人がリポジトリに� えた変更とは別に、新しいブランチで作業できます。 機能を構築するために作成するブランチは、通常、フィーチャブランチまたはトピックブランチと呼ばれます。 詳細については、「リポジトリ内でブランチを作成および削除する」を参照してく� さい。
また、GitHub Pagesサイトを公開するためにブランチを使うこともできます。 詳細については、「GitHub Pages について」を参照してく� さい。
ブランチの作成、プルリクエストのオープン、プルリクエスト中でのブランチの削除とリストアを行うためには、リポジトリへの書き込みアクセスを持っていなければなりません。 詳細については、「GitHub 上のアクセス権限」を参照してく� さい。
デフォルトブランチについて
上でコンテンツを持つリポジトリを作成すると、GitHub Enterprise Serverは1つのブランチを持つリポジトリを作成します。 リポジトリ内のこの最初のブランチがデフォルトブランチです。 デフォルトブランチは、誰かがあなたのリポジトリにアクセスしたときに GitHub が表示されるブランチです。 また、デフォルトブランチは、誰かがリポジトリのクローンを作成したときに Git がローカルでチェックアウトする最初のブランチでもあります。 異なるブランチを指定しないかぎり、リポジトリ内のデフォルトブランチが新しいPull Requestやコードコミットのベースブランチになります。
既定では、すべての新しいリポジトリの既定のブランチに、GitHub Enterprise Server によっては main
という名前が設定されます。
新しいリポジトリのためのデフォルトブランチの名前を設定できます。 詳細については、「リポジトリの既定のブランチを管理する」、「組織のリポジトリの既定のブランチ名を管理する」、「Enterprise でリポジトリ管理ポリシーを適用する」を参照してく� さい。
新しいリポジトリのためのデフォルトブランチの名前を設定できます。 詳細については、「リポジトリの既定のブランチを管理する」、「組織のリポジトリの既定のブランチ名を管理する」、「Enterprise でリポジトリ管理ポリシーを適用する」を参照してく� さい。
ブランチを使用する
作業が満足できる状態になったら、pull request を開いて、現在のブランチ (ヘッド ブランチ) の変更を別のブランチ (ベース ブランチ) にマージできます。 詳細については、「pull request について」を参照してく� さい。
プルリクエストがマージまたはクローズされた後、head ブランチは不要になり削除できます。 ブランチを削除するには、リポジトリへの書き込みアクセスが必要です。 オープンなプルリクエストに直接関連付けられているブランチは削除できません。 詳細については、「プル リクエスト中のブランチの削除と復元」を参照してく� さい。
プルリクエストがマージされた後に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 をマージできるかどうかを確認するには、pull request の [会話] タブの下部にあるマージ ボックスを確認します。詳細については、「保護されたブランチについて」を参照してく� さい。
ブランチが保護されていると、以下のようになります。
- ブランチの削除やブランチへのフォースプッシュはできません。
- ブランチでステータスチェック必� �が有効化されていると、必要なCIテストがすべてパスするまで、変更をブランチにマージできません。 詳細については、「ステータスチェックについて」を参照してく� さい。
- ブランチでプルリクエストレビュー必� �が有効化されている� �合、プルリクエストレビューポリシー中のすべての要求が満たされるまでは、ブランチに変更をマージできません。 詳細については、「プル リクエストをマージする」を参照してく� さい。
- ブランチでコードオーナーからの必� �レビューが有効化されており、プルリクエストがオーナーを持つコードを変更している� �合、コードオーナーがプルリクエストを承認しなければ、そのプルリクエストはマージできません。 詳細については、「コードオーナーについて」を参照してく� さい。
- ブランチでコミット署名必� �が有効化されている� �合、署名および検証されていないコミットはブランチにプッシュできません。 詳細については、「コミット署名の検証について」および「保護されたブランチについて」を参照してく� さい。
- GitHub のコンフリクトエディタを使用して、保護されたブランチから作成したプルリクエストのコンフリクトを修正する� �合、GitHub はプルリクエストの代替ブランチを作成して、コンフリクトの解決をマージできるようにします。 詳細については、「 GitHub でのマージ コンフリクトを解決する」を参照してく� さい。
参考資料
- "プル リクエストについて"
- GitHub 用語集の "ブランチ"
- Git ドキュメントの "Nutshell でのブランチ"