なぜほとんどのGitワークフローはソロ開発者に失敗するのか
ほとんどのGitチュートリアルとワークフローの問題は、複数のチーム、コードレビューのプロセス、および少なくとも3つの異なる環境を含むデプロイメントパイプラインを持つ企業で働く人々によって書かれていることです。ソロ開発者であると、そのような制約はありませんが、安全装置もありません。 2010年代を支配したワークフローGitFlowはその完璧な例です。これは、同時に複数のバージョンをサポートする必要があるソフトウェアのリリースを管理するために、Vincent Driessenによって特定の問題として設計されました。顧客がローカルにインストールするデスクトップアプリケーションを構築している場合、GitFlowは理にかなっています。しかし、SaaS製品やクライアントのウェブサイトを出荷するソロ開発者の場合、それは完全に過剰です。 典型的なソロ開発者のGitとの経過は次のようなものです：まず`main`（または`master`、Gitを学んだ時期によります）にコミットすることから始めます。次に、「プロフェッショナルなGitワークフロー」についての記事を読んで罪悪感を覚えます。私はフィーチャーブランチを実装します。それから、図に示されている通り`develop`ブランチを追加します。しばらくすると、ブランチを管理するために1日20分と費やしてしまい、そのうちの半分の理由もわからなくなります。 私はその状況にいました。`feature/new-feature`、`feature/new-feature-2`、`feature/new-feature-actually-final`、そして`feature/new-feature-for-real-this-time`という名前のブランチを持つリポジトリを持っていました。ブランチ命名の危機を経験したことがないのなら、あなたは嘘をついているか、ソロ開発をしている期間がまだ不十分です。 根本的な問題は、チームのワークフローがチームの問題を解決するために設計されていることです：複数の人の間での仕事の調整、コンフリクトの防止、コードレビューのプロセスの管理、および共有環境の安定性の維持です。ソロで作業をしていると、これらの問題のほとんどは単に存在しません。誰もいなければ、他の誰かとのマージコンフリクトは発生しません。すべてを変えた3コミットルール
午前2時の大惨事の後、私は実際の作業パターンを分析し始めました。前の6ヶ月間のGitの履歴を引き出し、私が作成したすべてのブランチ、行ったすべてのマージ、および解決したすべてのコンフリクトを見ました。私が見つけたものは啓示的でした。 私のフィーチャーブランチの90％は、マージする前に3コミット以下で構成されていました。これらは隔離が必要な複雑な何週間にもわたるフィーチャーではありませんでした。これは、小さな改善、バグ修正、そして私は「本物の開発者」がやることだと思っていたので非自発的に分けた段階的な変更でした。 残りの10％、実際の複雑な機能は、ブランチが意味のあるところでした。しかし、その時も私は何かに気づきました：問題を引き起こすブランチは、1週間以上開いていたブランチでした。ブランチが長く生きるほど、マージバックするときに問題が発生する可能性が高くなりました。 これが私に「3コミットルール」と呼んでいるものを導きました：変更が3コミット以上かかる場合、その変更はおそらく大きすぎて、分割すべきです。分割できない場合、それは実際にブランチが役立つまれなケースの1つです。 このルールは私が働き方について異なる考え方を強いられました。「ユーザーインターフェース全体の再設計」ではなく、「ボタンのスタイルを更新」または「新しいナビゲーションコンポーネントを実装」というブランチを作成するようにしました。それぞれのブランチは最大で1日か2日生き、焦点を当てた変更を含み、きれいにマージされました。 心理的なシフトは重要でした。私は「フィーチャー」という観点ではなく、「デプロイ可能な部分」という観点から考えるようになりました。すべてのブランチは、既存の機能を壊すことなく本番環境に出荷できる何かを表現する必要がありました。これにより、自然にブランチは小さく短命に保たれました。私がバグを本番に出荷した日（そしてそれが私のワークフローをなぜ改善したのか）
私のキャリアの中で最悪のデプロイメントについてお話しします。私はクライアントプロジェクトに取り組んでいました—小さなホテルチェーンのための予約システムです。新しい支払い統合を追加するフィーチャーブランチに2週間取り組んでいました（はい、自分のルールを破りました）。 そのブランチは`main`から大きく逸脱していました。私は支払い機能に集中しすぎて、急なクライアントリクエストのために直接`main`で行っていた小さな修正や改善を追従していませんでした。マージの時期が来たとき、14のファイルにコンフリクトが発生しました。 私はコンフリクトを解決し、テストを実行しました（パスしました）、そして本番にデプロイしました。1時間以内に、クライアントからパニックの電話を受けました。予約フォームが壊れていました。新しい支払い統合ではなく、数ヶ月間正常に動作していた基本的な予約フォームです。 何が起こったのか？ マージコンフリクトの1つを解決する際に、間違ったバージョンの関数を保持してしまったのです。テストはそれをキャッチしませんでした。なぜなら、その特定のエッジケースのためにテストを書いていなかったからです（教訓として学びました）。バグは完全に私の責任でしたが、そのワークフローはそのような間違いを犯しやすくしました。 その事件は私に重要なことを教えてくれました：ソロ開発者として、私の最大のリスクは他の人のコードではなく、2週間前の自分のコードです。プロジェクトの異なる部分をコンテキストスイッチしていると、基本的に過去の自分とのコラボレーションをしているのです。そして、過去の私というのはしばしば信頼できない同僚です。 この認識は私のワークフローの第二の柱につながりました：1週間ルール。どのブランチも1週間以上生きません。そのフィーチャーがそれ以上かかる場合は、1週間以内に完了しマージできる小さな部分に分けます。それが不可能な場合は、機能フラグを使用して未完成のコードを`main`にマージし、それをユーザーから隠します。 1週間ルールは私を何度も助けてくれました。私を常に`main`に近づけることを強制し、つまり、常にコードベースの最新バージョンで作業していることを意味します。このようにして、複雑なマージコンフリクトに至るような逸脱を防ぎます。そして、スコープに対して正直でいさせます—もし何かを1週間以内に終えられないのであれば、おそらく同時にやりすぎているのです。ブランチの複雑さの本当のコスト
数字について話しましょう。私はワークフローを簡素化する前後での私のGit関連活動を3ヶ月間追跡しました。その結果は驚くべきものでした：| 活動 | 前 (時間/週) | 後 (時間/週) | 節約時間 |
|---|---|---|---|
| ブランチの作成と管理 | 2.5 | 0.5 | 2時間 |
| マージコンフリクトの解決 | 3.0 | 0.3 | 2.7時間 |
| どのブランチで作業するかの決定 | 1.5 | 0.1 | 1.4時間 |
| 古いブランチのクリーニング | 1.0 | 0.1 | 0.9時間 |
| リベースおよびブランチの同期 | 2.0 | 0.2 | 1.8時間 |
| Gitの総オーバーヘッド | 10.0 | 1.2 | 8.8時間 |
なぜ「早くコミットし、頻繁にコミットすること」がソロ開発者には間違っているのか
ここに物議を醸す意見があります：「早くコミットし、頻繁にコミットする」というアドバイスは、実際にはソロ開発者にとって有害です。これは常識に反することは分かっていますが、私の話を聞いてください。コミットの目的は、すべてのキーストロークの詳細なログを作成することではありません。これは、コードがどのように進化したかについての物語を語る意味のあるチェックポイントを作成することです。ソロで作業をしていると、理解する必要があるのはあなた自身だけです。