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

  • [アーティクル]

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019 | TFS 2018

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

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

次のブランチ戦略は、Microsoft で Git を使用する方法に基づいています。 詳細については、Microsoft での Git の使用方法に関するページを参照してください。

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

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

  • すべての新機能とバグの修正には、機能ブランチを使用します。
  • pull request を使用して機能ブランチをメイン ブランチにマージします。
  • 高品質で最新のメイン ブランチを維持します。

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

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

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

基本的なブランチ ワークフローの画像

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

規則により機能ブランチに名前を付ける

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

機能ブランチに名前を付ける際の推奨事項は次のとおりです。

  • ユーザー/ユーザー名/説明
  • ユーザー/ユーザー名/作業項目
  • バグ修正/説明
  • 機能/機能名
  • 機能/機能領域/機能名
  • 修正プログラム/説明

注意

ブランチの名前付け戦略を適用するためのポリシーの設定については、ブランチ フォルダーが必要に関するページを参照してください。

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

コードでの機能フラグの使用に関する詳細を参照してください。

pull request を使用したコードの確認とマージ

pull request で行われる確認は、コードの品質を向上させる上で非常に重要です。 確認プロセスに合格した pull request のみを通じてブランチをマージします。 pull request なしでブランチをメイン ブランチにマージしないでください。

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

正常な pull request に関するいくつかの推奨事項は次のとおりです。

  • レビュー担当者 2 名が、調査に基づく最適な数です。
  • チームに既にコード確認プロセスがある場合は、既に実行している内容に pull request を取り込みます。
  • 同じレビュー担当者を多数の pull request に割り当てる際には注意してください。 レビュー担当者の責任がチーム全体で共有されている場合、pull request の機能が向上します。
  • 十分に詳しい説明を提供して、レビュー担当者が変更を迅速に処理できるようにします。
  • pull request のあるステージされている環境で実行されている変更のビルドまたはリンクされたバージョンを含めます。 他のユーザーは、容易に変更をテストできます。

高品質で最新のメイン ブランチを維持する

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

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

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

ヒント

pull request のビルド パイプラインは、確認プロセスに干渉しないように、迅速に完了する必要があります。

リリースを管理する

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

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

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

リリース ブランチからバグを修正するブランチを作成し、それらを pull request でリリース ブランチにマージします。

リリース ブランチ ワークフローの画像

変更をメイン ブランチに移植する

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

このトピックでは、リリース ブランチの変更とメインラインへの移植について説明します。 マージの代わりにチェリーピックを使用して、どのコミットをメイン ブランチに移植するかを正確に制御できるようにします。 リリース ブランチを メイン ブランチにマージすると、メイン ブランチで不要なリリース固有の変更が発生する可能性があります。

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

  1. メイン ブランチから新しい機能ブランチを作成して、変更を移植します。
  2. リリース ブランチから新しい機能ブランチへ変更をチェリーピックします。
  3. 2 つ目の pull request で機能ブランチをメイン ブランチにマージし直します。

更新されたリリース ブランチ ワークフロー。

このリリース ブランチ ワークフローでは、基本的なワークフローの柱である機能ブランチ、pull request、および常に最新バージョンのコードを持つ強力なメイン ブランチはそのままになります。

リリースにタグを使用しない理由

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

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

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

デプロイを管理する

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

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