Git 重构后合并-检测移动的文件部分

我有两个分支机构，其结构如下：

---(commit 1) ----- (commit 2, refactoring) ----(CONFLICT) 
        \                                      /
         \                                    /
          -----(commit 3, modifying) --------/

在

commit 1

中，我有一个文件

text.txt

：

Part 1:
  line 1
  line 2
  line 3
Part 2:
  line 4
  line 5
  line 6

Part 1:
  line 1
  line 2
  line 3

Part 2:
  line 4
  line 5
  line 6

Part 1:
  line 1
  line 2a
  line 3
Part 2:
  line 4
  line 5b
  line 6

在

commit 2

中，我将

text.txt

的“第2部分”提取到

part2.txt

中，因此我得到：

• text.txt

  ：

  Part 1:
    line 1
    line 2
    line 3
  Part 2:
    line 4
    line 5
    line 6
  

  Part 1:
    line 1
    line 2
    line 3
  

  Part 2:
    line 4
    line 5
    line 6
  

  Part 1:
    line 1
    line 2a
    line 3
  Part 2:
    line 4
    line 5b
    line 6
  

• part2.txt

  ：

  Part 1:
    line 1
    line 2
    line 3
  Part 2:
    line 4
    line 5
    line 6
  

  Part 1:
    line 1
    line 2
    line 3
  

  Part 2:
    line 4
    line 5
    line 6
  

  Part 1:
    line 1
    line 2a
    line 3
  Part 2:
    line 4
    line 5b
    line 6
  

在

commit 3

中，我稍微修改了

text.txt

的两部分：

Part 1:
  line 1
  line 2
  line 3
Part 2:
  line 4
  line 5
  line 6

Part 1:
  line 1
  line 2
  line 3

Part 2:
  line 4
  line 5
  line 6

Part 1:
  line 1
  line 2a
  line 3
Part 2:
  line 4
  line 5b
  line 6

合并两个分支我希望git足够聪明，将

第2a行

放入

text.txt

中，将

第5b行

放入

part2.txt

。不幸的是，这没有发生

我的期望是基于这样一个事实，

git gui.txt

检测正确显示

text.txt

的行的起源

我的问题是：

• 为什么它不能开箱即用
• 是否有已知的解决方法

---

我没有看到与您使用

git-gui-part2.txt时相同的结果。我在执行任务2
git-gui
不显示
text.txt
。无论如何，要回答您的问题：


如果它“开箱即用”，您认为在以下场景中会发生什么：在提交3中，您将
第5行
更改为
第5b行
。与此同时，在commit 2中，出于某种原因，有人将“Part 2”行移动到两个相同的文件中：
part2a.txt
和
part2b.txt
。git现在是否应该自动将这两个文件更改为第5b行

Git不会尝试做出这样的决定，而是让你自己做决定

如果这种冲突频繁发生，则会出现
git-rere
。否则，您将需要手动处理。幸运的是，有一个
merge.conflictstyle=diff3
configuration选项，它在基本提交以及两个冲突提交中显示文件的内容。这使得我们很容易看到哪一方改变了什么，以及原来是什么。有关详细信息，请参见
git merge
手册页

我减少了示例文件中的行数，因此git可能无法识别移动的部分。但总体来说效果很好。谢谢你的回答！我知道，没有完美的解决方案。但常见的情况是简单的提取。我建议git生成冲突，但不是在text.txt中，而是在part2.txt中。这将引起人们对潜在问题的注意，并指出可能的正确解决方案。考虑新的“合并移动”的建议=（是的，冲突不）选项。