在 ClearCase 中，当在两个不同版本的目录中找到具有相同名称的两个文件时，如果元素 OID 不同但名称相同，则会发生邪恶孪生。
在 GIT 中，SHA1 id 总是唯一的，同名的文件总是有不同的 SHA1 id。
我们没有邪恶双胞胎的概念，但在某些情况下，可能会有 2 个或更多开发人员在同一目录中创建具有不同内容但文件名相同的文件。在合并期间，当两个文件完全不同时，开发人员有可能单独保留他的更改而留下其他更改，从而导致代码丢失。
任何人都可以让我知道 GIT 中是否会出现类似于 ClearCase 的问题，或者每个 SHA1 id 都是唯一的，GIT 中不会出现任何 Evil twin 问题。
Git 在整个树的级别进行跟踪，而不是单个文件和目录，因此它没有像 OID 这样的概念。
当合并包含对文件的不兼容更改的历史记录时（例如，两者都添加了具有不同内容的新文件），Git 将产生合并冲突并停止让用户解决冲突或中止合并。
当然，Git 不能强迫执行合并的用户做正确的事，但也许更难完全忽略冲突的一侧。在 Git 中，冲突将在文件本身中，而不是在保存文件的目录中。换句话说，冲突将与文件的内容有关，而不是应将哪个 OID 链接到目录中。当然，根据使用的工具，用户可能仍然只是按下“在所有冲突中站在我这边”，但 Git 不会在意（尽管懒惰的 lout 的老板和同事可能非常在意！）。
是的，Git 中有某种“邪恶”操作，但原因与ClearCase 的邪恶双胞胎不同：
它们被称为邪恶合并：
引入未出现在任何父项中的更改的合并。
即：将没有人要求存在的东西放入代码中，命名为'evil merge'，因为在注释文件时很难解决“git blame”的极端情况。
这些合并通常与两个版本合并之间的语义冲突有关（而不是简单的文本冲突）。
一个副作用是，您最终会在合并结果中得到两行（来自被合并的两个版本），而不是添加、删除或修改已更改的行...
不，但是有一个分离的头。对不起，忍不住：）
会发生的情况是，当第二个开发人员在推送之前拉动文件时，文件会出现冲突。当文件完全不同时，很明显它们应该具有不同的文件名。然后第二个开发人员将做一些事情（即重命名他的文件，以免发生冲突）。
哦，邪恶的双胞胎错误，这让我回来了。不，你不应该在 git 中有任何这样的错误。Git 实际上并没有跟踪整个文件，而是跟踪文件块。