Git如何在分支变基时传递LF/CRLF行尾变更并修复历史

针对你遇到的混合行尾历史问题，以下是无需手动大量修复冲突的简洁方案，核心是先修正版本C的行尾错误，再让后续提交自动继承正确行尾并保留真实代码变更：

步骤1：备份当前分支（防操作失误） #

先创建备份分支，避免变基过程中丢失数据：

git branch backup-before-rebase

步骤2：启动交互式变基到版本B #

找到版本B的提交哈希（记为<B-hash>），启动变基并标记版本C为可编辑：

git rebase -i <B-hash>

在弹出的todo编辑界面中，将版本C对应的行改为edit，其余提交保持pick，保存并退出。

步骤3：修正版本C的行尾问题（保留真实代码变更） #

此时Git会停在版本C的修改状态，我们需要回滚意外的行尾批量变更，同时保留你在C中做的有意代码修改：

1. 提取版本C中真实的代码变更（忽略行尾差异）：

   git diff --ignore-space-at-eol <B-hash> -- path/to/target-file > real-changes.patch
   

2. 将目标文件重置回版本B的状态（恢复原混合行尾）：

   git checkout <B-hash> -- path/to/target-file
   

3. 应用真实代码变更到恢复后的文件：

   git apply real-changes.patch
   

4. 验证变更：执行git diff确认只有你有意修改的代码，无批量行尾变更；也可通过cat -A path/to/target-file查看行尾格式。
5. 提交修正后的版本C：

   git commit --amend --no-edit
   

步骤4：继续变基后续提交（自动处理行尾冲突） #

使用带合并选项的命令继续变基，让Git忽略行尾差异并优先保留后续提交的真实代码：

git rebase --continue -s recursive -X ignore-space-at-eol -X theirs

• -X ignore-space-at-eol：对比时忽略行尾差异，避免把行尾变更识别为冲突
• -X theirs：遇到冲突时优先采用后续提交（D-Z）的代码变更，同时保留当前分支（已修正行尾）的行尾格式

如果变基过程中仍有少量真实代码冲突，手动修复后执行git add .再继续变基即可。

步骤5：验证最终结果 #

变基完成后，通过以下命令确认行尾和代码变更均符合预期：

# 查看每个提交的变更，确认无批量行尾修改
git log --patch -- path/to/target-file
# 检查文件当前行尾格式
cat -A path/to/target-file

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