Git ブランチ戦略を採用する
Azure DevOps Services |Azure DevOps Server 2022 - Azure DevOps Server 2019 |TFS 2018
Git などの分散バージョン管理システムを使用すると、バージョン管理を使用してコードを共有および管理する方法を柔軟に行えます。 チームは、この柔軟性と、一貫した方法で共同作業とコード共有を行う必要性とのバランスを見つける必要があります。
チーム メンバーは、他のユーザーと共有されている Git ブランチを通じて、コードの変更を発行、共有、レビュー、反復処理します。 チームに分岐戦略を採用します。 共同作業を改善し、バージョン管理の管理に費やす時間を減らし、コードの開発に多くの時間を費やすことができます。
次の分岐戦略は、Microsoft での Git の使用方法に基づいています。 詳細については、「 Microsoft での Git の使用方法」を参照してください。
ブランチ戦略をシンプルに保つ
ブランチ戦略をシンプルに保ちます。 次の 3 つの概念から戦略を構築します。
- すべての新機能とバグの修正には、機能ブランチを使用します。
- プル要求を使用して、機能ブランチをメイン ブランチにマージします。
- 高品質で最新のメイン ブランチを維持します。
これらの概念を拡張し、矛盾を回避する戦略は、一貫性があり、従いやすいチームのバージョン管理ワークフローになります。
作業に機能ブランチを使用する
メイン ブランチに基づいて機能を開発し、機能ブランチのバグを修正します。 これらのブランチは 、トピック ブランチとも呼ばれます。 機能ブランチは、進行中の作業をメイン ブランチの完了した作業から分離します。 Git ブランチは、作成と保守にコストがかからない。 小さな修正や変更でも、独自の機能ブランチが必要です。
すべての変更に対して機能ブランチを作成すると、履歴の確認が簡単になります。 ブランチで行われたコミットを確認し、ブランチをマージしたプル要求を確認します。
規則に従って機能ブランチに名前を付けます
機能ブランチの一貫した名前付け規則を使用して、ブランチで行われた作業を識別します。 ブランチ名には、ブランチを作成したユーザーなど、他の情報を含めることもできます。
機能ブランチに名前を付ける際の推奨事項をいくつか次に示します。
- users/username/description
- users/username/workitem
- bugfix/description
- feature/feature-name
- feature/feature-area/feature-name
- 修正プログラム/説明
Note
ブランチの名前付け戦略を適用するためのポリシーの設定については、「 ブランチ フォルダーを要求する」を参照してください。
機能フラグを使用して実行時間の長いブランチを管理する
コードで 機能フラグを使用 する方法の詳細を確認します。
pull request を使用したコードの確認とマージ
プル要求で行われるレビューは、コードの品質を向上させるために重要です。 レビュー プロセスに合格したプル要求を介してのみブランチをマージします。 プル要求なしでブランチをメイン ブランチにマージすることは避けてください。
プル要求のレビューの完了には時間がかかります。 チームは、pull request の作成者とレビュー担当者に期待される内容に同意する必要があります。 レビュー担当者の責任を分散して、チーム全体でアイデアを共有し、コードベースの知識を広めます。
プル要求の成功に関するいくつかの提案:
- 2 人の校閲者は 、研究に基づく最適な数です。
- チームにコード レビュー プロセスが既にある場合は、プル要求を既に実行している内容に取り込みます。
- 多数のプル要求に同じレビュー担当者を割り当てるように注意してください。 レビュー担当者の責任がチーム全体で共有されている場合、プル要求の方が効果的に機能します。
- 校閲者が変更に迅速に対応できるように、説明に十分な詳細を入力します。
- プル要求を使用して、ステージング環境で実行されているビルドまたはリンクされたバージョンの変更を含めます。 他のユーザーは、変更を簡単にテストできます。
高品質で最新のメイン ブランチを維持する
メイン ブランチのコードは、テストに合格し、クリーンにビルドし、常に最新である必要があります。 チームによって作成された機能ブランチが既知の適切なバージョンのコードから開始されるように、メイン ブランチにはこれらの品質が必要です。
次のメイン ブランチのブランチ ポリシー を設定します。
- コードをマージするプル要求が必要です。 この方法では、メイン ブランチへの直接プッシュを防ぎ、提案された変更について確実に説明します。
- プル要求の作成時にレビュー担当者を自動的に追加します。 追加されたチーム メンバーは、コードを確認し、プル要求の変更についてコメントします。
- プル要求を完了するには、ビルドが正常に完了している必要があります。 メイン ブランチにマージされたコードは、クリーンにビルドする必要があります。
ヒント
プル要求のビルド パイプラインは迅速に完了する必要があるため、レビュー プロセスに干渉しません。
リリースの管理
リリース ブランチを使用して、コードのリリースでの変更を調整し、安定させます。 このブランチは有効期間が長く、機能ブランチとは異なり、プル要求でメイン ブランチにマージされません。 必要な数のリリース ブランチを作成します。 アクティブな各リリース ブランチは、サポートする必要がある別のバージョンのコードを表します。 特定のリリースのサポートを停止する準備ができたら、リリース ブランチをロックします。
リリース ブランチを使用する
リリースまたはその他のマイルストーン (スプリントの終了など) に近づくと、メイン ブランチからリリース ブランチを作成します。 リリース /20 など、このブランチをリリースに関連付ける明確な名前を付けます。
ブランチを作成してリリース ブランチのバグを修正し、プル要求でリリース ブランチにマージします。
ポートがメイン ブランチに戻る
修正がリリース ブランチとメイン ブランチの両方に存在することを確認します。 1 つの方法は、リリース ブランチで修正を行い、コードの回帰を防ぐためにメイン ブランチに変更を加える方法です。 もう 1 つのアプローチ (および Azure DevOps チームによって採用されているもの) は、常にメインラインで変更を加え、それらをリリース ブランチに移植することです。 リリース フロー戦略の詳細を確認できます。
このトピックでは、リリース ブランチで変更を加え、それらをメインラインに移植する方法について説明します。 マージの代わりにチェリーピックを使用して、どのコミットをメインブランチに移植するかを正確に制御できるようにします。 機能ブランチをメイン ブランチにマージすると、メイン ブランチで不要なリリース固有の変更が行われます。
次の手順で、リリース ブランチで行われた変更でメイン ブランチを更新します。
- メイン ブランチから新しい機能ブランチを作成して、変更を移植します。
- リリース ブランチから新しい機能ブランチへの変更を選択します。
- 機能ブランチを 2 番目のプル要求でメイン ブランチにマージします。
このリリース ブランチ ワークフローは、機能ブランチ、プル要求、および常に最新バージョンのコードを持つ強力なメイン ブランチという基本的なワークフローの柱をそのまま保持します。
リリースにタグを使用しないのはなぜですか?
他の分岐ワークフローでは、Git タグ を使用して特定のコミットをリリースとしてマークします。 タグは、履歴内のポイントを重要としてマークするのに役立ちます。 タグは、リリースにブランチを使用している場合は必要ない追加の手順をワークフローに導入します。
タグは保持され、コミットとは別にプッシュされます。 チーム メンバーは、コミットのタグ付けを簡単に見逃し、その後履歴に戻ってタグを修正する必要があります。 また、タグをプッシュする追加の手順を忘れて、次の開発者がリリースをサポートするときに古いバージョンのコードから作業を続けることもできます。
リリース ブランチ戦略は、リリースを処理するための基本的な機能ブランチ ワークフローを拡張します。 チームは、移植の変更にチェリーピック以外の新しいバージョン管理プロセスを採用する必要はありません。
デプロイを管理する
コードの複数のデプロイは、複数のリリースを処理するのと同じ方法で処理できます。 deploy/performance-test などの明確な名前付け規則を作成し、環境ブランチをリリース ブランチのように扱います。 チームは、メイン ブランチのコードを使用してデプロイ ブランチを更新するプロセスに同意する必要があります。 デプロイ ブランチの Cherry-pick バグが修正され、メイン ブランチに戻ります。 リリース ブランチからの変更の移植と同じ手順を使用します。
この推奨事項の例外は、継続的デプロイの形式を使用している場合です。 継続的デプロイを操作する場合 は、Azure Pipelines を使用して、メイン ブランチからデプロイ ターゲットにビルドを昇格します。