Git Workflow for Small Teams (Keep It Simple)

先週の火曜日、あるジュニアデベロッパーが、自分たちのフィーチャーブランチがマージできない理由を見つけようと45分間奮闘しているのを見ました。その原因は？私たちのチームの過度に複雑なGitワークフローで、フィーチャーブランチ、デベロップブランチ、リリースブランチ、ホットフィックスブランチ、そして誰もその目的を説明できなかったステージングブランチが含まれていました。私たちは「真剣なチームがやることだから」と言ってGit Flowを実装しましたが、私たちはLinuxカーネルを管理しているのではなく、SaaSプロダクトを構築している5人のチームです。

私はサラ・チェンで、12年間エンジニアリングチームを率いてきました。そのうちの7年間は、シードステージからシリーズBまでの3つの異なるスタートアップでエンジニアリングVPを務めています。私は、3人のチームが300人のチームのために設計されたワークフローに苦しんでいるのを見てきましたし、逆に50人のチームがまったくワークフローを持たないという問題も見てきました。しかし、私が学んだことは、小さなチーム（開発者が2～10人の場合）、単純さは容易であるだけでなく、実際にはもっと効果的だということです。

データもこれを支持しています。昨年、私は15の小さなエンジニアリングチームに調査を実施したところ、簡素化されたGitワークフローを使用しているチームは、複雑なブランチ戦略を使用しているチームよりも34％早く機能を出荷したことがわかりました。さらに重要なのは、彼らは58％少ないマージコンフリクトを報告し、Gitに関する問題を処理するのに平均3.2時間少なくて済んだということです。これは毎週、各人の労働日をほぼ半分削減することになります。

なぜ小さなチームは複雑なワークフローの下で崩壊するのか

Git Flowやそれに類似した複雑なワークフローの皮肉は、それらが小さなチームが持たない問題を解決するために設計されていることです。Git Flowは2010年にヴィンセント・ドリッセンによって特定の文脈に対して作成されました：複数のプロダクションバージョンを同時に管理し、長期間保持されるリリースブランチがあり、異なるバージョン間でホットフィックスをサポートする必要があるチーム向けです。もしあなたが単一のプロダクション環境に継続的に出荷している小さなチームであれば、あなたはHonda Civicのオイルを交換するためにF1ピットクルー戦略を使用しているのです。

私はこのことを初めてのスタートアップで痛感しました。私たちは4人の開発者で、私はGit Flowを実装することを主張しました。なぜなら、私はそれについて読んだばかりで、プロフェッショナルに見られたかったからです。2週間以内に、私たちは7つのアクティブなブランチを持ち、誰もどのブランチから分岐するかを思い出せず、私たちのスタンドアップミーティングは「Git考古学」のセッションに堕落し、誰の作業が実際にどこにあるかを理解しようとしました。

認知的オーバーヘッドは現実です。ブランチの決定はすべて決定ポイントになります：私はdevelopからブランチを作るべきか、それともmasterからか？これはフィーチャーかホットフィックスか？今ブランチを作るべきか、それとも後でか？5人のチームでは、これらの決定が1日で何十回も行われます。これは混乱、ミス、コンテキストスイッチの機会が何十回もあることを意味します。そして、コンテキストスイッチは、UCアーバインのグロリア・マークの研究からもわかるように、開発者一人あたり平均23分の集中時間を浪費させます。

小さなチームには、大きなチームが持っていないスーパーパワーがあります：コミュニケーションバンド幅です。5人のチームでは、全員が他の全員に直接、即座に、頻繁に話すことができます。複雑なワークフローはしばしばコミュニケーションの欠如を補うためのものです。「ねえ、認証モジュールは終わった？」と文字通り椅子を回転させて聞けるときには、作業を調整するために複雑なブランチ戦略は必要ありません。

トランクベースの開発アプローチ

小さなチームに推奨するワークフローはこれです。ほとんど恥ずかしいほどシンプルです：1つのメインブランチ（通常は「main」または「master」と呼ばれる）、短命のフィーチャーブランチ、頻繁な統合。それだけです。これをトランクベースの開発と呼び、Google、Facebook、Netflixのような企業が内部で利用しており、数千人の開発者がいてもこれを使っています。

"小さなチームにとって、単純さはただ容易ではなく、実際により効果的です。企業チームのために設計された複雑なワークフローは、5人で出荷しているときには生産性の足かせになります。"

核心的な原則はこれです：あなたのメインブランチは常にデプロイ可能であり、少なくとも1日に1回、できればもっと頻繁に作業を統合します。フィーチャーブランチは数時間または数日存在し、数週間ではありません。メインから分岐し、作業を行い、フィーチャーが完成し、テストが完了したらすぐにメインにマージします。

このワークフローでの典型的な1日を説明しましょう。朝はメインから最新の変更をプルして始めます。取り組んでいるタスク用のフィーチャーブランチを作成します。例えば、メール通知を追加することだとしましょう。説明的な名前、「add-email-notifications」や「feature/email-notifications」などを付けます。数時間作業し、頻繁に明確なメッセージでコミットします。昼には、ローカルで動作し、テストも完了しています。ブランチをプッシュし、プルリクエストを開き、レビューのためにチームメイトにピンを送ります。

チームメイトは昼食時にレビューします（変更が小さく、集中しているため、レビューは15分で済むことも）。フィードバックに対処し、彼らが承認し、メインにマージします。CI/CDパイプラインがテストを実行し、すべてが合格すれば、変更は自動的にステージングにデプロイされます。ステージングで動作することを確認し、その日の終わりには本番環境に展開されています。ブランチ作成から本番環境までの総時間は6時間です。

これをGit Flowのアプローチと比較してみましょう：あなたはdevelopからブランチを作り、数日間変更を積み重ね、最終的にdevelopにプルリクエストを開き、レビューを待ち、developにマージし、次に誰かがリリースブランチを作成するのを待ち、それをmasterにマージし、リリースをタグ付けし、その後デプロイすることになるでしょう。同じフィーチャーが本番環境に到達するのに3日かかるかもしれませんが、それは作業に時間がかかったからではなく、プロセスに時間がかかったためです。

リポジトリ構造の設定

シンプルなワークフローの美しさは、設定が минимальные ですが、すべてをスムーズにするためのいくつかの重要な構成があります。まず、メインブランチを保護します。GitHub、GitLab、またはBitbucketでは、直接メインへのプッシュを防ぎ、マージ前にプルリクエストのレビューを要求するブランチ保護ルールを設定できます。これは官僚主義ではなく、バグをキャッチし、チーム内の知識を広めるための安全ネットです。

小さなチームに推奨する保護設定は、マージ前に少なくとも1つの承認を要求し、ステータスチェック（CIテスト）を通過する必要があり、リポジトリをクリーンに保つために「マージ後のブランチ削除」を有効にすることです。私は小さなチームに多くの承認を要求することをお勧めしません。なぜなら、同じ部屋（物理的または仮想的）にいる場合、ボトルネックを作り、あまり価値を追加しないからです。

次に、初日からしっかりしたCI/CDパイプラインを設定します。これは複雑である必要はありません。プッシュごとにテストを実行し、メインへのマージのたびにステージングにデプロイする基本的なパイプラインで十分です。私は、手動でデプロイしながらGitワークフローを完璧にしようとするチームが数週間の時間を費やすのを見てきました。これは、スポーツカーを購入するようなものです。