Git变基失败时如何输出差异到命令行而非修改文件？

一、如何阻止Git Rebase在冲突时修改文件 #

Git Rebase默认遇到冲突时，会把冲突标记（比如<<<<<<<、=======、>>>>>>>）写入冲突文件，让你手动解决。如果想避免这种文件修改，有两个实用方法：

• 提前预检查，避免实际修改：在执行真实的rebase之前，先运行git rebase --dry-run <target-branch>。这个命令会完整模拟rebase的过程，告诉你哪些提交会触发冲突，但不会对工作区或仓库做任何实际修改。这样你可以提前知道风险，决定是否继续。
• 冲突发生后快速回滚：如果已经触发了冲突、文件被修改，别慌，直接执行git rebase --abort。这个命令会立刻撤销所有rebase带来的变更，把仓库和工作区完全恢复到rebase开始前的状态，文件自然也就回到了未修改的样子。

二、把冲突的差异（目标×补丁）输出到命令行 #

当rebase卡在冲突时，要查看目标分支和当前待应用提交的补丁差异，你可以用这些命令：

• 查看当前冲突提交的完整补丁：Git会在冲突提示里告诉你当前正在应用的提交信息（比如Applying: 修复支付流程bug），你可以用git show <commit-hash>（把<commit-hash>换成这个提交的哈希值）直接查看该提交的原始补丁。
• 对比目标分支和当前文件的差异：针对单个冲突文件，运行git diff <target-branch>:path/to/conflict-file path/to/conflict-file。这个命令会直接显示目标分支上的文件版本，和当前工作区中带冲突标记的文件版本之间的差异，帮你快速定位冲突点。
• 简洁查看冲突文件列表：如果想先知道哪些文件冲突了，用git diff --name-only --diff-filter=U，它会只列出存在冲突的文件路径，方便你逐个处理。

关于你用Cherry-Pick的替代方案 #

其实你用git cherry-pick -X theirs + git diff + git commit --amend的流程，本质是手动模拟了rebase的部分逻辑，虽然不够直观，但胜在完全可控——毕竟自己掌握每一步的变更，心里更踏实。不过如果哪天想尝试rebase了，上面的方法应该能帮你解决之前的痛点。

内容的提问来源于stack exchange，提问作者aleskva