Skip to main content

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

ブランチの概要

開発作業をリポジトリ内の他のブランチに影響することなく分離するために、ブランチを使ってください。 各リポジトリには1つのデフォルトブランチがあり、複数の他のブランチを持つことができます。 プルリクエストを使えば、ブランチを他のブランチにマージできます。

ブランチの概要

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

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

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

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

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

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

既定では、すべての新しいリポジトリの既定のブランチに、GitHub によって main という名前が設定されます。

既存のリポジトリのデフォルトブランチを変更できます。 詳しくは、「デフォルトブランチを変更する」をご覧ください。

新しいリポジトリのためのデフォルトブランチの名前を設定できます。 詳細については、「リポジトリのデフォルトブランチ名を管理する」、「組織のリポジトリのデフォルトブランチ名を管理する」、「Enterprise でリポジトリ管理ポリシーを適用する」を参照してください。

ブランチを使用する

作業が満足できる状態になったら、pull request を開いて、現在のブランチ (ヘッド ブランチ) の変更を別のブランチ (ベース ブランチ) にマージできます。 詳しくは、「pull requests について」をご覧ください。

プルリクエストがマージまたはクローズされた後、head ブランチは不要になり削除できます。 ブランチを削除するには、リポジトリへの書き込みアクセスが必要です。 オープンなプルリクエストに直接関連付けられているブランチは削除できません。 詳しくは、「プルリクエスト中のブランチの削除と復元」をご覧ください。

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

ここでは、他のユーザーが feature1 ブランチから main という名前のブランチを作成しており、自分は feature2 から feature1 という名前のブランチを作成しました。 両方のブランチにオープンなプルリクエストがあります。 矢印は、各プルリクエストの現在のベースブランチを示します。 この時点で、feature1 は feature2 のベース ブランチになります。 ここで feature2 に対する pull request がマージされた場合、feature2 ブランチは feature1 にマージされます。

main をターゲットとする pull request を含む feature1 ブランチと、feature1 をターゲットとする pull request を含む feature2 ブランチを示す図。

次の図では、他のユーザーが feature1 に対する pull request を main ブランチにマージし、feature1 ブランチを削除しました。 その結果、feature2 に対する pull request は GitHub によって自動的にターゲット変更されて、ベース ブランチが main になります。

main をターゲットとする pull request を含む feature1 ブランチと feature2 ブランチの両方を示す図。

ここで feature2 の pull request をマージすると、main ブランチにマージされます。

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

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

メモ

ブランチ保護が [Include administrators] に設定されていない場合、リポジトリ管理者は、pull request が要件を満たしていなくても、ブランチ保護が有効になっているブランチに pull request をマージできます。

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

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

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

参考資料