トランクベース開発 vs GitFlow：毎週の出荷に向くのはどちらか？

間違ったブランチ運用で週次リリースが混乱する理由

週次リリースは簡単に聞こえますが、ある週に失敗するとすべてがややこしくなります。木曜にはビルドが「ほぼ準備できている」、金曜に QA が遅く問題を見つけ、月曜はクリーンな開始ではなく後始末に変わる──という具合です。

大きな要因はブランチモデルです。いつ変更が出会うか、どこで統合が起きるか、何かが壊れたときにどれだけ早く戻せるかを決めます。統合が週末の最後に押し込まれると、マージの衝突、思わぬバグ、不安定なテスト環境の代償を支払うことになります。

ワークフローが味方してくれないとき、だいたい次のように感じます：

• マージにかかる時間が、その原因となった機能開発より長い。
• ブランチが分岐しているため、QA が間違った変更の組み合わせをテストする。
• リリースがルーチンではなく交渉ごとになる。
• ホットフィックスで慌てる。何が一緒に出るのか誰も確信が持てない。
• 人々が QA を信頼しなくなり、例外を求め始める。

ブランチは QA の安定性にも影響します。QA が半分統合されたコードの間を行ったり来たりすると、検証対象が動く標的になってしまいます。どんなに優秀なテスターでも、システムの挙動が数時間ごとに変わったり、遅いマージで昨日テストしたものが静かに置き換わったりすると明確な結論は出せません。

だからこそ、週次リリースに移行する際にチームは Trunk-based development と GitFlow を比較します。本当に重要なのはどちらが人気かではなく、どちらがマージの痛みを減らし、リリースを予測可能にし、ホットフィックスを安全かつ迅速にし、QA を意味あるものに保てるかです。

ここでは小〜中規模チーム、共有リポジトリ、プッシュごとに CI が回る想定です。Web アプリと API を出しているかもしれませんし、AppMaster のように視覚的に構築する部分と、生成されたコードやデプロイを従来通り扱う部分が混在することもあり得ます。

現在のプロセスが週末の大きなマージを生んでいるなら、週次のペースは伸び続けます。逆に小さく頻繁に統合することを奨励するなら、週次リリースは『退屈』になる（良い意味で）でしょう。

Trunk-based と GitFlow を平易に説明すると

どちらも「作業をどのようにブランチで扱うか」のルールに過ぎません。違いは長く残すブランチがどれだけあるか、そして作業がどれだけ長く分離されたままになるか、という点です。

• Trunk-based はほとんどを main に近く保ちます。
• GitFlow は進行中の作業とリリース安定化のために別々のレーンを持ちます。

Trunk-based development（平易な説明）

Trunk-based development は main（トランク）を中心とします。人は短命のブランチ（数時間〜1〜2日）で作業し、頻繁にマージして main をリリース可能な状態に保ちます。

準備ができていない機能は、小さく保って早く終わらせるか、フィーチャーフラグで隠してユーザーに見せずに安全に出荷します。

GitFlow（平易な説明）

GitFlow では通常、機能はまず長期の develop に投げられ、develop から派生するフィーチャーブランチで作業します。リリース時には release/* を切って安定化とテストを行い、本番で問題が起きたら main から hotfix/* ブランチを切って修正し、元に戻します。

このモデルは分離を最適化します：リリースブランチが検証されている間も、develop 上では新しい作業が継続できます。

よくある誤解から多くの問題が生じます：

• Trunk-based を「ブランチを使わないこと」とみなす（実際はブランチを使うが短命）。
• GitFlow を使っているがリリースブランチを作らず、develop が不安定なステージングになっている。
• フィーチャーブランチを数週間放置して、どんなモデルでもマージ地獄にしてしまう。
• 「リリース可能（releasable）」を「すべてが完成している」と混同してしまう。実際は「安全にデプロイできる」ことが重要。

マージ摩擦：何が本当に原因か

マージコンフリクトは大きく分けて二つの原因から来ます：ブランチが長く生きすぎること、そして複数人が同じ箇所を調整なしで変更すること。

Trunk-based と GitFlow の実務上の最大の違いは、作業が他の作業と出会うまでの分離時間です。

Trunk-based では変更が頻繁にメインラインに入るため、PR は小さく、差分も小さく、コンテキストがまだ新しいうちに衝突が現れます。衝突は起きますが、通常は数行の調整で済むことが多いです。トレードオフは規律で、ビルドをグリーンに保ち、変更を段階的に行い、main をプロダクトとして扱うことです。

GitFlow ではフィーチャーが長く放置されることがあり、そのコストは後で大きなマージイベントとして現れます：フィーチャー→develop、develop→release/*、release/*→main。各マージはより多くの変更のぶつかり合いなので、衝突は起きやすく解消しにくい。週次リリースでは、そうした大きなマージがちょうどテストを行いたいタイミングに発生しやすいのです。

コードレビューの負荷も変わります。Trunk-based はレビューは多くなりがちですが、各レビューは理解しやすく短時間で済みます。GitFlow はレビューが少ない分重くなりがちで、リリースマージ時にみんな疲れている中で追加のレビューが発生します。

どちらのモデルでもマージ摩擦を減らすためにできること：

• PR を小さく集中させる（一つの目的に絞る）。
• マイグレーションや共有設定、コア UI などリスクの高い領域のオーナーを合意する。
• 上流の変更を毎日のように取り込んでドリフトを防ぐ。
• あるファイルが常に「熱い」なら、並行で競合するよりペアで作業する。

衝突が常態化しているなら、原因は遅い統合であることが多く、Git 自体の問題ではありません。

週次のペースでのリリース予測性

予測可能であるとは三つのことを意味します：いつリリースするかが分かる、何が入るかが分かる、出荷前にどのチェックが必須かが分かること。多くのチームが週次リリースを逃すのは、スコープ決定と最後の修正を混ぜてしまうからです。

Trunk-based では main がグリーンであれば週次リリースは予測可能です。小さな変更を頻繁にマージし、スコープはフィーチャーフラグで制御して長期ブランチに頼らないようにします。コードは入るがユーザーに見せないようにしておけば、週次の列車は動き続けます。

品質ゲートは単純になることが多いです：

• 自動テストは main で通ること。
• QA は安定した候補ビルドをテストし、直前に入ったコミットを追いかけないこと。
• ロールアウトとロールバック手順を文書化する。
• 明確なリリースカットオフ時間を決める（コミットは続いてもよい）。

GitFlow ではリリースブランチがフリーズゾーンとして予測性をもたらします。カットオフを決めて release/* を作り、出荷に必要な変更だけを受け入れます。しかしその分、修正は複数の場所（release と develop）に適用する必要があり、調整が増えます。

未完成の作業の扱いはこう違います：

• Trunk-based: 安全な部分をマージし、残りはフィーチャーフラグで隠す。
• GitFlow: 未完成は develop に残し、リリースブランチには含めない。

例：チェックアウト改善が水曜に半分しか終わっていない場合、Trunk-based なら安全なリファクタはマージして新 UI をフラグで隠せます。GitFlow なら develop に残して次回のリリースで完成させます。

ホットフィックスの流れ：本番へ最速で安全に出す方法

ホットフィックスは通常の作業ではありません。速度、低リスク、そして修正をチームの作業ラインに戻すパスが必要です。そうしないと同じバグを二度直すことになります。

最初に問うべきは：「今本番で動いている正確なコードは何か？」です。数秒で答えられなければ、ホットフィックスは推測になりがちです。

Trunk-based でのホットフィックス

Trunk-based では main を真実のソースとして扱うのでシンプルに感じられます。

一般的なフロー：

• 本番コミット（多くは main）から短命のブランチを切る。
• 可能な限り最小の修正を行う（できればテストを追加）。
• すぐに main にマージする。
• main からデプロイしてリリースにタグをつける。

チームが頻繁に main に統合していれば、ホットフィックスは次の週次リリースにも自然に含まれます。注意点は main をリリース可能に保つというルールを破らないことです。フィーチャーフラグは有用ですが、デフォルトでオフになっていることを確認し、ホットフィックスは関係ない機能を有効にせず検証してください。

GitFlow でのホットフィックス

GitFlow ではホットフィックスは通常 main（本番）から始まり、その後 develop にもマージして修正が失われないようにします。

安全なフローの例：

• 本番のタグから hotfix/* をブランチする。
• 修正してリリースする（ホットフィックスブランチから、または main にマージしてから）。
• ホットフィックスを main にマージし、さらに develop にもマージする。
• release/* が存在するならそこにもマージする。

よくある失敗はこれらのマージのどれかを忘れることです。1 週間後に、develop にパッチがないために同じバグが「戻ってくる」ことがあります。

単純なルール：ホットフィックスは、今後リリースされる全ての長期ブランチにマージされるまで完了ではありません。

QA 環境を安定させる方法（チームを止めずに）

週次リリースが崩れるのは「QA = 今デプロイされているもの」という状態になったときです。環境に名前を付け、それぞれの役割を決めてください：dev は早いフィードバック、QA はチームテスト、staging はリリースチェック、本番は顧客向け。1 文で環境の目的を説明できなければ、人は誤った使い方をします。

動く標的を防ぐルール

安定した QA はブランチモデルよりも何をデプロイするかに関わります。

Trunk-based の場合、QA にランダムなコミットをデプロイしないでください。毎回同じチェックを通ったピン留めされた候補（タグ付きビルド、ビルド番号、短命の release-candidate ブランチ）をデプロイします。これにより、開発が続いても QA は検証すべき固定の対象を持てます。

GitFlow では QA が通常リリースブランチを追いかけます。罠は QA が始まった後にリリースブランチが変わり続けることです。QA が始まったらリリースブランチを契約のように扱い、承認された修正のみを受け入れ、明確なプロセスでのみ変更します。

どちらのアプローチでも予測可能にする小さなルール：

• 通過したビルドだけを QA にデプロイする。
• デプロイされたバージョンをピン（タグ、ビルド番号、リリースブランチの先端）してアナウンスする。
• QA への変更はバグ修正に限定し、新機能は入れない。
• テストデータはスケジュールでリセットし、何が消されるかを文書化する。
• 設定はコードで管理して環境のドリフトを減らす。

チームが AppMaster をビルドの一部に使っているなら、同じ原則を守ってください：QA 用に特定のビルドを再生成してデプロイし、作業中の編集をそのまま流し込まないこと。

複数チームで QA を共有する場合

1 つの共有 QA 環境は、異なるバージョンを必要とする 2 チームがいるとボトルネックになります。別々の QA 環境を用意できない場合は、軽量な予約ルールを追加してください：一定の時間帯はあるチームが QA を占有し、他は dev や staging を使う。フィーチャーフラグも役立ちます。未完成の作業をデプロイしてもテスターに見えないようにできます。

例：チーム A が週次のリリース候補を検証しているなら、QA はサインオフまでビルド 1842 に固定します。チーム B は修正を続けられますが、それらは次の候補まで待つため、QA がテスト中に対象が変わることはありません。

ステップバイステップ：チームが毎週守れるワークフローの選び方

「週次リリース」が自分たちにとって何を意味するかを書き出してください。リリース日と時間、受容できるリスクレベル（例：「既知の P1 バグなし」）、チーム人数やタイムゾーンを書き出すことで、ブランチの議論が優先度の喧嘩に発展するのを防げます。

ベースとなるモデルを一つ選び、1 ヶ月はそれにコミットしてください。初日から混在させるなかれ。混在はルールを増やすだけで驚きを減らしません。

適応可能なシンプルな週次ワークフロー例：

• ブランチ寿命を短く保つ（数時間〜1〜2日）し、少なくとも毎日マージする。
• 安全策を追加する：高速 CI、短めの必須レビュー、実際の障害を検出する自動テスト群。
• スコープ管理方法を決める：フィーチャーフラグ、週末前に短命のリリースブランチを切る、または正確なリリースコミットにタグを付ける。
• ホットフィックス手順を定義する：誰が起動できるか、どのチェックが必要か、変更をメインラインに戻す流れ。
• QA を安定させる：QA が追うもの（リリースブランチかピン留めされた候補）を決め、テスト中にそれを途中で変えない。

最小限のワークフローを1ページに書いてください。新しいメンバーがミーティングなしで従えるほど短くすること。これは、チームの一部が視覚的（AppMaster など）で作業し、他がコードで作業する場合に特に重要です。ルールが誰かの頭の中だけにあると引き継ぎが失敗します。

例：両モデルでの現実的な週次リリース

6 人のプロダクトチームが毎週金曜に出荷すると想定。2 人の QA が 1 つのステージングを共有しており、ステージングが不安定だとテストが止まります。

GitFlow で忙しい週の流れ

月曜：3 人が機能を仕上げ develop へ PR を出す。QA は develop から作られたステージングでテストを開始する。

水曜：安定のため release/1.8 を切る。新しい作業は develop に入り続けるが、QA はリリースビルドに集中する。

木曜午後：遅いバグが見つかる。修正はまず release/1.8 に入り QA を再テストさせ、続いて誰かがその修正を develop にマージする。ここでミスが起きやすい。

典型的なリズム：

• 月〜火：機能が develop に入り、ステージングが頻繁に変わる。
• 水曜：release/1.8 を作り、ステージングはリリースビルドへ切り替わる。
• 木曜：release/1.8 でバグ修正を行い、その後 develop に戻す。
• 金曜：release/1.8 を main にマージ、タグ付けしてデプロイ。

同じ週を Trunk-based で

週は小さく頻繁な main へのマージで形作られる。未完成の機能はフラグで隠して、途中でも main に入れられる。

月〜木：開発者は小さな変更を毎日マージ。QA はピン留めされた候補ビルドをテストする。

火曜：本番問題が発生。ホットフィックスは main から短いブランチを切り、レビュー後すぐ main に戻して本番に昇格する。main が真実のソースであるため、余分なバックマージは不要。

どちらの場合でも、プロモーションルールは明確である必要があります：

• ステージングは最新のピン留め候補を動かす。すべてのコミットを自動で反映させない。
• QA は準備ができたら新しい候補を要求する。自動ではない。
• 金曜のリリース候補に変更できるのはそのリリース用の修正のみ。
• 他の作業はフラグの後ろに置くか候補から外す。

チャーンと不安定な QA を生むよくあるミス

多くのチームが失敗するのは「間違ったモデルを選んだから」ではなく、日々の習慣がモデルに合っていないからです。その結果 QA が騒がしくなり、リリースはランダムに感じられます。

よくある問題は「準備できていないのでブランチを何日も放置する」ことです。コードは main から離れていき、衝突が積み重なり、QA は誰も再現できない混合されたビルドをテストします。

また GitFlow をフリーズなしで使うのも危険です。リリースブランチは安定化のために存在するのに、チームが「あと一つだけ」を入れ続けると、それは第二の main になり、誰も QA が何を承認しているのか分からなくなります。

QA が不安定になるもう一つの理由は、未完成ビルドの捨て場にされることです。もしすべてのコミットがルールなしに QA に行くなら、テスターは動く標的を追いかける羽目になります。

最もチャーンを生むミス：

• 長期のフィーチャーブランチが遅れてマージされ、無関係な作業を壊す。
• リリースブランチに新機能を入れてしまう。
• プロモーションパスが不明瞭で、QA がテストしたビルドと出荷されるビルドが一致しない。
• ホットフィックスが慌てて行われ、全てのブランチに戻されない。
• 環境にオーナーがおらず目的もリセット計画もない。

誰もが繰り返せるルールセットを保ってください：

• QA はピン留め候補のみをテストする。
• QA から本番へは同じアーティファクトをプロモートする。
• 各環境にオーナーとリセット頻度を決める。
• ホットフィックスは当日中にメインラインへ戻す。

サプライズなしの週次出荷チェックリスト（クイック）

週次リリースが機能するのは、チームがいくつかの退屈な質問に自信を持って答えられるときです。2 つ以上に「いいえ」と答えるなら、遅い修正や QA の振り回しを覚悟してください。

• 今日安全にデプロイできるブランチは一つあるか？ ビルドが通り、スモークテストをクリアし、半端な変更が混ざっていないこと。
• プルリクは小さく、1〜2 日でマージされるか？ 長期 PR はフィードバックが古くなり、衝突が大きくなる。
• QA は動く標的ではなく固定ビルドをテストしているか？ QA は特定のビルド番号やリリース候補を検証するべき。
• 未完成作業をドラマなくリリースから外せるか？ フィーチャーフラグ、設定トグル、あるいは明確なスコープ切り分けルール。
• ホットフィックスとロールバックを推測なしで実行できるか？ 短いランブックが部族的知識に勝る。

一つの測定可能な目標：QA をリリース候補にピン留めし、その候補を意図的な修正以外で変えないこと。

次のステップ：来週試す一つの変更を選ぶ

Trunk-based と GitFlow を巡って議論が続くなら、一度にすべてを作り変えないでください。最も時間を食っている問題を一つ選び、小さな実験を次のリリースで試してください。

マージ衝突が最大の痛みなら、すぐにブランチ寿命を短くしてください。目標は毎日（または隔日）登場させることで、必要ならフィーチャーフラグを使います。

QA の不安定さが最大の痛みなら、まず QA がテストするものをピン留めし、シンプルなプロモーション手順を定義してください。

軽量なパイロット例：

• 1 リポジトリ、1 チームを選ぶ。
• ブランチの年齢制限を設定する（例：2 日以上放置しない）。
• QA を 1 つのビルドにピン留めし、それを明確なプロモーションでしか変更しない。
• 3 つの指標を追う：マージ解決時間、QA の手戻り時間、ホットフィックスの本番投入時間。
• 2〜4 週間後にレビューして調整する。

内部ツールやカスタマーポータルのリリース圧を下げたいなら、AppMaster（appmaster.io）のようなノーコードプラットフォームは有用です。視覚的設計から本番対応のバックエンド、Web、モバイルを生成できますが、上記の習慣（小さな変更、ピン留めされた QA 候補、明確なプロモーションパス）は同様に重要です。