GIT是否有邪恶的双胞胎问题？

Question

在ClearCase中，当两个不同版本的目录中找到两个具有相同名称的文件时，会发生恶意双胞胎，如果元素OID不同但名称相同。

在GIT中，SHA1 id始终是唯一的，同名文件总是具有不同的SHA1 id。

我们没有Evil双胞胎的概念，但有可能有两个或更多开发人员在同一目录中创建具有相同文件名的不同内容的文件。在合并期间，当两个文件完全不同时，开发人员有可能单独保留其更改并留下其他更改，从而导致代码丢失。

任何人都可以告诉我，如果GIT中存在类似于ClearCase的问题，或者每个SHA1 ID都是唯一的，那么GIT中就不存在任何邪恶双胞胎问题。

Answer 1

Git会在整个树的级别进行跟踪，而不是单个文件和目录，因此它没有像OID这样的概念。

当合并包含对文件的不兼容更改的历史记录时（例如，两者都添加了具有不同内容的新文件），Git将产生合并冲突并停止让用户解决冲突或中止合并。

当然，Git不能强迫用户做合并做正确的事情，但也许更难以完全忽略冲突的一方。在Git中，冲突将在文件本身中，而不是在包含文件的目录中。换句话说，冲突将是关于文件的内容而不是应该将哪个OID链接到目录中。当然，根据所使用的工具，用户可能仍然只是按下“在所有冲突中占据我的一面”，但Git至少不会关心（尽管懒惰的老板和同事可能非常关心！）。

Answer 2

不，但有detached head。对不起，忍不住了:)）

当第二个开发人员在执行推送之前拉出文件时，该文件将会出现冲突。当文件完全不同时，很明显他们应该有不同的文件名。然后第二个开发人员将做一些事情（即重命名他的文件，以便没有冲突）。

Answer 3

是的，在Git中存在某种“邪恶”操作，但不是出于与evil twins of ClearCase相同的原因：

他们被称为 evil merge ：

  

引入未出现在任何父级中的更改的合并。

I.e：将代码中的东西放在没有人要求的代码中，命名为'evil merge'，因为在注释文件时“git blame”很难解决。 这些合并通常与两个版本合并之间的 semantic conflict 相关（而不是简单的文本冲突）。 副作用是，不是添加，删除或修改更改的行，而是在合并结果中最终使用两行（来自合并的两个版本）...

Answer 4

哦，邪恶的双胞胎错误，让我回来了。不，你不应该在git中有任何这样的错误。 Git实际上并不跟踪整个文件，因为它跟踪文件块。