既定のブランチの変更

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

既定のブランチは、新しいクローンで Git によって最初にチェックアウトされるブランチです。 また、pull request でも、既定でこのブランチがターゲットになります。

既定のブランチを変更するプロセスについて説明します。 また、この変更を行うときに考慮し、更新する必要があるその他の事項についても説明します。 最後に、移行を容易にするためのツールを紹介します。

新しい既定のブランチを設定する

main 以外のブランチを新しい変更に使用したり、リポジトリ内のメインの開発ラインを変更したりすることができます。 新しいリポジトリの既定のブランチ名を変更するには、すべてのリポジトリの設定とポリシーに関する記事を参照してください。

リポジトリの既定のブランチを変更して新しい pull request をマージするには、少なくとも 2 つのブランチが必要です。 ブランチが 1 つしかなければ、それが既に既定のブランチです。 既定のブランチを変更するには、2 つ目のブランチを作成する必要があります。

Note

既定のブランチを変更するには、ポリシーの編集アクセス許可が必要です。 詳細については、「Git リポジトリのアクセス許可を設定する」を参照してください。

1. プロジェクト リポジトリで、[ブランチ] を選択します。

2. [ブランチ] ページで、目的の新しい既定のブランチの横にある [その他のオプション] を選択し、[既定のブランチとして設定] を選択します。

   

3. 新しい既定のブランチを設定したら、必要に応じて前の既定のブランチを削除できます。

この変更を行う前に考慮すべきことが他にもあります。

名前を選択する

Git 2.28 で、初期ブランチ名を選択する機能が追加されました。 同時に、Azure Repos、GitHub などの Git ホスティング プロバイダーで、別の初期ブランチ名を選択する機能が追加されました。 以前は、既定のブランチはたいてい master という名前でした。 それに代わる最も一般的な名前は main です。 あまり一般的ではない選択肢として trunk や development があります。 使用するツールや所属するチームで制限がなければ、有効な、どのようなブランチ名も使用できます。

他のシステムを更新する

既定のブランチを別のものに変更すると、ワークフローの他の部分が影響を受ける可能性があります。 変更を計画する場合は、これらの部分を考慮する必要があります。

Pipelines

すべてのパイプラインの CI トリガーを更新します。 デザイナー パイプラインは Web で編集できます。 YAML パイプラインは、それぞれのリポジトリで編集できます。

処理中の pull request

開いている各 pull request のターゲットを新しい既定のブランチに変更します。

既存のクローン

リポジトリの新しいクローンでは、新しい既定のブランチが取得されます。 切り替え後、既存のクローンを持つすべてのユーザーは git remote set-head origin -a を実行し (origin は、別の名前であればそれぞれのリモートの名前に置き換えます)、リモートの既定のブランチのビューを更新する必要があります。 以降の新しいブランチは、新しい既定のブランチに基づくようになります。

受信リンク

Azure Repos 内のファイルを参照するブックマーク、ドキュメント、その他のコード以外のファイルは、更新する必要があります。 ファイルまたはディレクトリのブランチ名が、URL に表示される場合があります。

URL に version のクエリ文字列 (たとえば 、&version=GBmybranchname など) が含まれている場合は、その URL を更新する必要があります。 幸い、既定のブランチへのほとんどのリンクには version セグメントがないため、そのままにすることができます。 また、前の既定のブランチを削除した場合、そこに移動しようとすると、新しい既定のブランチに誘導されます。

一時ミラーリング

Git リポジトリに含めることができる既定のブランチは 1 つだけです。 ただし、しばらくの間は、前の既定のブランチと新しい既定のブランチの間にアドホック ミラーリングを設定できます。 こうすると、エンド ユーザーが引き続き前の既定のブランチにプッシュしても、エンド ユーザー側で作業をやり直す必要がありません。 この一時的なミラーリングを設定するには、Azure Pipelines を使用します。

Note

このセクションには、Microsoft の考え方に合っていない言葉が使用されています。 具体的には、master という言葉が、Git での使用方法と一致する複数の場所に出現します。 このトピックの目的は、main などの、より包括的な言語に切り替える方法を説明することです。 master をすべて使用しないようにすると、手順が理解しにくくなります。

ミラーリング パイプライン

Note

これらの手順は確定的なものではなく、リポジトリのセットアップでは、アクセス許可やポリシーの緩和など、追加の変更が必要になる場合があります。

警告

このパイプラインを実行する前に、前の既定のブランチと新しい既定のブランチの両方が更新された場合、パイプラインで変更をミラーリングできません。 もう一度自動的に実行されるようにするには、前の既定のブランチを新しい既定のブランチに手動でマージする必要があります。

1. 既存のすべての CI ビルドは、前の既定のブランチではなく新しい既定のブランチに対してトリガーするように更新します。

2. ビルド ID に、リポジトリに対する [Contribute] (投稿) アクセス許可を付与します。 [プロジェクトの設定]>[リポジトリ]>(ご自分のリポジトリ)>[アクセス許可] の順に移動します。 最大 2 つの ID (1 つはプロジェクト コレクション ビルド サービス用、もう 1 つはプロジェクト ビルド サービス用) が存在する場合があります。 [Contribute] (投稿) アクセス許可が [許可] になっていることを確認します。

3. 新しい既定のブランチにブランチ ポリシーがある場合は、ビルド ID に [プッシュするときにポリシーをバイパスする] アクセス許可も付与します。 このアクセス許可は、悪意のあるユーザーがパイプラインを作成してプロジェクト内のリポジトリにコードを侵入させるおそれを生じるため、セキュリティ上のリスクになります。 ミラーリングが不要になった場合は、必ずこのアクセス許可を削除してください。

4. 新しいファイルmirror.yml を新しい既定のブランチのリポジトリに追加します。 この例では、前の既定のブランチが master で、新しい既定のブランチが main であると想定しています。 ブランチ名が異なる場合は、トリガー ブランチと git push 行を更新します。

trigger:
  branches:
    include:
    - main
    - master
 
pool: { vmImage: ubuntu-latest }
steps:
- checkout: self
  persistCredentials: true
- script: |
    git checkout $(Build.SourceBranchName)
    git push origin HEAD:master HEAD:main
  displayName: Mirror old and new default branches

5. ウィザードで [Azure Repos Git] と [既存の Azure Pipelines YAML ファイル] を選択して、新しいパイプラインを作成します。 前の手順で追加したmirror.yml ファイルを選択します。 パイプラインを保存し、実行します。

トラブルシューティング

このパイプラインは、master または main へのプッシュが行われるたびに実行されます。 新しいコミットが両方のブランチに同時に到着しない限り、同期は維持されます。

[Updates were rejected because a pushed branch tip is behind its remote] (プッシュされたブランチ チップがリモートの背後にあるため、更新が拒否されました) などのエラー メッセージでパイプラインが失敗し始めた場合、手動で前のブランチを新しいブランチにマージする必要があります。

1. リポジトリと cd をそのディレクトリにクローンします。
2. git checkout main を使用して新しい既定のブランチをチェックアウトします (main が新しい既定のブランチの場合)。
3. git checkout -b integrate を使用して、2 つのブランチを統合するための新しいブランチを作成します。
4. git merge master を使用して前の既定のブランチをマージします (master が前の既定のブランチの場合)。
5. 新しいブランチをプッシュし、新しい既定のブランチへの pull request を開いて完了します。
6. この後、ミラーリング パイプラインの働きで、前の既定のブランチへのマージ コミットのミラーリングが行われます。