継続的デリバリーのための 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 をローカルで操作する方法を説明する」でプロジェクトを作成しておく必要があります。

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

myWebApp
```
git checkout -b feature/myFeature-1
```
出力:

"新しいブランチ 'feature/myFeature-1' に切り替えました。"
Git ブランチコマンドを実行してすべてのブランチを表示します。アスタリスクが付いたブランチは "現在チェックアウトされている" ブランチです。

myWebApp
```
git branch
```
出力:

feature/myFeature-1

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

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

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/organization/teamproject/\_git/MyWebApp * [新しいブランチ] feature/myFeature-1 -> feature/myFeature-1 ブランチ feature/myFeature-1 は、配信元からリモートブランチ feature/myFeature-1 を追跡するように設定されています。

リモートには、変更の履歴が表示されます。
組織とプロジェクト用に Azure DevOps CLI を構成します。組織とプロジェクト名を置き換えます。
```
az devops configure --defaults organization=https://dev.azure.com/organization project="project name"
```
新しい 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 を承認します。

メインはリリースする準備ができています。チームはメインブランチにリリース番号でタグを付けます。
機能 2 で作業を開始します。メインブランチからリモートでブランチを作成し、ローカルでチェックアウトを行います。

myWebApp
```
git push origin main:refs/heads/feature/myFeature-2
```
出力:

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

myWebApp
```
git checkout feature/myFeature-2
```
出力:

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

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();

変更をローカルでコミットし、リモートリポジトリにプッシュしてから、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' に切り替えました。"

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();

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

myWebApp
```
git add .
git commit -m "Adding FOF changes."
git push -u origin fof/bug-1
```
出力:

"To https://dev.azure.com/**organization**/**teamproject**/\_git/MyWebApp * [新しいブランチ] fof/bug-1 - fof/bug-1 ブランチ fof/bug-1 は、配信元からリモートブランチ fof/bug-1 を追跡するように設定されています。"
変更が運用にロールアウトされた直後に、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 つの変更が加えられていることがわかります。

pull request を承認しようとすると、マージの競合が発生したことを知らせるエラーメッセージが表示されます。
Git Pull Request Merge Conflict 解決拡張機能を使用すると、ブラウザーでマージの競合を解決できます。 [競合] タブに移動し、[Program.cs] をクリックして、マージの競合を解決します。

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

この時点で、fof/bug-1 ブランチに実装され、マスターにマージされた重要なバグ修正に基づいてリリースブランチを作成できます。 git checkout コマンドを使用して、マスターブランチから専用のリリースブランチを作成します。

git checkout -b release/v1.1 main

このコマンドは、マスターブランチに基づいて release/v1.1 という名前の新しいブランチを作成します。

リリースプロセス中に重要なマイルストーンに達すると、Git タグを使用してリリースブランチでタグがリリースされます。タグは、ソフトウェアの特定のバージョンを示すマーカーとして機能します。

git tag -a v1.1 -m "Release version 1.1"

このコマンドは、リリースブランチでリリースバージョン 1.1 をマークする v1.1 という名前のタグを作成します。

しくみ

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

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

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

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

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

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

続行

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

開発の準備

方法

しくみ

フィードバック