既定のブランチの変更

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

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

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

[前提条件]

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

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

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

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

注

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

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

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

    既定の分岐の設定を示すスクリーンショット。

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

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

名前を選択する

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

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

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

  2. ビルド ID にリポジトリへの 投稿 アクセス許可を付与します。 プロジェクト設定>Repositories>(リポジトリ)>Permissions に移動します。 最大 2 つの ID が存在する場合があります。1 つはプロジェクト コレクション ビルド サービス用、もう 1 つはプロジェクト ビルド サービス用です。 「共同作業」のアクセス許可が許可になっていることを確認します。

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

  2. 新しい既定のブランチのリポジトリに 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
  1. ウィザードで [Azure Repos Git] と [既存の Azure Pipelines YAML ファイル] を選択して、新しいパイプラインを作成します。 前の手順で追加した mirror.yml ファイルを選択します。 パイプラインを保存して実行します。

トラブルシューティング

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

「プッシュされたブランチのチップがリモートより遅れているため、更新が拒否されました」などのエラー メッセージが表示され、パイプラインが正常に動作しなくなった場合、手動で古いブランチを新しいブランチにマージする必要があります。

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