分支是 Git 的灵魂
分支的本质是”可移动的指针”。理解了这一点,merge、rebase、cherry-pick 就都顺理成章了。本文从团队协作视角讲清楚分支该怎么用。
一、两种主流分支模型
GitHub Flow(小团队、持续部署)
只有 main 一个长期分支,所有改动都在功能分支上开发,完成后开 Pull Request 合并:
1 | main ──────────────────────────────── |
流程:main 拉分支 → 开发 → PR → 评审 → 合并 → 自动部署。
Git Flow(发版节奏固定的项目)
有 main、develop 两个长期分支,加上 feature、release、hotfix 三类临时分支:
1 | main: v1.0 ──────── v1.1 ──────── |
小团队、快速迭代建议用 GitHub Flow,别为流程而流程。
二、merge 与 rebase:到底怎么选
merge:保留完整历史,产生一个合并提交:
1 | git checkout main |
rebase:把当前分支的提交”重新垫”到目标分支之上,历史是一条直线:
1 | git checkout feature/login |
| 对比 | merge | rebase |
|---|---|---|
| 历史 | 保留真实时间线,有分叉 | 线性、整洁 |
| 安全性 | 不重写历史,安全 | 重写提交,严禁对已推送的公共分支 rebase |
| 适用 | 合并特性分支回主干 | 本地开发时同步主干更新 |
推荐组合:拉取主干更新用 rebase 保持本地干净,合并回主干用 merge --no-ff 保留特性上下文。
三、常用但容易忘的命令
1 | # 摘取某个提交到当前分支(紧急修复时很常用) |
四、冲突解决的正确姿势
冲突不可怕,关键是先搞清楚哪些提交在打架:
1 | git merge feature/login |
手动解决后:
1 | git add src/App.vue |
rebase 冲突要额外注意:解决一个冲突后不能 commit,要 git rebase --continue,想放弃就 git rebase --abort。
五、团队协作最佳实践清单
- 分支命名带语义:
feature/登录、fix/支付超时、hotfix/紧急漏洞; - 小步提交:一次提交只做一件事,commit message 写清”为什么”;
- 提交前自查:
git diff --check查空白错误,git status确认没多提交文件; - 不要提交敏感信息:
.env、密钥文件一律进.gitignore; - 公共分支保护:
main/develop设置保护,禁止直接 push,强制走 PR + 评审; - PR 尽量小:超过 400 行的 PR 评审质量会明显下降,拆成多个;
- 删除已合并的本地分支:
git branch -d <name>,保持git branch干净。
六、一个完整的协作闭环
1 | # 1. 拉最新主干 |
总结
分支策略没有银弹,团队一致 + 保持简单比花哨的模型更重要。先掌握 GitHub Flow + merge/rebase 的取舍,再根据项目节奏决定要不要上 Git Flow。
本博客所有文章除特别声明外,均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 JCAlways!
评论
