Azure DevOps Services |Azure DevOps Server |Azure DevOps Server 2022 |Azure DevOps Server 2020
pull request を完了すると、トピック ブランチを既定のブランチ (通常はmain) にマージします。 このマージにより、トピック ブランチのコミットがメイン ブランチに追加され、マージ コミットが作成され、既定のブランチとトピック ブランチの間の競合が調整されます。 pull request のコメントとディスカッションにより、トピック ブランチで行われた変更のコンテキストが増えます。
関連するトピックブランチ履歴のため、ブランチ (またはその他の既定のブランチ) のmain履歴は直線に従いません。 プロジェクトが大きくなると、同時に作業したトピック ブランチの数が増え、既定のブランチ履歴のフォローがますます困難になります。
既定のブランチは、各トピック ブランチの履歴を正確に表しますが、プロジェクトの開発に関するより広範な質問に答えるために使用するのは困難です。
[前提条件]
| カテゴリ | Requirements |
|---|---|
| プロジェクトへのアクセス権 | プロジェクトのメンバー。 |
| アクセス許可 | - プライベート プロジェクトのコードを表示する: 少なくとも Basic アクセス。 - プライベート プロジェクトのコードを複製または投稿する: 共同作成者 セキュリティ グループのメンバー、またはプロジェクト内の対応するアクセス許可。 - ブランチまたはリポジトリのアクセス許可を設定する: ブランチまたはリポジトリの アクセス許可を管理 します。 - 既定のブランチを変更する: リポジトリ のポリシー のアクセス許可を編集します。 - リポジトリをインポートする: プロジェクト管理者 セキュリティ グループのメンバーまたは Git プロジェクト レベルの [リポジトリ の作成 ] アクセス許可が [許可] に設定されています。 詳細については、「Git リポジトリのアクセス許可を設定する」を参照してください。 |
| サービス | リポジトリが有効になっています。 |
| ツール | Optional. az repos コマンドを使用する: Azure DevOps CLI。 |
注
パブリック プロジェクトでは、 利害関係者 アクセス権を持つユーザーは、コードの表示、複製、投稿など、Azure Repos へのフル アクセス権を持ちます。
| カテゴリ | Requirements |
|---|---|
| プロジェクトへのアクセス権 | プロジェクトのメンバー。 |
| アクセス許可 | - コードの表示: 少なくとも 基本 アクセス。 - コードの複製または投稿: 共同作成者 セキュリティ グループのメンバー、またはプロジェクト内の対応するアクセス許可。 |
| サービス | リポジトリが有効になっています。 |
スカッシュ マージ
スカッシュ マージは、プル要求を完了したときにトピック ブランチの Git 履歴を要約できるマージ オプションです。 トピック ブランチの各コミットを既定のブランチの履歴に追加する代わりに、スカッシュ マージによって、すべてのファイル変更が既定のブランチの単一の新しいコミットに追加されます。 スカッシュ マージ コミットには、トピック ブランチへの参照がありません。 トピック ブランチからのすべての変更を含む 新しいコミット が生成されます。 混乱を防ぐために、トピック ブランチを削除することをお勧めします。
これを簡単に考える方法は、スカッシュ マージによってファイルの変更だけが得られ、通常のマージではファイルの変更とコミット履歴が提供されるということです。
スカッシュ マージはどのように役立ちますか?
スカッシュマージは、チームにワークフローの変更を要求することなく、デフォルトのブランチ履歴をクリーンで簡単にフォローできるようにします。 トピック ブランチの共同作成者は、トピック ブランチで必要な作業を行い、既定の分岐はスカッシュ マージを使用して線形履歴を保持します。 スカッシュ マージで更新された main ブランチのコミット履歴には、マージされたブランチごとに 1 つのコミットがあります。 この履歴をステップ実行して、作業がいつ完了したかを正確に確認できます。
スカッシュ マージ時の考慮事項
スカッシュ マージでは、既定のブランチの変更履歴が要約されるため、チームと協力して、トピック ブランチの完全なコミット履歴を保持するのと比較して、マージをスカッシュするタイミングを決定することが重要です。 スカッシュ マージの場合は、ソース ブランチを削除することをお勧めします。 ソース ブランチを削除すると、トピック ブランチ自体に既定のブランチにマージするコミットがないため、混乱を防ぐことができます。
スカッシュ マージを使用してプル要求を完了する
Azure Repos でプル要求を完了するときに、マージをスカッシュすることを選択できます。
トピックブランチをスカッシュマージするには、[プル要求の完了] ダイアログで [マージの種類] で [スカッシュコミット] を選択します。
複数のマージ ベース
プル要求の [ ファイル ] タブでは、3 つの側の比較によって差分が検出されます。 このアルゴリズムでは、ターゲット ブランチの最後のコミット、ソース ブランチの最後のコミット、および 共通のマージ ベース (たとえば、最も一般的な先祖) が考慮されます。 このアルゴリズムは、変更を迅速かつコスト効率よく、信頼性の高い方法で検出します。 残念ながら、場合によっては、複数の真のベースがあります。 ほとんどのリポジトリでは、この状況はまれですが、アクティブなユーザーが多い大規模なリポジトリでは一般的な場合があります。 分岐間に複数のマージ ベースが存在するかどうかを手動で確認できます。 これを行うには、コマンド git merge-base --all feature master 実行します。 Azure DevOps では、PR ごとに複数のマージ ベースが存在することを検出します。 これらが検出されると、Azure DevOps に "複数のマージ ベースが検出されました" というメッセージが表示されます。 表示されるコミットの一覧が不完全である可能性があります。 Azure DevOps では、複数のマージ ベースの検出が実行されていますが、潜在的なマージ ベースが既にマージされているかどうかは確認されません。 このようなチェックは、 git merge-baseによって行われます。 このため、 git merge-base が 1 つのマージ ベースのみを報告する場合でも、Azure DevOps でメッセージが表示される可能性があります。
注
PR レビュー中に変更が失われた場合は、複数のマージ ベースが根本原因でないことを確認してください。
次のシナリオ例では、Azure DevOps によって複数のベースとして検出され、マージ ベースは番号 1 と 2 で示されます。
- 異なるブランチ間のクロスマージ (クロス クロスとも呼ばれます) (Azure DevOps と
git merge-baseによって報告)
---1---o---A
\ /
X
/ \
---2---o---o---B
- 1 つのブランチを他の 2 つにマージする (Azure DevOps によって報告されるが、マージ ベース 2 を排除する
git merge-baseによって報告されない)
---1---o---o---o---A
\ /
\-------2
\ \
\---o---o---o---B
- メイン ブランチの余波の処理 (マージ コミットの修正など)
* 42bb2d2 (HEAD, A) Amended merge commit
|\
| | * 67c9bb8 (other) Merge branch 'A' into B
| | |\
| |/ /
|/| /
| |/
| * fa78e32 add second commit
* | 15845c9 add first commit
|/
* 6a52130 add init
- 機能ブランチのアクティブな再利用
- 元に戻す、チェリーピック、マージを使用したその他の非直感的で複雑な操作
複数のマージ ベース検出は、セキュリティ認識の一部です。 複数のマージ ベースがある場合、選択したマージ ベースによっては、ユーザー インターフェイスのファイル差分アルゴリズムでファイルの変更が正しく検出されない可能性があります。 プル要求内のファイルのバージョンがマージ ベース間で異なる場合は、複数のマージ ベース警告が発生します。
詳細については 、公式の Git ドキュメント を参照してください。
複数のベースからのマージの潜在的なセキュリティ リスク
- 悪意のあるユーザーが UI アルゴリズムを悪用して、PR に存在しない悪意のある変更をコミットする可能性があります。
- PR で提案された変更が既にターゲット ブランチにある場合は、[ ファイル ] タブに表示されますが、フォルダーの変更にマップされたブランチ ポリシーがトリガーされない可能性があります。
- 複数のマージ ベースから同じファイルに対する 2 セットの変更が PR に存在しない可能性があります。 その場合、危険なロジックのギャップが発生する可能性があります。
複数のマージ ベースの問題を解決する方法
複数のマージ ベースがあると必ずしも悪いわけではありませんが、すべて問題ないことを再確認する必要があります。 複数のマージ ベースを取り除くには、ターゲット上のブランチをリベースするか、ターゲットをブランチにマージすることで、ブランチを 1 つの共通の先祖に結び付けます。 これらのアクションは警告メッセージを取り除き、実際の変更が正常かどうかを確認するのに役立ちます。
1 つの方法は、再調整またはマージする前に、論理的なリセットと進行状況の保存です。 その後、新しいブランチを作成するか、空のブランチをリベースし、明確なポイントから変更を適用できます。 変更が既に存在する場合、このプロセスではリモートへの強制プッシュが必要になる場合があります。
複数のマージ ベースの問題を回避する方法
複数のマージ ベースの問題を回避するための一般的なヒントを次に示します。
- プル要求を準備するときは、メイン ブランチまたはリリース ブランチの最新バージョンから機能ブランチを作成します。
- 必要な場合を除き、リポジトリの安定したブランチから直接発生しないブランチは作成しないでください。
複数のマージ ベースの問題が再び表示された場合の対応
多くのアクティブな共同作成者が存在する大規模なリポジトリでは、この問題は特に不便な場合があります。 マージによって複数のベースを取り除いても、状況が再び現れる可能性があります。 誰かが長年のプル要求を閉じると、状況を再現できます。 ビルド ポリシーとテストが実行されている場合でも、プル要求を完了する手段はありません。 新しいブランチのリセットと開始が役立つ場合があります。 何も変更されない場合は、状況が繰り返される場合でも、変更はおそらく明確になります。