git pull --rebase 更适合日常拉取，因其重放本地提交到远程最新head后，保持历史线性干净，避免无意义merge commit；需注意不用于已推送的公共分支。
git pull --rebase 为什么比 git pull 更适合日常拉取
默认 git pull 是 git fetch + git merge 的组合，会无条件创建一个 merge commit，哪怕本地和远程只是线性演进。这导致历史里堆满无意义的「Merge branch 'main' into main」提交，干扰 bisect、blame 和 code review。
而 git pull --rebase 把你的本地提交“重放”到远程最新 HEAD 之后，保持提交历史干净线性。它不会自动解决冲突，但把冲突暴露在 rebase 过程中，更利于逐个定位和清理。
- 适用场景：你只在自己分支上提交，且不介意重写本地提交哈希（未推送前安全）
- 注意：不要对已推送到远程的公共分支使用
--rebase，否则会强制覆盖他人引用 - 可设为默认：运行
git config --global pull.rebase true，之后所有git pull等效于git pull --rebase
如何用 alias 定义一键拉取+自动跳过常规空白/换行冲突
很多冲突其实只是空格、缩进或换行符差异（比如 Windows vs macOS 的 \r\n vs \n），Git 默认把这些当作实质性变更。你可以让 git pull --rebase 忽略它们，避免卡在 trivial 冲突上。
先配置 Git 忽略空白变更：
git config --global core.whitespace "blank-at-eol,blank-at-eof,space-before-tab,tab-in-indent,cr-at-eol"
再定义一个自定义命令 alias：
git config --global alias.pullclean '!f() { git pull --rebase --strategy-option=ignore-space-change --strategy-option=ignore-all-space "$@"; }; f'
之后直接运行 git pullclean 即可拉取并跳过纯空白类冲突。
-
--strategy-option=ignore-space-change：忽略行尾空格和内部空格数量变化 -
--strategy-option=ignore-all-space：彻底忽略所有空格、制表符、换行符差异 - ⚠️ 注意：这两个选项不能跳过逻辑冲突，仅对 whitespace 冲突有效；若文件本身有语义修改，仍会停在冲突处
git mergetool 配合 vimdiff 解决剩余冲突的实际操作
当 pullclean 仍停在冲突处，说明存在真实内容冲突。此时别手动删标记，用 git mergetool 启动可视化工具更可靠。
先确保已安装 vimdiff（macOS/Linux 自带；Windows 需装 Vim 或用 git config --global merge.tool vimdiff）：
- 运行
git mergetool，它会依次打开每个冲突文件 - vimdiff 中左侧是
LOCAL（你的版本），右侧是REMOTE（上游版本），中间是合并结果区 - 常用操作：
:diffget lo取左版、:diffget r取右版、:wq保存退出 - 退出后 Git 自动标记该文件为已解决，无需再
git add
如果想跳过某些文件不处理，按 q 退出当前文件，git mergetool 会继续下一个。
合并后如何验证是否真没漏改、没引入意外回退
很多人解决完冲突就立刻 git push，但容易忽略两个关键点：一是误删了对方的有效修改，二是保留了自己已废弃的旧逻辑。
- 用
git diff HEAD@{1}对比 rebase/merge 前后的实际变更，不是看冲突标记，而是看最终生成的代码差 - 重点检查冲突文件里被你手动编辑过的函数、配置项、API 调用——这些地方最易出错
- 如果项目有 CI，务必等测试通过再推送；没有 CI 的话，至少本地跑一遍核心流程（比如启动服务、调用关键接口）
真正麻烦的从来不是冲突本身，而是解决过程中无意识覆盖掉的他人逻辑——它不会报错，但上线后才暴露。
