从 SVN 单分支协作到 Git 分支管理：别再把一天的代码攒到下班提交了

公司现在的代码管理还是 SVN。严格说，SVN 不是不能用，它稳定、集中、权限直观，在一些传统项目里也跑了很多年。问题在于，我们现在的开发方式已经不是当年那种“少数人、少量改动、按计划提交”的节奏了。

现在更常见的场景是：很多人同时在同一个分支上开发。上午你改订单，我改库存，另一个同事改登录，大家都在一条线上施工。平时还好，一到发版前就开始紧张：有人说“我这个功能还没改完，不能提交”；有人说“我现在提交会报错”；还有人下班前才把一天的代码一次性提交上来，冲突像攒了一天的账单，晚上统一结算。

这类问题表面看是个人习惯不好，实际上更像是工具和流程一起把人推到了尴尬位置。

同一个分支，所有人都没有缓冲区

在 SVN 单分支协作里，主干既是开发区，又是集成区，很多时候还临时承担了准发布区的角色。这个设计一旦碰上多人并行开发，就会天然产生几个矛盾。

第一个矛盾是“代码没写完，但又需要保存进度”。开发人员本地改了一堆文件，功能还没完成，提交上去可能影响别人，不提交又只能在自己机器上扛着。时间一长，本地工作区越来越脏，合并别人的代码也越来越胆战心惊。

第二个矛盾是“发版要稳定，但主干一直在变”。发版当天大家都盯着同一条分支，有人要修 bug，有人功能还差一点，有人已经提交了一半。最后发布负责人只能一边催，一边问：“现在这个版本到底能不能打包？”

第三个矛盾是“冲突被推迟了”。早上开始写代码，中间不怎么提交，下班前一次性提交一天的改动，看似省事，其实只是把冲突、编译错误、逻辑冲突都往后拖。等到真正提交时，冲突已经不是几行代码的问题，而是一整天上下文的碰撞。

我见过不少团队把这种行为归因成“开发不规范”。当然，习惯要改，但也要承认：如果一个工具链让大家很难创建分支、很难切换分支、很难舒服地合并，那最后大家自然会选择最省操作的方式，哪怕这个方式长期看很痛。

SVN 也有分支，为什么大家还是不用

SVN 当然可以创建分支。理论上，trunk、branches、tags 也能组织出不错的流程。但落到日常开发里，很多团队还是很少用 SVN 分支，原因通常不是“不知道有这个功能”，而是“不好用、不敢用、嫌麻烦”。

尤其是依赖 GUI 工具时，创建分支、切换分支、合并回主干这些操作，经常显得重。分支在 SVN 里更像是服务器上的一个目录副本，合并历史和冲突处理也容易让人没有安全感。对于不常操作分支的同事来说，每次合并都像一次小型发布。

于是团队最后形成了一个很典型的惯性：既然分支麻烦，那就都在主干上改；既然主干不能随便坏，那就等功能差不多了再提交；既然大家都晚点提交，那冲突就集中在下班前和发版前爆出来。

这不是某个人偷懒，而是流程在奖励“大提交”和“晚集成”。

Git 分支真正解决的是什么

Git 最大的变化不是命令更酷，也不是大家可以在终端里多敲几行命令。它真正改变的是：分支变得足够便宜，便宜到你愿意每天用。

在 Git 里，创建一个功能分支通常就是一秒钟的事情：

git checkout -b feature/order-refund

这意味着每个功能都可以有自己的工作空间。功能没写完，没有关系，先提交到自己的分支；代码还会报错，也不要紧，只要别合进主分支；需要同步别人的改动，就从 main 拉一下再 rebase 或 merge。主分支不再承担所有人的半成品，它只接收经过检查的变更。

一个更健康的日常节奏大概是这样：

git checkout -b feature/order-refund
git add .
git commit -m "feat: add refund order status"
git fetch origin
git rebase origin/main
git push -u origin feature/order-refund

这里的重点不是命令本身，而是工作方式变了。你可以一天提交多次，每次只提交一个明确的小改动。提交不再等于“我要影响所有人”，而是“我把当前阶段的工作保存下来”。真正影响主分支的动作，发生在 Pull Request 或 Merge Request 被合并的时候。

发版时，未完成的功能不应该挡住所有人

发版最怕一句话：“我这个功能还没改完，不能提交。”

在 SVN 单分支模式下，这句话很致命。因为大家都在同一条线上，某个人的半成品可能真的会影响整个发布节奏。但在 Git 分支模式下，这句话应该变成：“这个功能还没完成，所以这次不合进发布分支。”

常见做法是：

• main 保持随时可运行；
• 每个需求从 main 拉出 feature/* 分支；
• 发版前从稳定的 main 拉出 release/* 分支；
• 发布分支只接受明确的 bugfix；
• 没做完的功能继续留在自己的功能分支；
• 线上紧急问题从 main 或发布 tag 拉出 hotfix/* 分支。

比如：

git checkout -b release/2026-06-01 origin/main
git cherry-pick <fix-commit>

这样发版就不再是“等所有人都刚好写完”，而是“把已经完成、已经验证的内容发布出去”。未完成的功能不会消失，也不会被粗暴打断，只是不会混进这次发布。

分支不是按人分，而是按事情分

有些团队刚切到 Git 时，会把 SVN 的思维原封不动搬过来：每个人一个长期分支，月底再合一次。这样做很容易把 Git 也用成另一种形式的单分支痛苦。

更推荐的方式是按任务建分支，而不是按人建分支：

feature/order-refund
feature/invoice-export
bugfix/login-timeout
hotfix/payment-callback
release/2026-06-01

一个分支对应一件清晰的事情。事情完成了，代码评审通过了，自动化检查过了，就合回主分支，然后删除这个分支。分支活得短，风险就小；分支拖得久，冲突和认知成本都会上升。

Git 不是万能药，但它给团队留出了操作空间

换 Git 之后，问题不会自动消失。大提交还是可以大提交，长期分支还是可以长期不合，主分支也还是可能被提交坏。工具只能提供更好的可能性，真正让协作变顺的，是团队愿意一起调整规则。

我会建议先从几条简单规则开始：

• 主分支必须保持可编译、可启动、可测试；
• 一个需求一个功能分支，不在主分支直接开发大功能；
• 每天多次小提交，不把一天代码攒到最后；
• 合并前必须同步主分支，解决冲突后再提合并请求；
• 合并请求里要有人看代码，至少看风险点和影响范围；
• CI 不通过不合并；
• 发布分支只收修复，不收临时加塞的大功能。

这些规则看起来朴素，但它们能把“发版前集体焦虑”拆成每天可处理的小问题。

迁移时别一口吃太满

从 SVN 切到 Git，最怕一上来就讲一堆复杂模型：Git Flow、Trunk Based Development、rebase、squash、cherry-pick、tag 策略、权限策略、CI/CD 全家桶。概念越多，团队越容易觉得这是另一套负担。

比较稳的方式是先小范围试点：

1. 选一个活跃但风险可控的项目迁到 Git；
2. 约定 main、feature/*、release/*、hotfix/* 四类分支；
3. 让大家先熟悉创建分支、提交、推送、提合并请求；
4. 给主分支加最基本的构建检查；
5. 发一次小版本，复盘冲突、回滚、修复流程；
6. 再逐步补充代码评审规范和 CI 规则。

不要试图第一天就把所有流程设计到完美。团队真正需要的不是一份漂亮流程图，而是每个人第二天上班真的愿意照着做。

最后

SVN 单分支协作最大的问题，不是它不能提交代码，而是它让“提交”这件事变得太沉重：没写完不敢交，怕影响别人不敢交，发版前更不敢交。于是大家都把风险留在本地，等到某个时间点一起爆出来。

Git 分支管理的价值，是把半成品、已完成、待发布、线上修复这些状态分开，让每一种代码都有合适的位置。它不是为了让流程显得高级，而是为了让开发者可以更早提交、更小步集成、更从容地发版。

工具该服务人，而不是让人每天靠胆量维护主干。对于多人并行开发的团队来说，从 SVN 单分支走向 Git 分支管理，不只是换一个仓库地址，更是把协作方式从“大家挤在一条路上抢时间”，改成“每件事有自己的车道，最后有秩序地汇入主路”。