Git 协作避坑指南：分支、合并与冲突处理

多人协作写代码，最常见的翻车往往不是技术太难，而是流程太乱。一个三五人的小团队，只要分支、提交、合并这三件事没立好规矩，冲突、丢代码、主线变脏就会轮番出现。下面这几点，都是实际协作里踩过坑后总结出来的做法。

一、分支：名字说清楚，用完就删掉

主分支（比如 main）只接受合并请求，任何人都不直接在上面改代码。功能开发从主分支拉一条新分支，命名带上类型和内容，例如 feat/登录页、fix/支付超时，一眼就能看出这条分支是干什么的。分支合并进主线后就删掉它，长期不删的分支越攒越多，最后谁也不敢动，冲突也越攒越大。

二、提交：一次只做一件事

一个提交只包含一件事：修一个 bug、加一个功能、改一次配置，不要把格式化、改逻辑、换依赖混进同一个提交。提交信息写清楚动词、对象和原因，例如“修复订单超时后状态未回滚”，而不是“改了一下”。提交干净了，以后出问题用 git log 定位也快，回滚也不用提心吊胆。

三、每天先拉后推，别在主线上直接改

开工第一件事是拉取最新代码再开工，推送之前再拉一次。很多人图省事直接在主分支上改完就推，结果和别人的提交撞在一起，只能靠强制推送解决，队友的代码就这样被覆盖。记住一条铁律：公开分支上不要 force push，自己的本地分支没推送之前怎么整理都行，推给别人之后就别再改写历史。

四、冲突：先看懂三方，再动手选

冲突出现时不要慌，也不要无脑选“保留我方”或“保留对方”。先看懂三方：共同祖先版本、我方改动、对方改动，理解每一处差异的意图再合并。合并标记一定要清干净，合并完成后先跑一遍测试再提交，带着标记提交上去等于把半成品推给了全队。二进制文件和锁文件冲突时，优先按约定保留一方并在提交信息里说明，不要手工拼二进制内容。

五、合并策略：小步快跑，主线保持干净

日常功能开发建议用 squash 合并，把一个分支上的多次零散提交压成一个再进主线，主线历史干净好读。需要完整保留开发过程时再用普通合并提交。合并请求不要攒太大，几百行以内、改动聚焦的请求最容易评审通过，几千行的大请求只会越拖越久、冲突越多。

六、敏感信息：一开始就挡在仓库外面

密钥、令牌、本地配置文件一开始就要写进 .gitignore，宁可多挡一点，也不要事后补救。一旦密钥误提交进了仓库，光删文件是没用的，历史记录里还能翻出来，必须立刻去平台上轮换、作废旧密钥，再清理历史。

流程存在的意义是给团队省时间，不是添麻烦。分支命名清楚、提交粒度干净、每天先拉后推、冲突看懂再合、敏感信息提前挡住，这几条养成习惯后，协作里的摩擦会少一大半，代码历史也会干净得像样。