テスト - ブランチについて - テスト

公開のテスト 12/16

ブランチを使用して、リポジトリ内の他のブランチに影響を与えずに開発作業を分離します。 各リポジトリには 1 つの既定のブランチがあり、他の複数のブランチを持つことができます。 プル要求を使用して、ブランチを別のブランチにマージできます。  

ブランチについて

ブランチを使用すると、機能の開発、バグの修正、リポジトリの包含領域での新しいアイデアの安全な実験を行えます。 

既存のブランチから常にブランチを作成します。 通常、リポジトリの既定のブランチから新しいブランチを作成できます。 その後、他のユーザーがリポジトリに加える変更から分離して、この新しいブランチで作業できます。 機能を構築するために作成するブランチは、通常、機能ブランチまたはトピック ブランチと呼ばれます。 詳細については、「リポジトリ内でのブランチの作成と削除」を参照してください。

ブランチを使用して、GitHub Pages サイトを発行することもできます。 詳細については、「GitHub Pagesについて」を参照してください。

リポジトリへの書き込みアクセス権を持って、ブランチを作成するか、プル要求を開くか、プル要求でブランチを削除および復元する必要があります。 詳細については、「GitHub でのアクセス許可」を参照してください。

既定のブランチについて

GitHub でコンテンツを含むリポジトリを作成すると、GitHub によって 1 つのブランチでリポジトリが作成されます。 リポジトリ内のこの最初のブランチは、既定のブランチです。 既定のブランチは、誰かがリポジトリにアクセスしたときに GitHub に表示されるブランチです。 既定のブランチは、誰かがリポジトリを複製するときに Git がローカルでチェックアウトする初期ブランチでもあります。 別のブランチを指定しない限り、リポジトリ内の既定のブランチは、新しいプル要求とコードコミットのベース ブランチです。

既定では、GitHub は新しいリポジトリ内の既定のブランチメインに名前を付けます。 

既存のリポジトリの既定のブランチを変更できます。 詳細については、「既定のブランチの変更」を参照してください。

新しいリポジトリの既定のブランチの名前を設定できます。 詳細については、「リポジトリの既定のブランチの管理」、「organization内のリポジトリの既定のブランチ名の管理」、「Enterprise アカウントでのリポジトリ管理ポリシーの適用」を参照してください。

ブランチの操作

作業に満足したら、pull request を開いて、現在のブランチ (ヘッド ブランチ) の変更を別のブランチ (ベース ブランチ) にマージできます。 詳細については、「pull request について」を参照してください。"

プル要求がマージされた後、または閉じられた後は、不要になったhead ブランチを削除できます。 ブランチを削除するには、リポジトリに書き込みアクセス権が必要です。 開いているプル要求に直接関連付けられているブランチは削除できません。 詳細については、「プル要求でのブランチの削除と復元」を参照してください。

プル要求がマージされた後にhead ブランチを削除した場合、GitHub は、削除されたブランチをベース ブランチとして指定する、同じリポジトリ内の開いているプル要求をチェックします。 GitHub は、このようなプル要求を自動的に更新し、そのベース ブランチをマージされたプル要求のベース ブランチに変更します。 次の図は、これを示しています。

ここで、誰かがメインブランチから feature1 というブランチを作成し、feature1 から feature2 というブランチを作成しました。 両方のブランチに対してオープンプル要求があります。 矢印は、各プル要求の現在のベース ブランチを示します。 この時点で、feature1 は feature2 のベース ブランチです。 feature2 のプル要求がマージされると、feature2 ブランチが feature1 にマージされます。

次の図では、誰かが feature1 のプル要求をマスター ブランチにマージし、feature1 ブランチを削除しました。 その結果、GitHub は feature2 の pull request を自動的に再ターゲットし、ベース ブランチがマスターになるようにしました。

feature2 pull request をマージすると、メイン ブランチにマージされます。

保護されたブランチの操作

リポジトリ管理者は、ブランチで保護を有効にすることができます。 保護されているブランチで作業している場合、ブランチを削除したり、ブランチにフォース プッシュしたりすることはできません。 リポジトリ管理者は、ブランチをマージする前に、他のいくつかの保護されたブランチ設定を有効にして、さまざまなワークフローを適用することもできます。

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

ブランチが保護されている場合:

• ブランチを削除したり、ブランチにフォース プッシュしたりすることはできません。

• ブランチで必要なステータス チェックが有効になっている場合、必要なすべての CI テストが成功するまで、変更をブランチにマージすることはできません。 詳細については、「ステータス チェックについて」を参照してください。

• ブランチで必要なプルリクエストレビューが有効になっている場合、プルリクエストレビューポリシーのすべての要件が満たされるまで、ブランチに変更をマージすることはできません。 詳細については、「プル要求のマージ」を参照してください。

• ブランチでコード所有者からの必要なレビューが有効になっていて、プル要求によって所有者を持つコードが変更された場合、コード所有者はプル要求をマージする前に承認する必要があります。 詳細については、「コード所有者について」を参照してください。

• ブランチで必要なコミット署名が有効になっている場合、署名および検証されていないブランチにコミットをプッシュすることはできません。 詳細については、「コミット署名の検証について」および「保護されたブランチについて」を参照してください。

• GitHub の競合エディターを使用して、保護されたブランチから作成したプル要求の競合を修正する場合、GitHub は、競合の解決をマージできるように、プル要求の代替ブランチを作成するのに役立ちます。 詳細については、「GitHub でのマージの競合の解決」を参照してください。

その他の読み取り

"pull request について"

GitHub 用語集の "Branch"

Git ドキュメントの "Nutshell 内のブランチ"