Docs Library

Git 协作最佳实践

整理更适合团队协作的 Git 使用习惯，包括小提交、topic branch、fetch-first、共享历史边界、提交规范与安全推送策略。

为什么“最佳实践”很重要

Git 的灵活性很高，但团队协作的成本也往往来自这种灵活性。如果大家都能完成提交、合并和推送，不代表协作就一定顺畅。真正影响效率的，往往是这些细节：

提交是不是够小、够清晰
分支是不是够独立
同步远端时是不是足够可控
历史改写是否踩到了共享边界
提交信息能不能被未来的人读懂

1. 保持提交小而明确

Pro Git 在协作章节里明确建议，把每个提交做成“逻辑上独立的 changeset”。

这意味着：

一个提交尽量只表达一个清晰意图
不要把多个无关问题糅在一个大提交里
如果同一文件里混入了多种变更，优先拆开暂存再提交

典型做法：

git add --patch
git commit -m "fix: handle empty email input"

这样做的好处：

review 更轻
revert 更安全
cherry-pick 更精确

一个更实用的补充判断是：如果你很难用一句话概括这次提交在做什么，往往就说明它还不够聚焦。

2. 用 topic branch 隔离工作主题

当你在做一项具体工作时，优先新建一个明确的主题分支，而不是在长期分支上直接堆积改动。

git switch -c feature/login-validation

好处有三个：

被拒绝或暂缓的工作可以直接丢弃，不污染主分支
在等待 review 期间，可以继续从主线拉出别的分支并行开发
后续做 rebase、merge、cherry-pick 时边界更清晰

命名上也建议让分支名直接表达工作主题，例如：

feature/login-validation
fix/navbar-overlap
docs/release-notes

这样在 review、CI 和回滚场景里都会更容易沟通。

3. 先 fetch，再决定 merge 或 rebase

官方 git pull 文档已经把整合结果拆得很清楚：pull 会先 fetch，再进入具体整合策略。

更稳妥的习惯通常是：

git fetch origin

然后再决定：

git merge origin/main
git rebase origin/main
git pull --ff-only

这样做的核心价值是“把观察和改动分开”。你先确认远端状态，再决定如何整合，而不是把判断交给默认行为。

如果团队希望进一步保守，官方 git pull 文档里提到的 --ff-only 也是一个很好的默认策略，因为它会在分叉时直接失败，而不是悄悄生成你并不想要的 merge commit。

4. 共享历史要保守，未共享历史才大胆整理

重写历史在本地分支上非常有用，比如：

git commit --amend
git rebase -i
git reset --soft

但 Pro Git 也明确强调：一旦历史已经推送并被别人基于它继续开发，就要把它看得更“接近最终状态”。

一个很实用的经验法则是：

个人分支：可以整理
共享分支：谨慎改写
主分支：默认不要改写

一个很重要的团队共识是：只要你不确定某段历史是否已经被别人基于它继续开发，就先把它当作“已共享历史”来处理。

5. 提交信息要让别人愿意读

官方书里对提交信息给了非常实用的建议：

第一行简洁概括改动
正文解释动机和背景
用祈使句表达，如 Fix bug 而不是 Fixed bug

一个简单模板：

Add validation for empty email input

Prevent the login form from submitting when the email field is blank.
This keeps client-side feedback aligned with server-side validation.

如果团队里还没有统一规范，至少可以先建立这三个最低要求：

标题行描述动作，不写模糊词
不把多个问题塞进同一个提交信息
复杂改动补一句“为什么”

6. push 前先做一次最小自检

在推送前，至少做下面几步中的大部分：

git status
git log --oneline --decorate -5
git diff --stat origin/main...

这能帮助你快速确认：

工作区是否真的干净
最近几个提交是否是你想发出的内容
变更量是否超出预期

如果这次提交会影响很多文件，建议再补一个动作：

git diff --name-only origin/main...

它能帮助你快速确认是否把不相关文件也带进来了。

7. 危险操作之前先想恢复路径

在执行这些命令前，先暂停一下：

git reset --hard
git rebase
git push --force

更稳的做法：

先看 git status
先看 git reflog
必要时先建救援分支

例如在一次可能复杂的 rebase 前，先做一条临时保护分支：

git branch backup/pre-rebase

这类小动作的价值，在出问题时会非常大。

8. 默认用更保守的推送和同步方式

如果确实要强推，优先：

git push --force-with-lease

如果只是想更新当前分支但不想隐式产生 merge：

git pull --ff-only

这两个习惯都属于“默认更保守”的策略，能显著减少误操作的范围。

官方 git push 文档长期保留 --force-with-lease，就是因为它比裸 --force 更适合团队环境。它会先检查远端引用是否仍然处于你预期的状态，再决定是否允许覆盖。

9. 用 review 友好的方式整理提交

在发起合并请求前，可以先问自己三个问题：

这些提交的顺序是否讲得通
有没有“修修补补”的噪声提交需要整理
reviewer 能不能从提交历史里看懂你的决策过程

这时常见的本地整理工具包括：

git commit --amend
git rebase -i
git restore --staged

但这类整理动作更适合发生在“还没共享之前”。

10. 不要把 Git 命令当作记忆题，要把它们当作风险分级工具

很多团队里真正的问题不是“不会 Git”，而是没有把命令按风险分级来使用。一个很实用的做法是把常见操作分成三类：

低风险

git status
git log
git fetch
git diff

中风险

git merge
git stash
git restore
git revert

高风险

git reset --hard
git rebase
git push --force

这样做的好处是，团队成员会更自然地形成“高风险命令前先停一下”的习惯。

一个适合团队落地的最小规则集

如果你要为团队写一版轻量规范，可以先从下面 5 条开始：

每个提交只做一件事
每项工作使用 topic branch
同步远端优先 fetch-first
已共享历史默认不改写
强推时默认使用 --force-with-lease

如果团队愿意再向前走一步，可以把它扩展成 8 条：

pull 默认优先 --ff-only 或 fetch-first
发起评审前整理噪声提交
危险操作前确认 reflog 和备份分支

一个适合 onboarding 的实践顺序

如果你要带新人上手 Git，可以按下面顺序建立习惯：

先学 status、add、commit
再学 topic branch
再学 fetch-first
再学 merge / rebase 的边界
最后学 reset、reflog、force push 这类高风险操作

下一步建议

这篇读完后，建议继续配套阅读：

fetch vs pull
git rebase
git reflog