既定のブランチの変更

Azure DevOps Services |Azure DevOps Server |Azure DevOps Server 2022 |Azure DevOps Server 2020

既定のブランチは、Git が新しいクローンでチェックアウトする最初のブランチです。また、 pull requests は既定でこのブランチを対象とします。

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

[前提条件]

カテゴリ	Requirements
プロジェクトへのアクセス権	プロジェクトのメンバー。
アクセス許可	- プライベートプロジェクトのコードを表示する: 少なくとも Basic アクセス。 - プライベートプロジェクトのコードを複製または投稿する: 共同作成者セキュリティグループのメンバー、またはプロジェクト内の対応するアクセス許可。 - ブランチまたはリポジトリのアクセス許可を設定する: ブランチまたはリポジトリのアクセス許可を管理します。 - 既定のブランチを変更する: リポジトリのポリシーのアクセス許可を編集します。 - リポジトリをインポートする: プロジェクト管理者セキュリティグループのメンバーまたは Git プロジェクトレベルの [リポジトリの作成 ] アクセス許可が [許可] に設定されています。詳細については、「Git リポジトリのアクセス許可を設定する」を参照してください。
サービス	リポジトリが有効になっています。
ツール	Optional. az repos コマンドを使用する: Azure DevOps CLI。

注

パブリックプロジェクトでは、 利害関係者 アクセス権を持つユーザーは、コードの表示、複製、投稿など、Azure Repos へのフルアクセス権を持ちます。

カテゴリ	Requirements
プロジェクトへのアクセス権	プロジェクトのメンバー。
アクセス許可	- コードの表示: 少なくとも基本アクセス。 - コードの複製または投稿: 共同作成者セキュリティグループのメンバー、またはプロジェクト内の対応するアクセス許可。
サービス	リポジトリが有効になっています。

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

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

新しいプル要求をマージするためにリポジトリの既定のブランチを変更するには、少なくとも 2 つのブランチが必要です。ブランチが 1 つしかない場合は、既に既定値です。既定値を変更するには、2 番目の分岐を作成する必要があります。

注

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

プロジェクトリポジトリで、[ブランチ] を選択します。
[ブランチ] ページで、目的の新しい既定のブランチの横にある [その他のオプション ] を選択し、[既定の ブランチとして設定] を選択します。
新しい既定のブランチを設定した後、必要に応じて前の既定値を削除できます。

この変更を行う前に考慮する必要があるその他の側面があります。

名前を選択する

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

他のシステムを更新する

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

Pipelines

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

インフライトプル要求

開いている各プル要求を新しい既定のブランチに再ターゲットします。

既存の複製

リポジトリの新しいクローンは、新しい既定のブランチを取得します。スイッチの後、既存の複製を持つすべてのユーザーが git remote set-head origin -a 実行して ( origin をリモートの名前に置き換える (別の場合はリモートの名前に置き換える)、リモートの既定のブランチのビューを更新する必要があります。今後の新しいブランチは、新しい既定値に基づく必要があります。

受信リンク

Azure Repos 内のファイルを指す一部のブックマーク、ドキュメント、およびその他のコード以外のファイルを更新する必要があります。ファイルまたはディレクトリのブランチ名は、URL に表示できます。

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

一時的なミラーリング

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

注

このセクションでは、Microsoft の視点と相反する言語を使用します。具体的には、 master という単語は、Git での使用方法と一致するいくつかの場所に表示されます。このトピックの目的は、 mainなど、より包括的な言語に切り替える方法について説明することです。 masterのすべての言及を避けると、方向を理解するのがはるかに困難になります。

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

注

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

Warnung

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

既存のすべての CI ビルドについて、古いブランチではなく新しい既定のブランチに対してトリガーするように更新します。
ビルド ID にリポジトリへの投稿アクセス許可を付与します。 プロジェクト設定>Repositories>(リポジトリ)>Permissions に移動します。最大 2 つの ID が存在する場合があります。1 つはプロジェクトコレクションビルドサービス用、もう 1 つはプロジェクトビルドサービス用です。 [投稿] アクセス許可に [許可] が表示されていることを確認します。

新しい既定のブランチにブランチポリシーがある場合は、アクセス許可を プッシュするときにバイパスポリシー をビルド ID にも付与します。悪意のあるユーザーがパイプラインを作成してプロジェクトのリポジトリにコードを侵入させる可能性があるため、このアクセス許可はセキュリティ上のリスクです。ミラーリングが不要になった場合は、必ずこのアクセス許可を削除してください。
新しい既定のブランチのリポジトリに 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

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

トラブルシューティング

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

パイプラインが "プッシュされたブランチヒントがリモートの背後にあるために更新が拒否されました" などのエラーメッセージで失敗し始めた場合、誰かが古いブランチを手動で新しいブランチにマージする必要があります。

リポジトリを複製し、そのディレクトリに cd します。
git checkout mainを使用して新しい既定のブランチを確認します (mainが新しい既定のブランチの場合)。
2 つのブランチを git checkout -b integrate と統合するための新しいブランチを作成します。
古い既定のブランチを git merge master にマージします ( master が古い既定のブランチの場合)。
新しいブランチをプッシュし、プル要求を開き、新しい既定のブランチに完了します。
その後、ミラーリングパイプラインは、マージコミットを古い既定値にミラーリングする必要があります。

フィードバック

このページはお役に立ちましたか?

Last updated on 2025-10-08