Question

因此，在上一次提交中，我有如下文件：

001.jpeg  
002.jpeg  
003.jpeg  
004.jpeg

由于无法控制的过程，工作目录现在如下所示：

001.jpeg (but this is the file that was formerly named 002.jpeg)  
002.jpeg (and this is the file that was formerly named 001.jpeg)  
003.jpeg (but this is the file that was formerly named 004.jpeg)  
004.jpeg (and this is the file that was formerly named 003.jpeg)

（幕后数据库确保这不会破坏应用程序）

如果我执行git status，则会将所有四个文件显示为已修改。

当仓库中有一个文件现在被视为已删除，并且在另一个路径中有一个新文件时，

Git重命名检测似乎可以正常工作尚未添加到存储库中。

是否有任何方法可以获取git重命名检测（或其他命令的巧妙组合），使其能够识别上面的重命名，即使旧名称和新名称仍在回购协议中，只是其中的数据不同？

Answer 1

简短的回答是“否”。

更长的答案是“不，这无关紧要”，当然，在合并过程中，当重要重要时除外。但是在那里，您仍然必须进行修复，因此您最好在合并之前解决重命名问题，然后再无所谓。

请记住，每个提交都是纯快照。因此，假设您有：

...--F--G--H--...

其中每个大写字母代表一个实际的提交哈希ID。提交H的父级是提交G；其父节点为F。

提交F包含内容C _x和C _y，名称分别为FN1和FN2。

在提交G中，相同内容出现在名称FN2和FN1中，即被交换了。

在提交H中，相同内容出现在名称FN1和FN2中，即被换回。

Git分别恰好存储一次C _x和C _y。提交F和H表示分别将它们放入FN1和FN2中，而提交G说将它们分别放入FN2和FN1中。只有两个存储的文件。比较F与G会显示每个文件更改的全部内容，而G与H会显示再次更改的整个内容，但将F与{{ 1}}直接显示完全没有变化。

即使在H，F和/或G之间存在提交，这也是正确的：

假设您现在需要合并，并且还没有已经提交了...--F--o--o--G--o--H--o--...，但是您还有其他人：

您希望合并提交o--o--G--o--...--K <-- branch1 / ...--F \ o--------...--------L <-- branch2和K以进行合并L，但是由于M，文件 names 被弄乱了在G中。如果您运行：

Git将diff git checkout branch1; git merge branch2与F进行比较，并认为文件FN1和FN2已完全更改。它将比较K与F并认为这两个文件是不变的，除非一个或两个文件被改进的文件替换。您可以进行合并，并处理任何合并冲突。但是您也可以首先添加提交L，除了将名称交换回去之外，什么都不做：

现在o--o--G--o--...--K--H <-- branch1 / ...--F \ o--------...--------L <-- branch2将git merge branch2与F进行比较，发现文件FN1和FN2均未更改（因为它们未更改！）。它将比较H与F并查看这两个文件（如果有）中的实际变化。 Git将能够将它们自己组合起来并产生合并L：

您可以在此处的顶行o--o--G--o--...--K--H / \ ...--F M <-- branch1 \ / o--------...--------L <-- branch2 之后的任意位置进行名称重新排列，“没有实际更改，但修正了混乱的文件名” H 。或者，如果您喜欢 names 的新排列，则可以随时沿底线进行类似的提交。

如果您正在使用命令行Git，则在运行G之前进行此操作的目的只是为了简化git merge步骤而进行的优化。（但是请注意，如果您使用GitHub clicky按钮进行合并，这不是简化步骤，实际上是 required ，因为GitHub的clicky按钮不会让您修复冲突的合并。）

git可以对已经存在的文件使用重命名检测吗？

1 个答案: