Git：将更改合并到早期提交的正确方法（手动回放？）

我不确定git中解决这种情况的正确方法是什么，无论我做什么，都会得到奇怪的结果

我有一个文件的X版本，在commitish a中。随着时间的推移，此文件已被修改，现在位于commitish a’

有人给我发了一封电子邮件，文件X'是commitsh a中包含的文件的修改版本。重要提示：此更改是带外的（通过电子邮件而不是git）和过期的（对文件早期版本的更改）

用git术语来说，我确切地知道我“想要”做什么，但我不确定实现它的最干净的方式：倒带、提交、重播。我假设它应该是那么简单，我知道git在内部做这件事，当它重新调整时，但我自己无法让它工作

我所做的：

• 签出并基于委托A创建新的分支B
• 复制并粘贴更改的文件
• 提交更改
• 结帐分行主管
• 合并分支B

我的问题是分支B与主分支的合并会导致文件中所有行的冲突

文件中的变化（我认为这就是原因）如下：

A版：

line 1
line 2
line 3

分行主管：

line 1, file 1
line 2, file 1
line 3, file 1

电子邮件文件：

line 1
line B
line 3

如您所见，分支母版包括对所有行的更改，但这些行保持不变。带外更改是对第2行的修改

合并告诉我文档中的所有行都是冲突的。我可以理解git是否无法将第2行的更改合并到两个版本中，但我不理解为什么所有3行都被标记为冲突

---

谁能帮帮我吗？

我想你回答了你自己的问题

如您所见，分支母版包括对所有行的更改

---

合并时，Git不知道哪一组更改对您更重要。您必须自己做出选择。

如果我错了，请纠正我的错误，但看起来您实际上想运行

git-rebase B

作为最后一步，而不是

git-merge B

---

但是，这三行可能仍然存在合并冲突，因为这些行彼此非常接近，git不想假设冲突只发生在第2行而不是第1-3行。

我不确定这是否是“正确”的解决方案，但除非有其他解决方法，否则我将接受这一点：

---

通过将git配置为使用外部diff/merge编辑器，在本例中是神奇而强大的BeyondCompare3，我能够解决这个问题。BC3有更精细的变化“块”，在同一行中检测修改。虽然我仍然需要手动合并更改，但它只将单独更改的行标记为已更改（尽管它确实显示Git已经检测到一个更大的周围块被修改，但它给了我覆盖它的选项）。

我明白了。但是第1行和第3行仅在master中更改，而在新分支中没有更改。为什么它们会出现冲突？如果存在实际冲突，Git会将附近所有更改的行标记为冲突。如果某个地方有足够多的未更改行（例如多个空行），那么只有有冲突的组才会被标记为冲突。在我的实际案例中有6行，只有第4行被更改。我可以缩小这个窗口吗？你检查过线的末端了吗？Windows CRLF与Unix/Max LF。使用默认的git设置，它可以标记不是真正冲突的冲突。您能解释一下为什么倒带、修补、重放方法比简单地计算delta=diff X X'和将修补程序“delta”应用到最新版本的X更好吗？确实，受“带外”修补程序影响的行也可能因文件的git历史记录中的更改而被修改，但这要么（由您）直接解决，要么（由git）在“重播”序列中以某种方式解决。@Peter：没有任何理由。事实上，这就是我最后做的。但我想知道为什么这种方法不起作用。在这种情况下，重定基础和合并都有相同的结果。是否无法“降低”合并冲突的敏感性？告诉它每一行都是绝对独立的（不是代码）？