Git Workflow for Small Teams (Keep It Simple)

先週の火曜日、私はジュニア開発者がなぜ彼らのフィーチャーブランチがマージできないのかを理解するのに45分を費やすのを見ました。その原因？ 私たちのチームの過度に複雑なGitワークフローで、4種類のブランチ、必須のリベースプロトコル、理解するためにフローチャートが必要なマージ戦略が含まれていました。私は12年間エンジニアリングチームを指導してきましたが、小さなチームのほとんどが必要のないGitの複雑さに溺れていることは間違いありません。

私はサラ・チェンです。過去10年間、3つの異なるスタートアップで開発チームを構築し、スケールさせてきました。5人の開発者が500人のエンジニア向けに設計されたワークフローを使用しているのを見てきました。素晴らしいプログラマーたちが、実際の仕事には何の価値も追加しないブランチ戦略のナビゲートに何時間も無駄にするのを見てきました。そして、2人から10人の開発者向けのGitワークフローに関しては、シンプルさは単なる「あると良い」ものではなく、機能を出荷するのと混乱を出荷するのとの違いであることを学びました。

誰も教えてくれないことがあります。Gitは非常に強力ですが、それだけに過度に複雑にするのも簡単です。インターネットにはGit-flow、GitHub flow、GitLab flow、トランクベースの開発、その他十種類以上の戦略に関する記事がたくさんあります。そのほとんどは、あなたが持っていない問題を解決しています。私は、私のチームが生産的で幸せであり、企業規模の複雑さのオーバーヘッドなしにコードを出荷できるGitワークフローをお見せします。

ほとんどのGitワークフローが小規模チームに失敗する理由

何が効果的かを深く掘り下げる前に、何がうまくいかないのかについて話しましょう。私は、Git-flowを使用して開発ブランチ、リリースブランチ、ホットフィックスブランチ、フィーチャーブランチを持っていたチームからコードベースを引き継いだことがあります。4人の開発者が毎週リリースするSaaS製品に取り組むチームには、これはまったくのオーバーキルでした。

複雑なワークフローの問題は、それが間違っていることではありません。それは、スケールに伴って生じる問題を解決しているということです。Git-flowは、長いリリースサイクルと広範囲なホットフィックス管理の必要性を持つチームが同時に複数のプロダクションバージョンを管理するための特定のコンテキスト向けに、2010年にビンセント・ドリエッセンによって作成されました。あなたが単一のプロダクション環境に継続的に出荷している小さなチームであるなら、あなたはGit-flowの全てのオーバーヘッドを抱え、利益を得ていません。

昨年、私は同様のサイズとスキルレベルの2つのチームで実験を行いました。チームAは、私が説明する簡素化されたワークフローを使用しました。チームBは、標準のGit-flowを使用しました。3ヶ月で、チームAは23%多くのフィーチャーを出荷し、四半期調査で著しく低いフラストレーションレベルを報告しました。違いは才能や努力ではなく、摩擦でした。すべての追加のブランチタイプ、すべての追加のマージステップ、すべての複雑なリベース操作は、認知負荷を追加し、チームを遅くします。

小さなチームは大規模組織とは異なる制約を持っています。おそらく、専任のリリースマネージャーはいません。複数のプロダクションバージョンをサポートする必要もないでしょう。開発者は多くの役割を兼任し、頻繁にコンテキストを切り替えます。あなたのワークフローは、これらの現実を反映すべきであり、それに逆らうべきではありません。5人のチームがGoogleと同じGit戦略を使用しているのを見ると、それは彼らが今日持っている問題ではなく、将来的に持つことを願っている問題に最適化していることがわかります。

複雑さのコストは時間とともに蓄積します。開発者が不必要に複雑なGitワークフローをナビゲートするのに1日10分を費やすと、年間で40時間以上を失います—まるまる1週間—ブランチの管理にだけです。それをチーム全体に掛け算すると、年間で数週間の生産性の損失が見込まれます。それは、単純なワークフローでは存在しないマージコンフリクトを修正するために費やされる時間や、どのブランチをどのブランチにマージするかを常に覚えておくために消耗されるメンタルエネルギーを考慮していません。

2ブランチ哲学：メインとフィーチャー

私が指導してきたすべての小さなチームに効果があったワークフローはこれです：2種類のブランチ、以上です。メインブランチ（古いリポジトリを使用している場合はマスター）があり、フィーチャーブランチがあります。それだけです。開発ブランチも、リリースブランチも、ホットフィックスブランチもありません。メインとフィーチャーだけです。

Gitは非常に強力ですが、それだけに過度に複雑にするのも簡単です。ほとんどのチームは、持っていない問題を解決しています。

あなたのメインブランチはプロダクションを表します。メインにあるものはいつでもデプロイ可能であるべきです。これは譲れません。メインがデプロイできない場合、あなたのワークフローは失敗しています。この単一の原則は、常に明確な目標に向かって取り組むことを意味するため、膨大な量の複雑さを排除します：あなたのコードをメインに安全にマージできる状態にすることです。

フィーチャーブランチは、すべての作業が行われる場所です。新しいフィーチャーを始める？メインからブランチを作成します。バグを修正する？メインからブランチを作成します。コードをリファクタリングする？メインからブランチを作成します。パターンは一貫していて予測可能です。どのブランチからブランチを作成するか、どのブランチにマージするかについての決定木はありません。すべてのフィーチャーブランチは同じライフサイクルを持ちます：メインからブランチを作成し、作業を行い、メインにマージします。

私はフィーチャーブランチをシンプルな規則で名前付けします：タイプ/短い説明。たとえば：feature/user-authentication、bugfix/login-redirect、refactor/api-client。タイプのプレフィックスは、どの種類の作業が行われているかをすぐに明確にし、説明は人間が読みやすいものです。私はチームがチケット番号（feature/JIRA-1234）を使用するのを見てきましたが、ブランチのリストを見ているときには直感的ではないと感じます。ブランチをスキャンし、すぐに何が作業されているかを理解できるようにしたいです。

このアプローチの美点は、その予測可能性です。あなたのチームに新しい開発者が参加すると、約5分であなたのGitワークフロー全体を理解できます。覚えるべき複雑なブランチ図は無く、特別なケースを記憶する必要もありません。メインからブランチを作成し、作業を行い、メインにマージします。このシンプルさは生産性に累積的な影響を与えます。あなたのワークフローがシンプルであれば、開発者はプロセスに対して少ないメンタルエネルギーを費やし、実際の問題の解決にもっと集中できます。

よく受ける質問の1つ：長期にわたるフィーチャーで数週間かかる場合はどうするのか？それには開発ブランチが必要ではないのか？いいえ。フィーチャーフラグが必要です。フィーチャーがユーザー向けに準備ができていない場合は、フラグの背後に隠してください。これにより、コードは継続的に統合され、いつフィーチャーが表示されるかを制御できます。私はチームがフィーチャーフラグがより優雅に解決する問題を解決するために複雑なブランチ戦略を作成するのを見てきました。

プルリクエスト：あなたのクオリティゲート

すべてのフィーチャーブランチは、プルリクエストを通じてメインにマージされます。例外はありません。あなたがCTOであろうと、1行の変更であろうと、私は気にしません。プルリクエストはコードレビューだけのものではなく、コードがプロダクションに入る前の意図的な意思決定の瞬間を作り出すことに関係しています。

私のプルリクエストのテンプレートは、何年にもわたる実験を経て洗練されたものです。長いテンプレートは正しく埋められないので、短くしています。すべてのプルリクエストには、変更内容、なぜ変更したのか、そしてテスト方法の簡単な説明を含める必要があります。これだけです。3つのセクションで、それぞれ通常3〜5文です。もしそのスペースで変化を説明できないなら、あなたの変更はおそらく大きすぎます。

コードレビューの際、私はシンプルなルールに従います：すべてのプルリクエストはマージ前に少なくとも1つの承認が必要ですが、それを承認した人は、発生した問題に対して責任を共有します。これにより、適切なインセンティブ構造が生まれます。レビュアーは自分の役割を真剣に受け止め、ただのハンコ押しではなく、共同署名しています。同時に、1つの承認で十分です。なぜなら、私たちは小さなチームであり、お互いを信頼しているからです。50人のチームにとっては2つまたは3つの承認が必要かもしれませんが、5人のチームではただ遅くなるだけです。

私はさまざまなレビューのターンアラウンドタイムの期待を実験しました。最も効果的なのは、レビュアーが営業時間内に4時間以内にフィードバックを提供することです。4時間の集中レビュー時間ではなく、プルリクエストを少なくとも認識し、初期のフィードバックを提供するための4時間です。これにより、コードは動き続け、即時の応答の期待を生み出すことはありません。もし誰かが徹底的なレビューのためにもっと時間が必要な場合は、その旨をコメントし、著者は詳細なフィードバックが後で来ることを期待できます。

私たちのコード品質を劇的に改善した1つの実践：プルリクエストの著者が承認後に自分のコードをマージすることを要求することです。これは小さな詳細のように思えますが、行動が変わります。あなたがマージボタンをクリックすることになると知っていると、変更に対してより注意深くなります。あなたが