継続的デリバリーのための Git ブランチ モデルを確認する

  • 3 分

コードを記述する目的は、ソフトウェアに拡張機能を提供することです。

プロセスのオーバーヘッドが多すぎるブランチ モデルは、顧客に変更を加える速度を上げるのに役立ちません。ブランチ モデルを開発すると、品質の低い変更を出荷しないための十分なパディングが得られます。 ただし、速度を低下するほど多くのプロセスを導入することはありません。

インターネットには、Git 用のブランチ戦略があふれています。正しいか間違っているかではなく、チームに最適なブランチ戦略が役立ちます。

機能ブランチと pull request の組み合わせを常に使用して、出荷完了状態のメイン ブランチを用意する方法について学習します。

開発の準備

提案されている原則について説明します。

  • メイン ブランチ:

    • メイン ブランチは、すべてのものを実稼働環境にリリースする唯一の方法です。
    • メイン ブランチは、常にリリース準備完了状態である必要があります。
    • ブランチ ポリシーを使用してメイン ブランチを保護します。
    • メイン ブランチに対する変更は、pull requests のみを介してフローされます。
    • Git タグを使用して、メイン ブランチ内のすべてのリリースにタグを付けします。

  • 機能ブランチ:

    • すべての新機能とバグの修正には、機能ブランチを使用します。
    • 機能フラグを使用して、実行時間の長い機能ブランチを管理します。
    • 機能ブランチからメインへの変更は、pull request を介してのみ行います。
    • 目的を反映するように機能に名前を付けます。

    ブランチの一覧:

    bugfix/description
features/feature-name
features/feature-area/feature-name
hotfix/description
users/username/description
users/username/workitem

  • Pull Request:

    • コードを確認し、pull request とマージします。
    • pull request の一部として検査および検証する処理を自動化します。
    • pull request の完了期間を追跡し、所要時間を短縮するためのゴールを設定します。

前の演習で作成した myWebApp を使用します。 「Git をローカルで操作する方法を説明する」を参照してください。

このレシピでは、マーケットプレースから 3 つのトレンド拡張機能を使用します。

  • Azure CLI: Azure のコマンド ライン インターフェイスです。
  • Azure DevOps CLI: これは、Azure DevOps および Azure DevOps Server と連携する Azure CLI の拡張機能であり、Git、CI パイプライン、アジャイル ツールとシームレスに統合するように設計されています。 Azure DevOps CLI を使用すると、コマンド ラインを離れることなくプロジェクトに貢献できます。 CLI は、Windows、Linux、Mac で実行されます。
  • Git Pull Request Merge Conflict: Microsoft DevLabs によって作成されたこのオープンソース拡張機能を使うと、Web 上の pull request のマージ競合を確認して解決できます。 Git の pull request を完了する前に、ターゲット ブランチとの競合を解決する必要があります。 この拡張機能を使用すると、マージを実行してローカル クローンで競合を解決する代わりに、pull request のマージの一部として Web 上でこれらの競合を解決できます。

Azure DevOps CLI では、クエリ結果を JSON、JSONC、YAML、YAMLC、テーブル、TSV、なし、で返すことがサポートされています。 構成コマンドを使用して、設定を構成できます。

方法

重要

最初のラーニング パス「Git をローカルで操作する方法を説明する」でプロジェクトを作成しておく必要があります。

  1. メイン ブランチをローカル リポジトリに複製した後、新しい機能ブランチ myFeature-1 を作成します。

    myWebApp

    git checkout -b feature/myFeature-1

    出力:

    "新しいブランチ 'feature/myFeature-1' に切り替えました。"

  2. Git ブランチ コマンドを実行してすべてのブランチを表示します。 アスタリスクが付いたブランチは "現在チェックアウトされている" ブランチです。

    myWebApp

    git branch

    出力:

    feature/myFeature-1

    main

  3. feature/myFeature-1 ブランチの Program.cs ファイルを変更します。

    myWebApp

    notepad Program.cs

  4. 変更をステージし、ローカルでコミットしてから、ブランチをリモートに公開します。

    myWebApp

    git status

    出力:

    "ブランチ feature/myFeature-1 変更がコミット用にステージされませんでした: ("git add <ファイル>..." を使用してコミットされるものを更新します) ("git checkout -- <ファイル>..." を使用して作業ディレクトリの変更を破棄します) 変更: Program.cs。"

    myWebApp

    git add .
git commit -m "Feature 1 added to Program.cs"

    出力:

    "[feature/myFeature-1 70f67b2] feature 1 が program.cs に追加されました 1 ファイルが変更されました、1 つの挿入(+)。"

    myWebApp

    git push -u origin feature/myFeature-1

    出力:

    Delta compression using up to 8 threads. Compressing objects: 100% (3/3), done. オブジェクトの書き込み中: 100% (3/3)、348 バイト | 348.00 KiB/s、完了。 合計 3 (デルタ 2)、再利用 0 (デルタ 0) リモート: オブジェクトの分析中... (3/3) (10 ms) リモート: パックファイルの格納中... 完了 (44 ms) リモート: インデックスの格納中... 完了 (62 ms) To https://dev.azure.com/Geeks/PartsUnlimited/\_git/MyWebApp * [新しいブランチ] feature/myFeature-1 -> feature/myFeature-1 ブランチ feature/myFeature-1 は、配信元からリモート ブランチ feature/myFeature-1 を追跡するように設定されています。

    リモートには、変更の履歴が表示されます。

    Screenshot of remote history of the changes.

  5. 組織とプロジェクト用に Azure DevOps CLI を構成します。 組織とプロジェクト名を置き換えます。

    az devops configure --defaults organization=https://dev.azure.com/organization project="project name"

  6. 新しい pull request (Azure DevOps CLI を使用) を作成し、feature-1 ブランチの変更を確認します。

    az repos pr create --title "Review Feature-1 before merging to main" --work-items 38 39 `
--description "#Merge feature-1 to main" `
--source-branch feature/myFeature-1 --target-branch main `
--repository myWebApp --open

    作成後に pull request を Web ブラウザーで開くときは --open スイッチを使います。 --deletesource-branch スイッチを使用すると、pull request が完了した後にブランチを削除できます。 また、-auto-complete を使用して、すべてのポリシーが合格したときに自動的に完了することを検討してください。ソース ブランチをターゲット ブランチにマージできます。

    注意

    az repos pr create パラメーターの詳細については、コードをレビューしてマージするための pull request の作成に関する記事を参照してください。

    チームは共同でコードの変更を確認し、pull request を承認します。

    Screenshot of the pull request with code changes approved and completed.

    メインはリリースする準備ができています。 チームはメイン ブランチにリリース番号でタグを付けます。

    Screenshot of the creation of a tag example.

  7. 機能 2 で作業を開始します。 メイン ブランチからリモートでブランチを作成し、ローカルでチェックアウトを行います。

    myWebApp

    git push origin main:refs/heads/feature/myFeature-2

    出力:

    "合計 0 (デルタ 0)、再利用 0 (デルタ 0) To https://dev.azure.com/Geeks/PartsUnlimited/\_git/MyWebApp * [新しいブランチ] origin/HEAD -> refs/heads/feature/myFeature-2。"

    myWebApp

    git checkout feature/myFeature-2

    出力:

    "新しいブランチ 'feature/myFeature-2' に切り替えました ブランチ feature/myFeature-2 は、配信元からリモート ブランチ feature/myFeature-2 を追跡するように設定されています。"

  8. feature-1 で変更されたコード内の同じコメント行を変更して、Program.cs を変更します。

    public class Program
{
    // Editing the same line (file from feature-2 branch)
    public static void Main(string[] args)
    {
        BuildWebHost(args).Run();
    }

    public static IWebHost BuildWebHost(string[] args) =>
        WebHost.CreateDefaultBuilder(args)
            .UseStartup<Startup>()
            .Build();

  9. 変更をローカルでコミットし、リモート リポジトリにプッシュしてから、pull request を発生させ、feature/myFeature-2 からメイン ブランチに変更をマージします。

    az repos pr create --title "Review Feature-2 before merging to main" --work-items 40 42 `
--description "#Merge feature-2 to main" `
--source-branch feature/myFeature-2 --target-branch main `
--repository myWebApp --open

    pull request が実行中の場合、feature-1 リリースに対する運用で重大なバグが報告されます。 この問題を調査するには、現在運用環境にデプロイされているコードのバージョンに対してデバッグする必要があります。 この問題を調査するには、release_feature1 タグを使用して新しい fof ブランチを作成します。

    myWebApp

    git checkout -b fof/bug-1 release_feature1

    出力:

    "新しいブランチ 'fof/bug-1' に切り替えました。"

  10. feature-1 リリースで変更されたのと同じコード行を変更して、Program.cs を変更します。

    public class Program
{
    // Editing the same line (file from feature-FOF branch)
    public static void Main(string[] args)
    {
        BuildWebHost(args).Run();
    }

    public static IWebHost BuildWebHost(string[] args) =>
        WebHost.CreateDefaultBuilder(args)
            .UseStartup<Startup>()
            .Build();

  11. 変更をローカルでステージしてコミットしてから、変更をリモート リポジトリにプッシュします。

    myWebApp

    git add .
git commit -m "Adding FOF changes."
git push -u origin fof/bug-1

    出力:

    "To https://dev.azure.com/Geeks/PartsUnlimited/\_git/MyWebApp * [新しいブランチ] fof/bug-1 - fof/bug-1 ブランチ fof/bug-1 は、配信元からリモート ブランチ fof/bug-1 を追跡するように設定されています。"

  12. 変更が運用にロール アウトされた直後に、fof\bug-1 ブランチに release_bug-1 タグのタグを付け、pull request を発生させて、fof/bug-1 からの変更をメインにマージします。

    az repos pr create --title "Review Bug-1 before merging to main" --work-items 100 `
--description "#Merge Bug-1 to main" `
--source-branch fof/Bug-1 --target-branch main `
--repository myWebApp --open

    pull request の一部として、ブランチは削除されます。 ただし、タグを使用して引き続き履歴全体を参照できます。

    重要なバグ修正を行ってから、feature-2 pull request をレビューしましょう。

    [ブランチ] ページでは、feature/myFeature-2 ブランチでメインの前に 1 つの変更と、メインの下に 2 つの変更が加えられていることがわかります。

    Screenshot of the branches page. The feature myFeature two branches are one change ahead of the main and two changes behind the main.

    pull request を承認しようとすると、マージの競合が発生したことを知らせるエラー メッセージが表示されます。

    Screenshot of merge conflicts from pull request.

  13. Git Pull Request Merge Conflict 解決拡張機能を使用すると、ブラウザーでマージの競合を解決できます。 [競合] タブに移動し、[Program.cs] をクリックして、マージの競合を解決します。

    Screenshot of the Git pull request merge conflict resolution extension.

    ユーザー インターフェイスを使用すると、ソースやターゲットを取得したり、カスタム変更を追加したり、マージを確認して送信したりできます。 変更がマージされると、pull request が完了します。

しくみ

Git ブランチ モデルが、機能ごとにブランチを作成することで、機能を並列で柔軟に操作する方法を学習しました。

pull request ワークフローでは、ブランチ ポリシーを使用してコードの変更をレビューできます。

Git タグは、リリースされたコードのバージョンなどのマイルストーンを記録するための優れた方法です。タグを使用すると、タグからブランチを作成できます。

以前のリリース タグからブランチを作成し、運用における重要なバグを修正しました。

Web ポータルのブランチ ビューを使用すると、メインのブランチを事前に識別しやすくなります。 また、進行中の pull request がマージの競合を解決せずにメインにマージしようとすると、マージの競合が強制されます。

リーン ブランチ モデルを使用すると、有効期間の短いブランチを作成し、品質の高い変更をより迅速に運用にプッシュできます。