分支合并这件事，说简单也简单，两条命令就完事；说麻烦也麻烦，一不留神就能把别人一周的活儿冲掉。我这些年带过几个团队，几乎每次代码事故复盘，总会有一两条跟合并有关——不是合错了分支方向，就是冲突解决时手一抖把对方的改动整段删了。所以我一直认为，在 IDEA 里合并 git 分支，真正的门槛不在命令本身，而在于你有没有搞清楚每一次点击背后 git 到底做了哪些动作。这篇就聊这个：IDEA 里做分支合并的完整路径、每个选项的真实语义、冲突界面怎么高效用、以及我踩过的那些坑。适合刚上手 git 工作流的新人，也适合用了几年 IDEA 但一直靠"感觉"点按钮的老手，看完至少能保证你在合并现场不慌、不出事。
1. 先搞明白 IDEA 在合并时到底替你做了什么
1.1 合并、变基、拣选：三种动作对应三种不同结果
很多人把 IDEA 右下角分支面板里那几个选项当成"差不多"的功能，其实它们的提交图结果完全不同。Merge是把目标分支的改动合并进当前分支，如果当前分支没有新提交，git 默认做快进（fast-forward），直接把指针推到目标分支的最新提交，历史是一条直线；如果有分叉，就会产生一个合并提交，两条历史汇合。Rebase是把当前分支的提交"挪"到目标分支最新提交之后重放一遍，历史被改写成一条直线，但每个提交的哈希值都会变。Cherry-Pick只挑一个或几个提交，把它们复制到当前分支，不动其他内容。
我在实际项目里用的策略很固定：个人特性分支追主干，用 rebase 保持干净；特性分支合回集成分支，用 merge 保留"这批改动是一起进去的"这个信息。理由很实际——排查线上问题的时候，你需要知道哪一批提交是同一个需求带进来的，merge 提交就是那个天然的边界。rebase 的历史虽然漂亮，但所有提交时间被重排，出问题回溯时会丢掉"这批代码什么时候真正上线"的线索。
IDEA 的 Update Project（Ctrl+T/Cmd+T）弹窗里会让你选 Merge 还是 Rebase，这个选择本质上就是上面说的取舍。我一直建议团队统一选 Merge，因为新人做 rebase 时一旦遇到冲突处理不当，很容易把自己的分支搞成一团乱麻，而 merge 至少失败后还能 Abort 干净回退。
| 动作 | 历史形态 | 是否改写提交 | 典型场景 |
|---|---|---|---|
| Merge | 分叉后汇合，产生合并节点 | 否 | 特性分支合入集成分支、发布前保守合并 |
| Rebase | 一条直线 | 是，哈希全变 | 个人分支追主干、提交前整理 |
| Cherry-Pick | 目标提交被复制一份 | 复制，原提交仍在 | 只把某个修复搬到另一条分支 |
1.2 为什么我建议在 IDE 里合而不是纯命令行
命令行合并没有任何问题，但 IDEA 有两个环节确实比终端舒服得多：冲突的三窗格对比和合并前的差异预览。命令行里冲突是一堆<<<<<<<标记，你得靠眼睛逐段辨认哪边是 HEAD、哪边是对方分支；IDEA 会把"你的版本""结果""对方版本"并排摊开，哪边加了几行、删了哪几行一目了然，还能直接跳到下一个未解决的冲突块。
另一个容易被忽略的点是合并前的预览。在分支面板里选中目标分支，点Compare with Current，IDEA 会用完整的差异视图列出这次合并会带来的所有改动，包括新增文件、删除文件、重命名。我养成的习惯是：任何跨天的、涉及多人协作的合并，动手前一定先看一遍这个差异列表。有次我在预览里发现一个配置文件被整段删除，追下去才发现是同事本地误删后提交上去了——如果直接合并，这个坑就埋进去了。
当然 IDEB 也不是万能的。真正复杂的历史改写（比如交互式 squash、按段落拆提交）还是要回命令行，但那是另一个话题，跟日常合并关系不大。
1.3 动手前必须过一遍的三项状态检查
合并出事故的人，九成是因为合并前没看状态。我总结了三项必备检查，每一项都能在 IDEA 里三十秒内完成：
第一，当前分支是不是你以为的那条。IDEA 右下角显示的分支名要亲眼确认，不要凭记忆。我见过最典型的事故是：以为自己在特性分支上，其实还停在集成分支，结果一个 merge 把别人没测完的代码直接推进去了。
第二，工作区是否干净。Git 工具窗口的 Local Changes 里如果还有未提交的改动，合并过程中这些改动会和进来的内容搅在一起，冲突范围会被莫名其妙地放大。要么提交，要么 Stash（右键项目 → Git → Repository → Stash Changes），二选一，不要留半成品。
第三，本地分支是否落后远端。合并前先 Fetch 一次（Git 工具窗口左上角的刷新图标，或Ctrl+Shift+A搜 Fetch），看看远端有没有你还没拉下来的提交。在过期的本地状态上做合并，等于在错误的地基上盖楼。
提醒：这三项检查做完，再点任何合并按钮。跳过检查省下的三十秒，通常在冲突现场要花三十分钟还回来。
2. 合并前的准备工作：把风险挡在动手之前
2.1 工作区清理的两种方案，以及我为什么更偏向 Stash
前面说了工作区要干净，但实际操作中经常出现"改了一半不方便提交"的情况。这时候有两条路：凑一个临时提交，或者 Stash。
凑临时提交的坏处很明显——它进了历史，回头还得再 revert 或者 reset 掉。如果分支已经推到远端，清理这些垃圾提交还要 force push，风险陡增。所以我更倾向 Stash。IDEA 里的操作路径是右键项目根目录 →Git→Repository→Stash Changes，弹窗里可以给这次暂存写个描述，比如"合并前的半成品-用户模块"，后面 Unstash 的时候好辨认。
Stash 有一个很多人不知道的细节：它默认只存已跟踪文件的改动。如果你刚新建了文件还没git add，Stash 不会带上它，合并完之后这个新文件还在原地。这看起来是好事，其实会带来麻烦——合并过程中这个"游离"的新文件可能挡住某些操作。所以我的习惯是，先git add把新文件纳管，再 Stash，这样工作区是真正干净的。IDEA 的 Stash 弹窗里有个Include untracked files勾选项，勾上就能解决，比手动 add 更省事。
Stash 用完记得 Unstash，别攒着。我见过一个项目，某位同事的 Stash 列表堆了十几条，最后他自己都分不清哪条是哪条，只能全删掉重写。Stash 是临时工具，不是备份手段。
2.2 同步主干：先追平再合并的顺序问题
合并方向不同，准备动作也不同。如果是把集成分支的更新合进特性分支（也就是说你要追上主干），标准顺序是：先 Fetch → 确认特性分支已推到远端（或者至少知道风险）→ 把集成分支 merge 进当前分支 → 解决冲突 → 跑一遍构建和关键测试 → 推远端。
如果是把特性分支合回集成分支，顺序相反，而且要更谨慎：先在特性分支上把自己追平主干（这样冲突在你自己的分支里解决，出问题只影响你一个人）→ 推远端 → 切到集成分支 → 拉最新 → 再 merge 特性分支。这个"先在本地追平、再合入主干"的顺序，能把冲突解决的影响面从整个团队缩小到你自己，是我认为最值得养成的习惯。
还有一种情况是多人共用同一条特性分支。这时候除了追平主干，还得先拉一下特性分支本身，确保队友的改动也在。合并前在 IDEA 的 Log 面板里扫一眼最近的提交作者，花不了几秒，能避免很多"我合并的时候你还没推"的扯皮。
2.3 给自己留一条后路：合并前的回滚点
不管准备多充分，我都建议在重要合并动手前留个锚点。最简单的做法是记下当前 HEAD 的短哈希，写在随手的地方，IDEA 的 Git 工具窗口 → Log 里选中最新提交就能看到。出问题的时候，git reset --hard <哈希>直接把分支挪回去，比事后一层层 revert 快得多，也干净得多。
如果项目本身有 tag 习惯，更稳的做法是打个临时 tag：右键 Log 里的提交 →New Tag，命名成pre-merge-20240115这种带日期的形式。tag 比记哈希可靠，因为它不会因为你记错一位字符而失效。
另外提一个被我用了很多年的小技巧：把git rerere打开（git config --global rerere.enabled true）。它的作用是记住你解决过的冲突，下次遇到同一段冲突自动套用上次的解法。对于长期维护的分支、反复 rebase 的场景，这个功能省下的时间相当可观，而且 IDEA 完全兼容，你不需要感知它的存在，它就在后台默默工作。
3. 实操全流程：从发起合并到提交落地
3.1 用分支面板发起一次合并，每一步都在干什么
主路径是右下角的分支指示器：点击Git: <当前分支名>→ 弹出面板会分成本地和远端两组 → 在本地列表里找到目标分支 → 鼠标悬停，展开子菜单 → 选Merge into Current。
这里的语义要掰清楚：Merge into Current是"把选中的分支合并到当前分支"，也就是目标分支的改动流进你所在的分支。方向搞反是这个界面最常见的失误。我的验证方法是点之前先读一遍右下角的分支名，默念一句"我要让 X 进到 Y 里"，然后确认选中的是 X、当前是 Y。
点完之后 IDEA 会有几种反应。如果目标分支的所有提交在当前分支里都已存在，会提示 Already up to date，什么都不发生。如果当前分支没有新提交、可以直接快进，IDEA 会静默把指针推到目标分支最新提交——注意，快进合并不产生合并提交，历史里看不出"这里合并过一次"。如果你需要保留这个痕迹（团队规范要求可追溯），就得用git merge --no-ff <分支名>强制生成合并节点，命令行的这一条在 IDEA 界面里没有直接对应按钮，是我少数会切终端操作的场景。
如果有分叉，IDEA 会弹出合并提交信息窗口，默认文本是Merge branch 'xxx' into yyy。我习惯在这行后面补一句这次合并的目的，比如Merge branch 'feature/order-split' into develop (订单拆分一期)。半年后翻历史的人会感谢你。
3.2 冲突界面三个窗口的正确用法
冲突发生时 IDEA 会自动打开 Merge 对话框或者文件内的三窗格视图。左边是Local / Yours（当前分支的版本），右边是Theirs（被合并进来的版本），中间是Result（最终结果）。顶部工具栏有一排按钮，最常用的是Accept Left、Accept Right、Apply、Apply All，以及左右箭头用来在冲突块之间跳转。
大多数人只用一个动作：整段接受一边。这在小冲突上没问题，但遇到两边都改了同一段逻辑的情况，整段接受等于把另一边的改动全部丢弃，而且这个丢弃过程 git 不会给你任何警告，因为它认为你已经做出了选择。我的做法是，只要冲突块里的两边都有实质代码（不是空行、不是纯格式化），就一定手动在中间的 Result 里编辑，取两边的并集再调整逻辑。
有个细节值得说：IDEA 的 Resolve 面板底部会显示X of Y conflicts resolved，这个计数是判断"还有没有漏网之鱼"的唯一可靠依据。所有冲突块都处理完之前，中间的 Result 窗口不会允许你保存生效。处理完之后点Apply或Save and Finish，文件会自动标记为已解决，git 索引里的冲突状态也就清掉了。
注意：不要在编辑器里手动删除
<<<<<<<、=======、>>>>>>>这些标记来"解决"冲突。看似干净了，但 git 的索引状态还停在冲突中，后续 commit 会报错。要么用 IDEA 的 Resolve 按钮，要么在终端git add对应的文件。
3.3 合并提交信息与合并后的验证动线
冲突全部解决后，IDEA 会让你填合并提交信息。这里有个经验：不要只写默认的那行。默认信息只说明了"合了哪条分支"，没有任何业务含义。我的写法是标题行保持默认格式（方便工具解析），空一行之后补三到五行说明：这次合并带进来哪些需求、有没有需要特别注意的数据库变更、有没有配置项需要同步。
合并提交落下来之后，很多人就急着 push 了，这是第二个高风险节点。我固定的验证动线是四步：先看 IDEA 的 Problems 面板有没有编译错误（合并最常见的问题是方法签名冲突导致引用失效，编译不过直接暴露）；再跑一遍项目的构建；然后跑关键路径的单元测试；最后在 Git 工具的 Log 里看一眼提交图，确认分叉和汇合的关系符合预期。
这四步里我最看重第一步。有次合并一个跨模块的重构分支，代码本身没冲突，但两个模块各自改了一个公共工具类的方法参数，git 完全无感，编译直接报了一百多个错。如果当时合并完就推远端，CI 会红一片，还得回头查是哪次提交的问题。编译在本地跑通只要几十秒，收益极高。
3.4 只想搬一两个提交：Cherry-Pick 的适用边界
有时候不需要整条分支，只想要其中一个修复。这就是 Cherry-Pick 的场合。IDEA 里的路径是：Git 工具窗口 → Log，选中那条提交 → 右键 →Cherry-Pick，它会把这个提交的改动复制到当前分支并生成一个新提交。
它的适用场景很明确：线上紧急修复已经在修复分支验证过，现在要单独搬到发布分支；或者某个小改动误提交到了错误分支，想搬到正确的地方。但它有两个必须知道的限制。
第一，复制不包含上下文。如果那个提交依赖它前面的几个提交才能工作，单独 pick 过来会编译不过。所以 pick 之前一定要看那条提交的 diff，确认它是自包含的。
第二，重复 pick 会产生重复冲突。同一条提交如果被 pick 到多条分支，将来这些分支互相合并时，同一段代码会以两个不同哈希的形式出现，合并时必定冲突。所以我的原则是：能用 merge 就用 merge，Cherry-Pick 只用于"分支之间注定不会互合并"的场景，比如发布分支和开发分支的长期分叉。
还有一个工具是Revert Commit（右键提交），它生成一个反向提交来抵消某次改动。比起 reset，revert 不破坏历史，适合已经推到远端、别人可能已经拉过的提交。这两个操作在 IDEA 的右键菜单里紧挨着，我见过新人点错的，后果是一次本来只想撤销的提交变成了复制。点之前看清菜单项的名字。
4. 冲突处理进阶：把冲突当成信息而不是事故
4.1 冲突的四种成因，对应四种不同解法
冲突不是一种东西，我按成因分成四类，每类的处理思路完全不同。
第一类，同一行被两边改了逻辑。这是真正的语义冲突，必须人来判断。处理时先把两边的意图都读一遍，问自己"这次合并的目的是什么"，然后按目的取舍，不是按谁改得晚。
第二类，文件重命名或移动导致的冲突。一边把文件挪到新目录，另一边在原地改了内容。git 有时能自动跟踪，有时不能。这类冲突的解法是手动把文件放到正确位置，再把对方的内容合进去，不要图省事整段覆盖。
第三类，格式化差异造成的伪冲突。两边代码逻辑一样，只是缩进、换行、import 顺序不同。这类冲突最气人，因为它会淹没真正的冲突。根治办法是团队统一.editorconfig和代码格式化配置，并且在合并前先对当前分支跑一次格式化提交，把差异提前消化掉。
第四类，行尾符冲突。一边是 CRLF，一边是 LF，整个文件全红。这种情况需要在仓库根目录加.gitattributes，明确文本文件的换行处理策略，然后统一重新规范化一次。不解决这个根因，每次合并都会重演。
| 冲突类型 | 判断依据 | 推荐解法 |
|---|---|---|
| 语义冲突 | 同一行两边逻辑不同 | 人工阅读意图后手工编辑 Result |
| 重命名/移动 | 提示文件路径不一致 | 手动定位文件后再合内容 |
| 格式化伪冲突 | diff 里大量空白差异 | 统一格式化配置，合并前先格式化 |
| 行尾符冲突 | 整个文件全变更 | 加 .gitattributes 并重新规范化 |
4.2 大范围冲突的降级处理：先退一步再动手
有一种情况特别容易让人上头：打开合并，发现冲突文件几十个、冲突块上百处。这时候在 IDEA 里一个个点下去，效率极低而且极易出错，因为人在疲劳状态下会开始机械地"Accept Left"。
我遇到这种规模的冲突，第一反应是中止合并，回到起点重新规划。IDEA 里的操作是 Git 工具窗口右上角或者右键项目 →Git→Repository→Abort Merge，它会把工作区完整恢复到合并前的状态。这一步没有副作用，随时可以做。
退回来之后有三条路。一是缩小合并粒度，看看能不能先把对方的某几个提交单独合进来，分批解决冲突。二是先在命令行做一次 dry run，git merge --no-commit --no-ff <分支>可以在不提交的情况下看完整冲突列表，配合git diff --name-only --diff-filter=U列出所有冲突文件，心里先有个数。三是找对方一起看，两个人对着一个屏幕解决冲突的速度，通常比一个人闷头搞快三倍，因为很多冲突本质上是"我不知道你为什么要这么改"。
我个人的经验是，超过十个文件的冲突，八成意味着这条分支分叉太久，或者中间有过一次大规模的目录调整。这时候解决完冲突只是治标，真正要做的是缩短分支生命周期，从流程上不让这种情况再发生。
4.3 用对比工具把"看不出来"的差异摊开
有些冲突在 IDEA 的合并视图里看着没差别，但 git 就是认为冲突。这时候需要换个视角。Git 工具窗口 → Log 里选中两个提交（按住 Ctrl 多选）→ 右键Compare Versions，能看到完整的双向差异。或者对单个文件，右键 →Git→Show History，看这个文件的演变过程，往往能发现是哪次提交引入了格式变化。
另一个好用的动作是Compare with Branch：在当前文件上右键 →Git→Compare with Branch→ 选目标分支，直接看这个文件在两边的差异，绕开了合并状态本身的复杂性。排查"为什么这个文件老是冲突"的时候，这个视角比合并界面清楚得多。
还有个小技巧：在合并冲突的编辑器里，Ctrl+Alt+Shift+←和→（Mac 上是Cmd+Alt+Shift+←/→）可以在冲突块之间快速跳转，比用鼠标滚轮找<<<<<<<快得多。快捷键如果和你本地的其他插件冲突，可以在 Settings → Keymap 里搜Accept Left/Accept Right/Go to Next Conflict重新绑定。我一般把跳转绑到不常用的组合键上，冲突处理效率提升非常明显。
5. 常见问题与排查速查
5.1 合并之后代码"消失了"，怎么定位
这是最吓人的一类问题：合并完发现某个同事的改动不见了。先别慌，绝大多数情况不是代码丢了，而是被后续的提交覆盖或者合并方向反了。
排查顺序是这样的。第一步，在 Git 工具窗口的 Log 里找到那条合并提交，右键 →Show Diff with Working Tree或者直接双击查看它带进来的所有改动，确认那个"消失"的文件在不在这次合并的变更列表里。第二步，如果不在，说明目标分支里根本没有那个改动——问题出在源头，去目标分支看它有没有被正确提交。第三步，如果在对的提交里，但当前文件里没有，用git log -p -- <文件路径>（或者 IDEA 里对该文件 Show History → 选中提交看 diff）追踪这个文件的所有变更，找出是哪次提交把它改回去了。
我遇到过一次真实情况：合并时冲突块两边都改了同一个方法，当时我图快点了 Accept Right，把本地新增的十几行逻辑整段丢掉了。这类问题的特征是合并提交本身的 diff 里就能看到被删除的行，所以第一步的检查最关键。
建议：重要合并解决完冲突后，别急着点提交，先在 Result 窗口里从头扫一遍最终的完整文件，而不是只看冲突块。整段被吞掉的情况，只有通读才能发现。
5.2 合错了怎么办：三种回滚手段的选择
回滚手段要按"提交是否已经推到远端"和"有没有别人拉过"来选。
本地未推送的合并，最干净的是git reset --hard <合并前的哈希>，直接把分支挪回去，合并提交和冲突解决过程全部消失，工作区也回到干净状态。IDEA 里对应的操作是 Log 里右键那条合并提交之前的提交 →Reset Current Branch to Here→ 选 Hard。
已推送但没人拉过，可以用git reset之后再 force push。但这一步风险高，做之前必须在群里确认，哪怕只有一个人拉过，都会造成他那边的历史分叉。
已推送且有人拉过，只能用git revert -m 1 <合并提交哈希>生成一个反向提交。这里的-m 1表示保留第一父提交（也就是你合并前所在的分支）那条线，撤销另一条线带进来的改动。这个操作在 IDEA 里可以通过右键合并提交 →Revert Commit完成，但它默认不带-m参数，遇到合并提交会报错，需要切到终端补参数。这是个实实在在的坑，我第一次踩的时候在报错信息上卡了半天。
| 场景 | 手段 | 风险 |
|---|---|---|
| 本地未推送 | Reset --hard | 无，工作区未提交改动会丢 |
| 已推送、无人拉取 | Reset + Force Push | 中，需全员确认 |
| 已推送、有人拉过 | Revert Commit（带 -m） | 低，保留历史 |
| 只需撤销单个文件 | Checkout 该文件到指定版本 | 低，影响面最小 |
5.3 IDEA 显示的状态和实际 git 状态不一致
这类问题出现频率不低，典型表现是：分支面板显示的分支名和终端git status不一致；明明已经解完冲突，文件还是红的；或者提交列表里多了一条你没见过的提交。
根本原因通常是 IDEA 的缓存没跟上，或者是外部操作（终端、其他工具、甚至文件同步软件）改变了仓库状态而 IDEA 没有及时感知。处理办法从轻到重：先点 Git 工具窗口左上角的刷新按钮（Refresh）；不行就在 Settings → Version Control → Git 里确认 git 可执行文件路径没变；再不行用File→Invalidate Caches清一次缓存重启。
还有一个高频诱因是索引文件被锁。如果你在终端里跑了一条耗时很长的 git 命令（比如大仓库的 gc），同时又在 IDEA 里操作，可能触发index.lock残留，此后所有操作都报错。解决方法是关闭所有 git 相关进程，删掉.git/index.lock。这个文件本身没有内容，删它不会损坏仓库，它只是一个互斥锁标记。
另外提一句，IDEA 的 Git Log 面板有缓存机制，有时候刚推完的提交在面板里要过几秒才出现。看到"少了一条提交"先别急着重推，等两秒再刷新，或者切到终端git log --oneline -5核对一下。
6. 把合并变成流程的一部分，而不是救火现场
6.1 分支生命周期决定了冲突的规模
前面提到"超过十个文件的冲突八成意味着分叉太久"，这里展开说说。分支的生命周期长短，直接决定了合并时的冲突规模，而冲突规模又直接决定了合并事故的概率。一条活了两周的特性分支，和主干之间的差异通常已经大到无法靠人工逐块判断。
我的经验阈值是这样的：特性分支超过三天没和主干同步，就要主动做一次追平（merge 主干进当前分支，解决小规模冲突，推远端）。这个动作看起来增加了操作频率，实际上把一次大冲突拆成了若干次小冲突，每次都在可控范围内。在 IDEA 里做这件事的成本很低——Fetch、切分支、Merge into Current、处理几个冲突块、提交，熟练的话两三分钟。
还有一个团队层面的约定值得推：主干合并冻结窗口。发版前一天到发版当天，主干不接受特性分支合入，只接受修复。这个约定能避免"合并进去之后发现有问题，但已经跟着发版流程走了"的尴尬。
6.2 我个人的几条合并纪律
最后分享几条这些年形成的习惯，都是踩过坑之后固化下来的。
合并方向和分支名要念出来。点 Merge 之前，心里默念一遍"把 A 合进 B"，然后确认界面上选中和当前的关系匹配。听起来傻，但真的能防住大部分方向错误。
合并前必看 diff 列表。分支面板里Compare with Current，扫一遍文件名。看到意外删除的文件、意外的配置改动、意外的二进制文件，立刻停下来查。
冲突解决完通读整个文件。只看冲突块会漏掉整段被吞的情况，尤其是方法级别的冲突。通读一遍的成本是几十秒，收益是避免一次线上事故。
合并后不急着 push，先编译。语义冲突（比如两边各改了一个方法签名）git 完全无感，只有编译器能抓出来。
重要分支合并前打临时 tag。回滚的时候你会感谢自己。
Cherry-Pick 之后在提交信息里标注来源。写一句"cherry picked from <哈希>"，将来排查重复代码时能救命。
团队统一.gitattributes和格式化配置。这是唯一能根治伪冲突的办法，越早做越省事。
这些纪律单独看都很琐碎，但合在一起就是一套能挡住绝大部分事故的防线。我在实际使用中最大的体会是：IDEA 把合并这件事做得太顺了，点几下就完成，反而容易让人忽略它其实是在移动一整条分支的历史。工具越省事，越需要你自己慢下来确认方向。尤其是那个Merge into Current的按钮，它和旁边的Checkout、Rebase挨得很近，菜单展开的瞬间手滑点错，代价可能就是半小时的恢复工作。所以我现在的习惯是，涉及主干或发布分支的合并，宁可切到终端敲git merge --no-ff <分支名>，多打几个字，换一份确认感——这不是不信任工具，而是知道自己在哪一步最容易犯错。
