Skip to main content
Engineering9 min read

辞めたくならないGitワークフロー

トランクベース vs GitFlow vs GitHub Flow — 3つすべて使ってきました。これがソロ開発者や小規模チームに実際に機能する方法であり、ほとんどのGitワークフローが過度に複雑である理由です。

Part ofProduct Systems->
By Jason TeixeiraOctober 25, 2025
GitVersion ControlWorkflowDevOpsBest Practices
Share:
On this page

大規模プロジェクトでGitFlowを使ってきた経験があります。フィーチャーブランチ、developブランチ、リリースブランチ、ホットフィックスブランチ。ブランチのグラフはまるで地下鉄の路線図のようでした。フィーチャーをマージするには、コンフリクト解決の博士号が必要でした。

今はトランクベース開発を採用しています。ブランチは1つだけ。mainから出荷します。デプロイ頻度は週1回から毎日になりました。

なぜほとんどのGitワークフローは複雑すぎるのか

GitFlowは、四半期ごとに物理メディアで出荷するソフトウェアのために設計されました。もしデプロイプロセスにCDの焼き付けが含まれているなら、リリースブランチが必要です。

mainにマージしてVercel/GitHub Actionsが残りを処理する形でデプロイしているなら、GitFlowの90%は不要です。

実際にやっていること

\\

Reader route

article -> proof -> offer

ReadClusterProofScope

cluster

Product Systems

intent

Engineering

route

next step

What to do with this

Turn the note into a build path.

If this topic maps to a real business problem, keep reading the cluster, study the academy path, or route the work into a scoped engagement.

Jason Teixeira
Written by
Jason Teixeira
Founder, Sage Ideas Studio · Principal Engineer
livebuild 5d6c8652026-08-05 06:00Z
// solo studio// no analytics resold// every commit human-reviewed