说实话，每次看到团队里有人问“代码提交合并怎么又冲突了”，我就知道大概率是提交习惯和分支管理出了问题。这不是什么高深理论，就是日常开发里最基础也最容易踩坑的环节。今天把我在实际项目里积累的代码提交、分支合并和冲突处理经验完整梳理一遍，从一个具体的实操场景讲起，覆盖常见的分支策略、提交规范、合并方式选型，以及落地过程中的疑难杂症。
先说一个定位：这篇文章适合刚入行但已经能把代码跑起来的新人，也适合带小团队、需要自己定协作流程的开发者。如果你已经对 Git 很熟，可以重点看第 3 节和第 4 节的踩坑记录，很多细节是文档里不会写的。
1. 先把提交这件事做对：时机、粒度与信息规范
1.1 提交时机和粒度怎么把握
很多新人对提交的认知停留在“代码写完了就 commit 一下”，这会导致两个极端：要么一个提交里混了十多个文件改动，要么一天提交几十次。真正合理的提交粒度是：一次提交只做一件完整的事，并且保证当前仓库处于可用状态。
什么叫“一件事”？比如你修复了一个表单校验的 bug，那就只提交这个 bug 相关的文件。如果你在修 bug 的时候顺手改了两个变量的命名，哪怕改动很小，也建议拆成单独提交，或者在提交信息里明确写出来。我见过最痛苦的情况是一个 commit 改了 30 个文件，里面既有功能开发、又有样式调整、还夹着几个配置项的改动，等出了问题想回退，根本无从下手。
这里我自己的习惯是遵循“小步提交”原则：一个功能点、一个修复项、一次重构，对应一个提交。大概一个 commit 控制在 1 到 200 行改动，如果超过 500 行，我会先停下来想一想是不是拆分得不够细。另一个原则是保持任何时候都能发布——就是每次提交后代码必须是完整的、可运行的，不能出现“写到一半先提交了”的状态。
关于提交时机，还有一个容易忽略点：合并代码之前一定要先提交或暂存。哪怕你的改动还没完全测试通过，也建议把当前工作区清理干净，不然切分支的时候容易把半成品带过去。实在不想提交，就用git stash暂存，切完分支再弹回来。
1.2 提交信息怎么写才不挨骂
提交信息是很多人完全不在乎、但在协作里非常影响效率的部分。你想想看，三个月后有人来翻历史记录，看到一条“fix bug”会不会想骂人？因为这条信息根本看不出修的是哪个 bug、怎么修的、影响范围多大。
我推荐的结构是“标题 + 正文”，标题简短描述变更是做什么，正文说明为什么做这个变更、影响范围是什么。如果是修复 bug，还建议写清触发条件和复现路径。
fix(www/frontend): 修复登录页手机号校验不生效的问题 登录页在校验手机号时，正则匹配的是中国大陆手机号格式， 但运营后台录入的国际手机号因为存在空格导致校验失败。 将校验逻辑改为先去除空格再匹配，同时补充对应的单测用例。 影响范围：www/frontend/login 页面这里的“fix”是类型前缀，常用的类型有 feat（新功能）、fix（修复）、docs（文档）、refactor（重构）、style（格式调整）、test（测试）和 chore（构建或工具配置）。类型后面加括号写模块名，方便做版本发布时自动生成 changelog。
实际操作中，我见过团队用工具强制校验提交信息的格式，比如某些公司内部流水线会拦截不符合规范的 commit。如果你所在的团队还没有这个习惯，我建议你自己先养成，这不光是给别人看的，未来你维护开源项目、回看你自己写的历史记录时，收益非常大。
1.3 提交前的自检清单
提交前我会快速过一遍这几点，基本能避免大部分低级问题：
- 检查这次改动是否属于同一件事：如果发现混入了不相关的改动，先拆开。
- 检查是否有调试代码残留：控制台日志、临时测试文件、硬编码的路径和本地配置，这些都不应该进去。
- 检查敏感信息：数据库密码、密钥、token 是否被误提交，尤其是 .env 这类文件必须确认在 .gitignore 里。
- 检查文件状态：用
git status确认要提交的文件列表和预期一致，避免误提交。 - 跑一遍相关测试：哪怕是手动测试，也要确保当前提交是可运行的。
注意：如果发现一个文件里有部分改动应该另作它用，可以用
git add -p进行交互式暂存，分块提交，不要为了省事把所有改动塞进同一个提交。
2. 分支策略怎么选：团队协作的底层逻辑
2.1 常用分支模式对比
分支策略不是越多越复杂越好，它要匹配团队规模、发布节奏和业务特点。我接触过的项目大概分成这几类。
Git Flow是经典的完整分支模型，包含 master、develop、feature、release、hotfix 五种分支。优点是职责非常清晰，适合有固定版本规划、发布会拉版本分支的传统项目和软件产品。缺点也很明显：流程重，小团队跑起来会感觉处处受限，每次合代码都要留意是不是合错分支了。
主干开发模式是很多做持续交付的团队偏好的方式，所有人在一条主干上开发，用特性开关控制功能上线。优点是合入新鲜度高、冲突较少、持续集成自然落地；缺点是主干一旦坏了影响所有人，对代码质量要求很高，必须有完善的自动化测试兜底。
GitLab Flow算是我个人在各类型团队里都比较好用的一个变体，它把主干开发和生产环境分支结合，功能分支按需创建，通过环境分支处理发布。小团队可以直接用这个，既不会过度设计，也保留了发布隔离能力。
如果你是在 GitHub 上做开源项目，那就更没那么多讲究了：主分支加保护、功能分支开发、合并前跑 CI，基本上就是标配。
2.2 分支命名与权限管理
分支名本身也是一层约定。我建议至少包含类型前缀，后面带上要干什么的描述，比如feature/user-login、fix/phone-validate、release/v1.2.0。这样别人看到分支就能知道它属于哪个环节，合并后清理也方便。
权限管理上，我强烈建议把主干分支设置成保护分支，不是所有人都能直接 push 进去。实际做法是：普通开发者只能推 feature 分支，代码评审后才能合并到主干，管理员处理发布分支或紧急修复。这个操作在各类 Git 托管平台都有，30 秒就能配置好。
一条经验：保护分支不是给别人添麻烦，是给自己兜底的。你永远不会知道哪个人在某个深夜会不小心推了一个破坏性的改动上去。
2.3 分支策略选择的避坑指南
选分支策略的时候，最怕的不是选“错”，而是选了一套重量级模型但团队执行不起。我见过不少团队把 Git Flow 的架子搭得很完整，实际上大家都不跑 develop 分支，最后 develop 变成一个僵尸分支，还得定时清理。
另一个坑是分支长期不合并。一个 feature 分支如果开了一个月还没上主干，十有八九会成为团队的心病：合吧，冲突冲突一堆；不合吧，功能又一直不能上线。我建议功能分支两周内必须合回主干，如果做不到，那就说明需求拆得太大了。
发布节奏也是重要参考。每周发布一次以上的团队，用简单的主干加 tag 就够了；一个月发一版甚至更慢的项目，保留 release 分支会更从容。
3. 合并实操：选 merge 还是 rebase，关键判断标准
3.1 三种合并方式对比
合并代码时有merge、rebase、squash merge三种常见操作，它们的差异不只在命令，更在于它们如何塑造提交历史。
| 方式 | 历史形态 | 适用场景 | 注意事项 |
|---|---|---|---|
| merge | 保留分支分叉和合并节点，看起来像时间线交叉 | 团队协作，多人同时开发同一条主干 | 历史比较乱，但每个提交都保留真实时间线 |
| rebase | 把当前分支的提交“搬”到目标分支最新之上，形成线性历史 | 个人功能分支同步最新代码 | 改写已提交历史，公共分支上严禁使用 |
| squash merge | 将整个分支的所有提交压缩成一个提交 | 小功能、临时分支合并到主干 | 丢失中间提交细节，大功能慎用 |
这里有层逻辑很多人没想明白：merge 保留“什么时间发生了什么”，rebase 保留“最终一步步怎么实现的”，squash 只保留“最终做了这么一件事”。如果你看重过程，尤其是需要随时回退到每一次小改动，那 merge 更合适；如果你希望主干历史干净、每个提交都能单独编译通过，那主干用 squash merge、个人分支用 rebase 是不错的组合。
3.2 合并前的准备工作
好多冲突其实不是合并时产生的，而是合并前就没做好。我自己合并前固定做三件事：
第一，先把当前分支代码更新到最新，在自己的分支上把主干的更新合进来。这步虽然会早产生一次冲突，但在小范围内解决了总是比最后大合并时一次性解决要轻松得多。
第二，确认目标分支是可合并状态。如果主干上有别人刚合进来的代码导致 CI 挂了，先等它修好再合，别顶着失败的状态硬合并。
第三，处理掉临时的调试改动。很多时候你以为只改了业务代码，实际还有临时踩点、注释、写死的返回值，带着这些去合并就是在制造噪音。
3.3 冲突解决完整流程
冲突是躲不开的，关键是别慌，按流程来。
假设当前在feature/user-login分支，要把主干合并进来：
git checkout feature/user-login git fetch origin git merge origin/main这时候 Git 会提示哪些文件冲突了，接着用git status查看冲突文件列表，重点看那些双方都有修改的文件。打开冲突文件，里面会有类似这样的标记：
<<<<<<< HEAD 这是当前分支的代码 ======= 这是主干分支的代码 >>>>>>> origin/main解法没有统一标准，关键是先搞清楚每一段代码的含义，再动手改。很多时候两边改动的是不同的功能，只是碰巧改到了同一个文件的相邻区域，这种情况两边代码可以都保留；如果两边真做的是同一件事，那就得判断谁的业务逻辑更合理，必要时找写另一边的同事确认。
改完所有冲突文件后，需要手动git add标记完成，然后继续合并或提交：
git add src/common/validate.js git merge --continue这里有个容易误解的点：很多人以为git mergetool能自动解决全部冲突，其实它只是调起一个可视化的对比工具，最终怎么选还是由人来判断。可视化工具适合大段代码的比对，但小冲突直接用编辑器处理更快。
提示：如果冲突已经改得一团乱，想推倒重来，先执行
git merge --abort回到合并前状态，再重新合并。不要在同一次合并里反复手动还原文件，很容易越改越乱。
3.4 解决冲突后提交与验证
合并解决完并不意味着万事大吉。提交之后一定要做两件事：重新跑一遍自动化和手动验证。很多时候冲突解决时会出现“逻辑冲突”——代码没有语法错误但行为不对，比如 A 功能期望的调用参数被 B 功能改掉了，这种问题是编译不会报错、但运行时才会暴露的。
另一件事是确认本次合并的 diff 范围。用git log和git diff origin/main...HEAD看一遍变更集，确认没有把别人的改动覆盖掉，也没有把之前已经删掉的代码又找回来。这个检查花不了两分钟，但能省掉后面线上出问题的排查时间。
4. 合并后的事：验证、回滚路线与运营手段
4.1 合并完成不代表结束：验证清单
合并动作本身只是代码层面的操作，真正把一个变更落地还需要一套验证动作。我所在的团队目前合并后走的是这样的流程：
首先，CI 双重检查并行进行，包括单元测试、静态检查、构建产物校验。其次，拉分支到本地做冒烟测试，确认核心流程功能没有受影响。紧接着，在暂存环境部署后跑一轮接口自动化测试，这个环节能发现很多只有在真实环境里才会出现的问题。最后，同步更新相关文档，包括接口文档，以及需求跟踪系统里的任务状态。
如果这些验证里任何一项出了问题，先把后续代码合入暂停，等当前的修复确认通过再继续。不要带着失败状态继续合并新代码，不然问题会纠缠不清。
4.2 合并错了怎么办：reset 与 revert 的选型
代码合并错了，很多人第一反应是git reset，但用错场景会带来灾难。这里有一条非常清晰的界限：
- 如果提交还只存在于本地，或者还未被其他人拉取，可以大胆用
git reset --hard回退到某个提交。 - 如果代码已经推到远程分支，尤其是已经合并到主干被其他人拉取了，严禁用 reset 改写历史，必须用
git revert。
revert是生成一个反向提交，它不会改写历史，只是把之前某次提交的内容全部撤销。带来的好处是原提交记录还在，出了问题还能从原提交找回代码。
git revert <commit-hash>这在团队协作里是安全的操作，因为其他成员拉取更新时不会产生历史分叉。
4.3 常见问题排查速查表
把实操中经常遇到的问题整理成一张表，方便大家直接对应处理：
| 现象 | 可能原因 | 处理方式 |
|---|---|---|
| 合并时莫名多出大量冲突 | 长期未同步主干 | 先停止合并，手动同步主干后再重新合并 |
| 合并后部分代码丢失 | 冲突解决时选错了代码块 | 查看合并提交的 diff，找回被覆盖的代码 |
| push 被拒绝 | 远程主干有新提交 | 先拉取远程更新，再处理合并，最后推送 |
| 提交信息写错了 | 本地未推送 | 用git commit --amend修改信息 |
| 误把敏感文件推上远程 | 没有检查 .gitignore | 撤销文件跟踪并重写历史，同时立即更换密钥 |
| 提交历史混乱 | rebase 用了公共分支 | 不要强制覆盖，需和管理员协调处理 |
4.4 我个人实操中沉淀的几条经验
最后分享几点不那么容易被写进文档但非常实际的经验。
第一个是关于提交小步走的收益，我在实际项目中最大的体会是它大幅简化了代码评审的负担。评审人看到一个 20 行的提交和看到一个 400 行的提交，心理压力完全不一样，前者能在几分钟内认真看完，后者大概率扫一眼就通过了，质量自然没法保证。
第二个是别把紧急修复和日常开发搅在一起。遇到线上问题，永远先停下手头的功能开发，在 hotfix 分支上处理并发布，再回到主流程。如果顺手在同一个分支里改开发代码，上线和灰度很容易出现互相干扰。
第三个是新人对冲突这件事普遍怕，其实冲突不是代码出问题了，它只是意味着你和你同事的工作有重叠。越怕冲突就越不愿意合并，结果积攒的问题越多。我现在的习惯是每天至少同步一次主干，及时解决小冲突，保持分支新鲜度，这样真到合并的前一天临门一脚基本不会手忙脚乱。
第四个是操作习惯：在合并或重置前，永远先确认你的工作区是干净的。很多回退操作会丢失未提交的改动。每次执行强制类操作之前，用git status瞄一眼，就能避免绝大多数“我的代码不见了”的悲剧。
