如果git可以弄清楚如何合並垂直（線條）更改，為什么不合並水平（字符）更改？

Question

如果提交Apple在行1上放置“ a”，而在香蕉行3上進行提交香蕉，則git可以將這些提交合並在一起沒有問題，但是如果“ a”在行1的開頭並且“ b”在行的開頭跨過9個字符，它會窒息，不知道如何合並它們，您必須手動執行。

為什么無法弄清楚呢？

即使像這樣編輯同一行：

original commit:       <question1 states="AZ,OH">
commit Orange line 25: <question1 states="AZ,IN,OH">
commit Pear line 25:   <question1 states="AZ,OH,TX">

Git merge無法弄清楚在OH之前要放IN，在TX之后要放，但是我作為一個人可以很容易地知道如何做到這一點，並且我使用了比較編輯器（如KDiff3）為我指出了確切的字符發生了變化（以顏色區分），而git僅以實線顯示更改。

KDiff3示例：

我只是無法判斷git認為Orange中的OH更改為IN，OH，或者是否進行了過多的處理以檢查是否僅在OH之前添加了IN ...但是也許有一個更好的合並工具可以解決這個問題？

Answer 1

Git的內置合並算法使用Git的內置diff（面向行）。 真的就是這么簡單：它看到兩個差異，其中一個說“用行B替換行A”，其中一個說“用行C替換行A”，兩個替換不同=>沖突。

如果提供了自定義合並驅動程序，則可以運行自己的差異文件並進行自己的合並。 不過，這一點也不小。 在這種特殊情況下，可以使用兩次遍歷算法（第一，查找更改的行；第二，查看是否可以將更改的行作為更改的字符來處理）。