Skip to main content
We publish frequent updates to our documentation, and translation of this page may still be in progress. For the most current information, please visit the English documentation.

ブランチの概要

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

ブランチの概要

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

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

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

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

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

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

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

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

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

ブランチを使用する

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

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

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

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

merge-pull-request-button

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

merge-pull-request-button

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

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

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

注: リポジトリ管理者は、ブランチの保護で [管理者を含める] が設定されていなければ、要件を満たしていない pull request であっても、ブランチの保護が有効になっているブランチにマージできます。

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

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

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

参考資料