git合并冲突频发主因是分支长期未同步导致三方合并基点过老，引发大量格式性“假冲突”；应通过预检、忽略空格差异、统一换行符规范及语义化工具来减少无效冲突。

Git 合并冲突没法“跳过”，但可以大幅减少手动编辑量——关键不是更快删标记，而是让 Git 少报冲突、工具多识别语义、历史能复用。

为什么 git merge 一执行就满屏 CONFLICT？

根本原因常被忽略：不是代码改得多，而是分支长期没同步。Git 的三方合并（base + HEAD + other）依赖共同祖先，如果两个分支从几周前的提交分叉，base 太老，哪怕只改了一行，也可能因空白、换行符或注释差异触发大量“假冲突”。比如 unix2dos 改了所有行末符，再加一行业务修改，Git 就会把整文件标为冲突。

• 运行 git merge --no-commit --no-ff feature-branch 预检：不真正提交，只生成暂存区，方便 git status 查看哪些文件真有内容冲突，哪些只是格式抖动
• 对疑似格式冲突的文件，先用 git diff -b（忽略空格）或 git diff --ignore-space-change 确认是否真有逻辑差异
• 若只是换行符问题，提前统一团队的 .gitattributes，例如设置 * text=auto eol=lf，避免 DOS/Unix 混用

用 VS Code 合并编辑器跳过

VS Code 内置的合并视图不是锦上添花，而是直接绕开文本级冲突处理。它基于 AST（抽象语法树）感知代码块边界，对函数重命名、if 块增删等场景比纯行对比准确得多。

Git Pushing

使用约定式提交信息暂存、提交和推送git更改。当用户想要提交和推送更改、提到推送到远程、或要求保存并推送工作时触发。也适用于用户说“推送更改”、“提交并推送”、“推送这个”、“推送到github”或类似git工作流程请求时。

下载

• 打开冲突文件后，点击顶部 “Accept Current Change” / “Accept Incoming Change” / “Accept Both Changes” —— 这些按钮不是简单覆盖，而是按语法单元合并，比如保留左侧函数签名 + 右侧新增的 cache.set() 行
• 遇到语义冲突（如两边都改了 authenticate()，但逻辑互斥），别点“Accept Both”，右键冲突块选 “Open Changes in Merge Editor”，在三栏视图里手动拖拽逻辑块到中间面板
• 解决后务必点击 “Accept Merge”，否则文件仍处于未解决状态，git status 会持续显示冲突

让 Git 记住你上次怎么解的：启用 rerere

rerere 不是“一键解决”，而是让重复冲突自动消失。它记录的是“冲突上下文 + 你最终删了哪段、留了哪段”，下次同一段代码再次冲突，Git 直接照搬你的操作。

• 全局启用：git config --global rerere.enabled true（项目级去掉 --global）
• 首次冲突解决后，.git/rr-cache/ 下会生成哈希目录，里面存着原始冲突块和你的解决方案
• 后续遇到相同冲突（哪怕在不同分支、不同时间），git merge 会静默应用记录，git status 不再列出该文件
• 注意：rerere 对重构类冲突（如函数重命名后调用位置变化）无效，它只匹配原文本模式

冲突解决后，git add 之前必须检查什么？

很多人 git add . 一把梭，结果把未解决的冲突标记一起提交了——这些标记是合法的 Python/JS 语法吗？不是。它们会变成真实 bug。

• 运行 git status，只 add 明确显示 “both modified” 且你已编辑过的文件；对状态仍是 “unmerged” 的文件，说明还没真正解决
• 用 git diff --cached 检查暂存区内容，确认冲突标记（ 等）已彻底删除，且逻辑符合预期
• 如果用了 rerere，合并后 git status 可能显示 “nothing to commit”，但这不代表没做任何事——它已自动应用记录，直接 git commit 即可

真正卡住人的从来不是单个冲突，而是同一段逻辑在多个分支间反复冲突。与其每次重解，不如把 rerere 当作团队共享的冲突词典，再配合 VS Code 的结构化合并，让 Git 停止问“你要哪一行”，转而问“你要哪一段逻辑”。