Git Workflow for Teams: Branching Strategies That Work — cod-ai.com

3年前、50人のスタートアップのシニア開発者が、23ファイルにわたるマージコンフリクトを解消するのに4時間を費やすのを見ました。その原因は？私たちが5人の時に理にかなっていたブランチ戦略が、スケールアップするにつれて負担になってしまったことです。その日は私たちにとって完全なスプリントの生産性を失うことになり、Gitワークフローを完全に再考する必要があるという目覚ましの時刻でした。

私はサラ・チェンで、過去12年間DevOpsアーキテクトとして、5人のスタートアップから200人以上の開発者を擁する企業まで様々なチームと一緒に働いてきました。私は、ありとあらゆるGitワークフローを見てきました—素晴らしいものもあれば、大半は普通で、いくつかは本当に壊滅的でした。私が学んだことは、すべてのチームに合う解決策はないが、自信を持って出荷できるチームと次のデプロイメントを常に恐れているチームを分ける原則があるということです。

統計は厳しいものです：2023年のGitLabの調査によれば、68％の開発チームがマージコンフリクトやブランチの問題が四半期ごとに少なくとも一度の主要なデプロイメント遅延を引き起こすと報告しています。さらに懸念されるのは、34％の開発者が実際のコーディングとは関係のないGit関連の問題に、週に5時間以上を費やしていることです。これは年間で約260時間、6週間分の労働時間に相当します—ワークフローフリクションによって失われる時間です。

悪いブランチ戦略の隠れたコスト

解決策に入る前に、実際に何が危険にさらされているのかを話しましょう。Gitワークフローに苦しんでいるチームと相談すると、彼らは通常、明らかな痛点—マージコンフリクト、デプロイメントの遅れ、そして強制的なプッシュが必要な時に起こる壊滅的なミス—に集中します。しかし、本当のコストはもっと深いところにあります。

認知的負荷を考えましょう。開発者がブランチを作成するたびに、彼らは決定を下しています：これにどのような名前を付けるべきか？どこから分岐するべきか？いつマージするべきか？どれくらいの頻度でリベースすべきか？これらのマイクロ決定は累積します。私が3つの中型企業で行った調査によれば、開発者は1日平均47件のGit関連の決定を行っています。ブランチ戦略が不明確または過度に複雑な場合、それぞれの決定には不確実性と誤りの可能性が伴います。

次に、協力のコストがあります。私はあるフィンテック企業でそのブランチ戦略が非常に複雑だったため、新しい開発者がワークフローを理解するために3日間のトレーニングを受ける必要がありました。コードレビューは、レビュアーが変更の文脈を簡単に理解できなかったために遅れました。機能ブランチは数週間存続し、メインのコードベースからの対立とずれを蓄積しました。機能がマージの準備が整った時には、基盤が変わってしまったため、広範囲な再テストが必要でした。

財務的な影響は実際のものです。30人の開発者を擁するSaaS企業がGitワークフローを最適化するのを手伝ったとき、私たちは6ヶ月間の時間節約を追跡しました。彼らはマージコンフリクトの解決時間を73%削減し、平均プルリクエストサイクルタイムを4.2日から1.8日へと短縮し、デプロイメント関連のインシデントを41%減少させました。これは、平均的な開発者コストが年間$120,000と仮定すると、彼らは年間約$180,000をフリクションの削減だけで節約しました。それは機能の市場投入時間の短縮や開発者の士気向上を考慮する必要さえありません。

コアブランチモデルの理解

まず、実際に生産で使われる主要なブランチ戦略を見ていきましょう。教科書の定義を示すつもりはありません—実際にどのように見えるのかを、実際のチームからの実データを使ってお話しします。

最良のブランチ戦略は、最も洗練されたルールを持っているものではありません—それは、チームがプレッシャーの下で実際に一貫して遵守するものです。

Git Flowは構造化ブランチ戦略の祖父で、2010年にVincent Driessenによって導入されました。これは、2つの永続ブランチ（mainとdevelop）に加え、機能、リリース、ホットフィックス用のサポーティングブランチを使用します。私は7つの異なるチームでGit Flowを実装しましたが、私が学んだことは、予定されたリリースでパッケージされたソフトウェアを出荷するチームには美しく機能しますが、ほとんどのウェブアプリケーションにはやりすぎだということです。私が関わったあるeコマース企業は、Git Flowの下で常に平均14のアクティブブランチを持っていました。彼らのリリースプロセスは、developをreleaseにマージし、テストし、releaseをmainにマージし、タグを付けてからmainをdevelopに戻すというものでした。この儀式には、リリースごとに6〜8時間がかかり、正確に実行するには3人が必要でした。

GitHub Flowは、よりシンプルな代替手段として登場しました：1つのmainブランチ、その他には機能ブランチ、そしてプルリクエストが生産の門口です。そのシンプルさに優雅さがあります。私がアドバイスをしたあるモバイルアプリのスタートアップはGitHub Flowを採用し、ブランチのオーバーヘッドを60%削減しました。彼らは5種類のブランチを維持するのからただ2つに減らしました。彼らのデプロイメント頻度は週に2回から1日に複数回へと増加しました。しかしGitHub Flowには弱点があります：いつでも生産にデプロイできることを前提としています。ステージング環境やリリースの調整が必要な場合、追加のプロセスを付け加える必要があります。

GitLab Flowはその中間に位置し、GitHub Flowのシンプルさに環境ブランチ（ステージング、生産）を加えています。私は、環境の分離が必要でGit Flowの複雑さを望まない10〜40人の開発者を擁するチームに非常に良く機能すると見つけています。私が関わったある医療ソフトウェア会社は、開発、ステージング、生産環境のための別々のブランチを維持するためにGitLab Flowを使用していました。彼らはステージングで機能をテストしながら生産を安定させ、デプロイメントプロセスは簡単でした：ステージングにマージし、テストし、その後生産にマージするというものでした。

トランクベースの開発は、GoogleやFacebookのような企業で高パフォーマンスチームに好まれるアプローチです。全員が頻繁にmain（トランク）にコミットします—少なくとも毎日です。フィーチャーフラグはユーザーに表示される内容を制御します。私は25人のチームをトランクベースの開発に移行させる手助けをしたとき、彼らは懐疑的でした。「未完成の機能をmainにコミットすることがどう可能なのか？」と彼らは尋ねました。6ヶ月後、彼らのデプロイメント頻度は週から1日に複数回に増加し、インシデントからの復旧にかかる平均時間は4時間から45分に短縮されました。重要なのは、フィーチャーフラグと包括的な自動テストに投資することでした。

チームの規模と成熟度に合った戦略の選択

ここがほとんどのアーティクルがあなたを失望させるところです：それらはこれらの戦略を、いずれも任意のチームにとって等しく妥当なオプションのように提示します。そうではありません。チームの規模、リリースの頻度、技術的成熟度は、成功するアプローチに大きく影響します。