好的，基本上其中一个开发人员搞砸了。我会尝试缩短它，以便更容易理解。
我们在/src/SomeFile.php
master个文件
开发人员创建一个名为task-1
对/src/SomeFile.php和master
task-1进行单独更改
到目前为止一切正常。
开发人员决定更改master中的文件结构，并将/src/SomeFile.php移至/src/newdir/SomeFile.php。除非他不使用git移动文件，否则他会创建一个新文件，将旧文件中的代码复制并粘贴到新文件中，并删除旧文件并进行提交。
提示更多提交，我们希望从task-1合并到master，并发现/src/newdir/SomeFile.php的提交历史记录不包含原始提交历史记录它仍然是/src/SomeFile.php
所以现在当我们想要进行合并时，它想要完全覆盖master中的文件，无论自分支以来发生的任何提交，都使用task-1中的文件和我对于合并冲突没有任何意义，因为它显示整个文件是不同的。
我该如何解决这个问题。我已经回滚了合并。在理想的世界中，我可以在文件移动之前返回到版本，使用git移动文件，以便保留它的提交历史记录，然后让git重新应用文件中的所有提交移动到右上方当当前的主版本（预合并），这样我们就可以成功合并了。但是，我知道那是不可能的。
所以我想知道，如果有反正我可以告诉git这个新文件，实际上是旧文件，但在不同的地方，所以它会重新应用文件历史记录，以便我可以做一个当出现冲突时，合并并获得有意义的差异。
对不起，如果不清楚，我已尽力解释。
修改
所以在github上玩，如果我查看“新”文件/src/newdir/SomeFile.php并查看它的历史记录，它只会显示文件被“移动”时的提交历史记录（复制/粘贴到新文件中） ，删除旧文件）。但是，如果我看“责备”，它会给我一个完整的提交历史记录，即使是从原始文件。为什么这种方式只会受到指责，我怎么能把它放在两者中呢？
非常感谢任何帮助。
答案 0 :(得分：1)
如果您正在使用git 1.7.4+，您可以尝试使用＆＃34; rename-threshold＆＃34;合并期间的参数（以％为单位），以便让git考虑重命名候选文件。例如：
git merge -X rename-threshold=25
这是我能想到的唯一方法，因为git在技术上并不具有一流实体重命名的概念。它只是检测文件重命名。