Git分支管理实战：用Git Flow让团队协作不再混乱

一、为什么需要分支管理

单人开发时，一个 main 分支打天下没问题。但团队协作中，多人同时往一个分支提交代码，冲突频发、上线提心吊胆。分支管理的本质，是给“开发中”“待上线”“已上线”的代码各找一个安身之所。

二、Git Flow 的五个分支

• main：只放可发布的稳定代码，每次合并都打一个版本标签。
• develop：日常开发的主战场，所有功能分支最终汇入这里。
• feature/*：每个新功能一条分支，开发完合并回 develop 后删除。
• release/*：从 develop 切出，做发布前的测试与修 bug，完成后同时合并到 main 和 develop。
• hotfix/*：线上紧急修复，从 main 切出，修完合并回 main 和 develop。

三、一次完整迭代的命令流

# 1. 开始新功能
git checkout -b feature/user-login develop

# 2. 开发完成后合并回 develop
git checkout develop
git merge --no-ff feature/user-login
git branch -d feature/user-login

# 3. 准备发布
git checkout -b release/v1.2.0 develop
# ... 测试、修 bug ...
git checkout main
git merge --no-ff release/v1.2.0
git tag -a v1.2.0 -m "发布 v1.2.0"
git checkout develop
git merge --no-ff release/v1.2.0

四、三个容易踩的坑

1. 长期不合并的 feature 分支：超过一周没合并的分支，冲突概率指数上升。建议小步快跑，每天 rebase 一次 develop。
2. 直接在 main 上改代码：hotfix 也要走分支，这是铁律，否则回滚时无从下手。
3. git merge 不用 --no-ff：fast-forward 会抹掉分支的合并痕迹，历史图变成一条直线，出问题时难以追溯。

五、小结

分支管理没有银弹。Git Flow 适合有固定发布节奏的团队；如果是持续交付，GitHub Flow（一根 main 加短命 feature 分支）可能更轻量。关键不是选哪种模型，而是团队达成一致并坚持执行。