一个人写代码，分支策略还要不要

2026-09-08 Git,分支策略,版本管理,独立开发

我上一个项目的仓库里同时挂着三个长期分支，其中两个的最后一次提交停在两个月前。清理的时候我花了一个下午合并和删除，处理完发现，那两个分支上的改动本来就不该存在。一个人的项目要不要用 Git 分支策略，我的答案从那以后就固定了。

先说结论：主干直推，做有风险的大改动时才开短分支，改完当天合回去。长期存在的分支，在单人项目里基本只会变成负担。

一、三种做法放在一起比

|---|---|---|---|

表里第三行是我最在意的。完整流程的好处是很明确的，但它的好处体现在多人并行上——需要同时维护多个对外版本、需要给不同客户留不同分支。单人项目里这些场景基本不存在。

理由不是「一个人不会出错」，是出错之后的处理方式变了。

多人项目怕的是把别人的活冲掉，所以需要分支隔离。一个人不存在这个问题，你要防的只是自己改坏。而改坏这件事，提交记录本身就能解决——找到最后一个好提交，回退过去。

前提是提交要小。我现在的习惯是一次提交只做一件事，提交信息写清这次为什么改。这样回退的时候，丢掉的损失是可控的。

有三种情况我会开分支。

第一种是大范围重构。改到一半发现方向错了，主干直推的话回退很麻烦，开一个分支丢掉就行。这一点跟重构做一半停手，代价比想象大里说的是同一件事。

第二种是依赖或运行环境升级。这类改动经常需要反复试，中间状态跑不起来，不适合直接压在主干上。

第三种是不确定要不要做的实验。做完看效果，不行就删。

三种情况的共同点是改动会持续超过一天。一天内能收尾的，直接推主干更快。

第一条，分支不过夜。今天开的分支今天合回去，或者今天删掉。过夜的分支第二天就要重新同步主干，成本立刻上来。

第二条，分支名写清目的，不写「dev」这种看不出内容的名字。名字是给未来的自己看的。

第三条，合并前先跑一遍 CI。分支最大的价值是把一次完整验证挡在合入之前，这一条在CI 自动化配到什么程度，这几项就够里展开过。

三条规矩里，第一条最重要。分支的负担不在创建，在它开始积压。

Q：一个人写代码还要不要 Git 分支策略？

A：要一条最小策略：日常直推主干，只有持续超过一天的改动才开分支，并且当天或次日合回。完整的多分支流程对单人项目没必要。

Q：主干直推，改坏了怎么恢复？

A：靠提交粒度恢复。提交足够小、每次只做一件事，就能定位到最后一个正常提交并回退，不需要分支来兜底。

Q：feature 分支留久了会有什么问题？

A：需要不断把主干的改动同步进来，冲突会越积越多，最后合并的成本可能超过重做一遍。所以要么尽快合，要么尽快删。