このバージョンの GitHub Enterprise はこの日付をもって終了となりました: 2021-09-23. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの改善、新機能のためには、最新バージョンのGitHub Enterpriseにアップグレードしてください。 アップグレードに関する支援については、GitHub Enterprise supportに連絡してください。

ブランチについて

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

ブランチについて

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

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

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

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

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

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

デフォルトでは、GitHub Enterprise Server は新しいリポジトリのデフォルトブランチ master に名前を付けます。

新しいリポジトリのためのデフォルトブランチの名前を設定できます。 詳しい情報については、「リポジトリのデフォルトブランチの管理」、「Organization内のリポジトリのデフォルトブランチ名の管理」、「Enterpriseでのリポジトリ管理ポリシーの強制」を参照してください。

ブランチを使用する

満足の行くところまで作業したら、プルリクエストをオープンして、現在のブランチ(head ブランチ)の変更を別のブランチ(base ブランチ)にマージできます。 詳しい情報についてはプルリクエストについてを参照してください。

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

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

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

[Merge pull request] ボタン

次の図では、feature1 のプルリクエストを master ブランチにマージし、feature1 ブランチを削除しています。 その結果、GitHub は、feature2 のプルリクエストを自動的にリターゲットして、ベースブランチが master になるようにしました。

[Merge pull request] ボタン

これで、feature2 プルリクエストをマージすると、master ブランチにマージされます。

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

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

ノート:リポジトリ管理者は、ブランチの保護で"Include administrators(管理者を含む)"が設定されていなければ、要求を満たしていないプルリクエストを保護が有効化されたブランチにマージできます。

プルリクエストがマージできるかを調べるには、プルリクエストの Conversation(会話)タブの下部にあるマージボックスを見てください。 詳しい情報については保護されたブランチについてを参照してください。

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

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

参考リンク

問題がまだ解決していませんか?