Git 协作：从单人提交到团队分支工作流

一个人写代码时，Git 往往只用来保存进度；一旦变成三五个人同时改同一个仓库，没有约定的提交就会很快变成冲突、覆盖和互相等待。本文用一个贴近日常开发的分支工作流，把从建分支到合并上线的关键动作讲清楚。

一、先定一条主线，再谈分支

团队协作的第一条规则，是保护主线。主线分支一般叫 main，只接受经过评审的合并，不直接在上面写功能。每个新需求从主线拉一个功能分支，名字写清意图，例如 feature/login-captcha、fix/order-timeout。分支名本身就是一种文档，后来排查问题时，一眼就能知道这次改动属于哪个需求。

开始之前先同步主线，避免在旧代码上做无用功：

git checkout main
git pull origin main
git checkout -b feature/user-profile

二、小步提交，写能读懂的提交信息

好的提交信息比代码注释更能帮队友省时间。建议一次提交只做一件事，标题说明做了什么，正文说明为什么这样做。例如把“修复登录问题”改成“登录失败时保留用户名，避免用户重复输入”，后者不需要打开代码就能理解价值。

提交前先看改动范围：

git status
git diff
git add -p
git commit -m "登录失败时保留用户名，避免重复输入"

git add -p 可以分块确认改动，防止把调试代码、临时日志顺手提交上去。

三、每天同步，不要攒到最后再合并

分支活得越久，合并成本越高。比较稳妥的做法是每天至少同步一次主线，有冲突尽早在自己的分支里解决：

git fetch origin
git rebase origin/main

变基会让提交历史更干净，但已经推送到远端、且别人正在使用的分支不要随意变基，否则队友的本地历史会对不上。个人功能分支可以变基，公共分支一律用合并。

四、合并请求是最重要的协作环节

发起合并请求时，不要只贴一个标题。写清改动背景、影响范围、测试方法，以及有没有数据库变更或配置变更。评审人先看合并请求描述，再看代码，效率会高很多。评审意见要针对代码本身，给出可执行的建议，例如指出边界条件没有覆盖，而不是简单说“这里不好”。

收到评审意见后，不要在旧提交上反复追加“修复评审意见”式的提交堆叠。可以按评审点整理提交，或者在合并前把相关提交整理成逻辑清晰的几条记录，让主线历史保持可读。

五、冲突不可怕，怕的是不知道改了什么

冲突提示出现时，先看冲突双方各自想表达什么，再决定保留哪一段或重新组合。涉及业务逻辑的冲突不要只凭感觉选一边，最好和改动另一边的同事确认一次。解决后一定要重新跑相关测试，再提交解决结果：

git add .
git commit -m "解决与主线在用户信息字段上的合并冲突"

六、上线后也要留一条回退路

合并到主线并不等于工作结束。发布前确认回滚方式：是直接回退提交，还是用配置开关关闭新功能？对于数据库字段变更，尤其要先确认旧版本代码是否还能正常运行。把发布检查清单写进团队文档，下一次就不用凭记忆操作。

结语

Git 协作的核心不是记住多少命令，而是让每一次提交、每一次合并都可追溯、可评审、可回退。主线保持干净，分支职责清晰，提交信息说人话，冲突尽早解决，团队的开发节奏自然会稳下来。从下一个需求开始，就用这套流程走一遍，你会发现代码评审变快了，联调时的意外也少了。