Git ブランチ戦略を採用する

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

Git などの分散バージョン管理システムを使用すると、バージョン管理を使用してコードを共有および管理する方法を柔軟に行えます。 チームは、この柔軟性と、一貫した方法でコードを共同作業および共有する必要性のバランスを見つける必要があります。

チーム メンバーは、他のユーザーと共有されている Git ブランチを通じて、コードの変更を発行、共有、レビュー、反復します。 チームのブランチ戦略を採用します。 共同作業を改善し、バージョン管理の管理に費やす時間を減らし、コードの開発に多くの時間を費やすことができます。

次の分岐戦略は、Microsoft で Git を使用する方法に基づいています。 詳細については、「 Microsoft での Git の使用方法」を参照してください。

ブランチ戦略をシンプルに保つ

ブランチ戦略をシンプルに保ちます。 次の 3 つの概念から戦略を構築します。

• すべての新機能とバグ修正に機能ブランチを使用します。
• プル要求を使用して、機能ブランチをメイン ブランチにマージします。
• 高品質の up-to-date メイン ブランチを維持します。

これらの概念を拡張し、矛盾を回避する戦略は、一貫性があり、従いやすいチームのバージョン管理ワークフローになります。

作業に機能ブランチを使用する

メイン ブランチに基づいて機能を開発し、機能ブランチのバグを修正します。 これらのブランチは 、トピック ブランチとも呼ばれます。 機能ブランチは、進行中の作業をメイン ブランチの完了した作業から分離します。 Git ブランチは、作成と保守にコストがかからない。 小さな修正や変更であっても、独自の機能ブランチが必要です。

すべての変更に対して機能ブランチを作成すると、履歴の確認が簡単になります。 ブランチで行われたコミットを確認し、ブランチをマージしたプル要求を確認します。

規則に従って機能ブランチに名前を付けます

機能ブランチの一貫した名前付け規則を使用して、ブランチで行われた作業を識別します。 ブランチ名には、ブランチを作成したユーザーなど、他の情報を含めることもできます。

機能ブランチに名前を付けるための推奨事項をいくつか次に示します。

• users/username/description
• users/username/workitem
• bugfix/description
• feature/feature-name
• feature/feature-area/feature-name
• 修正プログラム/説明

機能フラグを使用して実行時間の長いブランチを管理する

コードで 機能フラグを使用 する方法の詳細を確認します。

pull request を使用してコードを確認およびマージする

pull request で行われるレビューは、コードの品質を向上させるために重要です。 レビュー プロセスに合格したプル要求を通じてブランチのみをマージします。 プル要求なしでブランチをメイン ブランチにマージすることは避けてください。

pull request のレビューが完了するまでに時間がかかります。 チームは、pull request 作成者とレビュー担当者から期待される内容に同意する必要があります。 レビュー担当者の責任を分散して、チーム全体でアイデアを共有し、コードベースの知識を広げます。

プル要求の成功に関するいくつかの提案:

• 2 人の校閲者は 、研究に基づく最適な数です。
• チームに既にコード レビュー プロセスがある場合は、pull request を既に行っていることを確認します。
• 同じレビュー担当者を多数のプル要求に割り当てるように注意してください。 レビュー担当者の責任がチーム全体で共有されている場合、プル要求の方がうまく機能します。
• 校閲者を迅速に変更に対応できるように、説明に十分な詳細を入力します。
• プル要求を使用して、ステージング環境で実行されているビルドまたはリンクされたバージョンの変更を含めます。 他のユーザーは変更を簡単にテストできます。

高品質の up-to-date メイン ブランチを維持する

メイン ブランチのコードは、テストに合格し、クリーンにビルドし、常に最新である必要があります。 メイン ブランチには、チームによって作成された機能ブランチが既知の適切なバージョンのコードから開始されるように、これらの品質が必要です。

次のメイン ブランチのブランチ ポリシー を設定します。

• コードをマージするためのプル要求が必要です。 この方法では、メイン ブランチへの直接プッシュを防ぎ、提案された変更の議論を確実にします。
• pull request の作成時にレビュー担当者を自動的に追加します。 追加されたチーム メンバーは、コードを確認し、pull request の変更についてコメントします。
• プル要求を完了するには、ビルドが成功している必要があります。 メイン ブランチにマージされたコードは、正常にビルドされます。

リリースを管理する

リリース ブランチを使用して、コードのリリースの変更を調整し、安定させます。 このブランチは有効期間が長く、機能ブランチとは異なり、プル要求のメイン ブランチにマージされません。 必要な数のリリース ブランチを作成します。 アクティブな各リリース ブランチは、サポートする必要がある別のバージョンのコードを表します。 特定のリリースのサポートを停止する準備ができたら、リリース ブランチをロックします。

リリース ブランチを使用する

リリースまたはその他のマイルストーン (スプリントの終了など) に近づくと、メイン ブランチからリリース ブランチを作成します。 このブランチにリリース ( release/20 など) に関連付ける明確な名前を付けます。

ブランチを作成してリリース ブランチからのバグを修正し、プル要求でリリース ブランチにマージします。

ポートがメイン ブランチに戻る

修正プログラムがリリース ブランチとメイン ブランチの両方に存在することを確認します。 1 つの方法は、リリース ブランチで修正を行い、メイン ブランチに変更を加えてコードの回帰を防ぐことです。 もう 1 つのアプローチ (および Azure DevOps チームによって採用されているもの) は、常にメインラインを変更してから、それらをリリース ブランチに移植することです。 リリース フロー戦略の詳細については、こちらをご覧ください。

このトピックでは、リリース ブランチで変更を加え、メインラインに移植する方法について説明します。 マージの代わりにチェリー ピックを使用して、メイン ブランチに移植するコミットを正確に制御できるようにします。 リリース ブランチをメイン ブランチにマージすると、メイン ブランチで不要なリリース固有の変更が行われます。

次の手順で、リリース ブランチで行われた変更でメイン ブランチを更新します。

1. メイン ブランチから新しい機能ブランチを作成して、変更を移植します。
2. リリース ブランチから新しい機能ブランチへの変更を選択します。
3. 機能ブランチを 2 番目のプル要求でメイン ブランチにマージし直します。

このリリース ブランチ ワークフローは、基本的なワークフローの柱 (機能ブランチ、プル要求、および常に最新バージョンのコードを持つ強力なメイン ブランチ) をそのまま維持します。

リリースにタグを使用しないのはなぜですか?

他の分岐ワークフローでは、Git タグ を使用して、特定のコミットをリリースとしてマークします。 タグは、履歴内のポイントを重要としてマークするのに役立ちます。 タグを使用すると、リリースにブランチを使用する場合は不要な追加の手順がワークフローに導入されます。

タグは保持され、コミットとは別にプッシュされます。 チーム メンバーはコミットのタグ付けを簡単に見逃す可能性があり、タグを修正するには、後で履歴に戻る必要があります。 また、タグをプッシュする追加の手順を忘れることもできます。次の開発者は、リリースをサポートするときに古いバージョンのコードから作業します。

リリース ブランチ戦略は、リリースを処理するための基本的な機能ブランチ ワークフローを拡張します。 チームは、移植の変更にチェリーピック以外の新しいバージョン管理プロセスを採用する必要はありません。

デプロイを管理する

複数のリリースを処理するのと同じ方法で、コードの複数のデプロイを処理できます。 deploy/performance-test などの明確な名前付け規則を作成し、環境ブランチをリリース ブランチのように扱います。 チームは、メイン ブランチのコードを使用してデプロイ ブランチを更新するプロセスに同意する必要があります。 デプロイ ブランチでメイン ブランチに戻る、Cherry-pick のバグ修正。 リリース ブランチからの変更の移植と同じ手順を使用します。

この推奨事項の例外は、継続的デプロイの形式を使用している場合です。 継続的デプロイを使用してメイン ブランチからデプロイ ターゲットにビルドを昇格する場合は、 Azure Pipelines を使用します。