分支是 Git 的灵魂

分支的本质是”可移动的指针”。理解了这一点,merge、rebase、cherry-pick 就都顺理成章了。本文从团队协作视角讲清楚分支该怎么用。

一、两种主流分支模型

GitHub Flow(小团队、持续部署)

只有 main 一个长期分支,所有改动都在功能分支上开发,完成后开 Pull Request 合并:

1
2
3
main ────────────────────────────────
\ /
feature/login ──────

流程:main 拉分支 → 开发 → PR → 评审 → 合并 → 自动部署。

Git Flow(发版节奏固定的项目)

有 main、develop 两个长期分支,加上 feature、release、hotfix 三类临时分支:

1
2
3
4
main:    v1.0 ──────── v1.1 ────────
develop: ── dev ────────
feature: \── f1 ──/
hotfix: \── 紧急修复 ──/

小团队、快速迭代建议用 GitHub Flow,别为流程而流程。

二、merge 与 rebase:到底怎么选

merge:保留完整历史,产生一个合并提交:

1
2
3
git checkout main
git merge feature/login
# 产生 Merge commit,历史是"分叉再合并"的网状结构

rebase:把当前分支的提交”重新垫”到目标分支之上,历史是一条直线:

1
2
3
git checkout feature/login
git rebase main
# 历史变成直线,干净但重写了提交
对比 merge rebase
历史 保留真实时间线,有分叉 线性、整洁
安全性 不重写历史,安全 重写提交,严禁对已推送的公共分支 rebase
适用 合并特性分支回主干 本地开发时同步主干更新

推荐组合:拉取主干更新用 rebase 保持本地干净,合并回主干用 merge --no-ff 保留特性上下文。

三、常用但容易忘的命令

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# 摘取某个提交到当前分支(紧急修复时很常用)
git cherry-pick <commit-hash>

# 暂存未提交的改动(切换分支前必备)
git stash
git stash list
git stash pop

# 撤销:reset 回退历史 / revert 生成反向提交
git reset --hard HEAD~1 # 本地未推送时用
git revert <commit-hash> # 已推送时用,生成一个"撤销提交"

# 查看每个分支领先/落后主干多少
git fetch --all --prune
git branch -vv

四、冲突解决的正确姿势

冲突不可怕,关键是先搞清楚哪些提交在打架:

1
2
3
4
git merge feature/login
# CONFLICT (content): Merge conflict in src/App.vue
git status # 看冲突文件
git diff # 看冲突内容(<<<<<<< ======= >>>>>>> 标记)

手动解决后:

1
2
git add src/App.vue
git commit # merge 冲突解决后直接提交

rebase 冲突要额外注意:解决一个冲突后不能 commit,要 git rebase --continue,想放弃就 git rebase --abort。

五、团队协作最佳实践清单

  1. 分支命名带语义:feature/登录、fix/支付超时、hotfix/紧急漏洞;
  2. 小步提交:一次提交只做一件事,commit message 写清”为什么”;
  3. 提交前自查:git diff --check 查空白错误,git status 确认没多提交文件;
  4. 不要提交敏感信息:.env、密钥文件一律进 .gitignore;
  5. 公共分支保护:main/develop 设置保护,禁止直接 push,强制走 PR + 评审;
  6. PR 尽量小:超过 400 行的 PR 评审质量会明显下降,拆成多个;
  7. 删除已合并的本地分支:git branch -d <name>,保持 git branch 干净。

六、一个完整的协作闭环

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
# 1. 拉最新主干
git checkout main && git pull

# 2. 建功能分支
git checkout -b feature/payment

# 3. 开发期间同步主干更新(本地保持线性)
git fetch origin
git rebase origin/main

# 4. 提交并推送
git add .
git commit -m "feat: 接入支付回调"
git push -u origin feature/payment

# 5. 开 PR → 评审通过 → 合并(merge --no-ff)

总结

分支策略没有银弹,团队一致 + 保持简单比花哨的模型更重要。先掌握 GitHub Flow + merge/rebase 的取舍,再根据项目节奏决定要不要上 Git Flow。