GIT有邪恶的孪生问题吗？

在ClearCase中，当在两个不同版本的目录中发现两个同名文件，并且元素OID不同但名称相同时，就会发生邪恶孪生

在GIT中，SHA1 id总是唯一的，并且具有相同名称的文件总是具有不同的SHA1 id

我们没有邪恶孪生兄弟的概念，但可能有两个或更多的开发人员在同一目录中创建具有相同文件名的不同内容的文件的情况。在合并过程中，当两个文件完全不同时，开发人员可能会保留自己的更改，而保留其他更改，从而导致代码丢失

---

有人能告诉我GIT中是否会出现类似ClearCase的问题，或者每个SHA1 id都是唯一的，GIT中不会出现任何邪恶孪生问题。

哦，邪恶孪生错误，这让我回过神来。不，在git中不应该有任何这样的错误。Git实际上并不跟踪整个文件，而是跟踪文件块

没有，但有一个。对不起，我忍不住：）

---

可能发生的情况是，当第二个开发人员在进行推送之前进行拉送时，文件会出现冲突。当文件完全不同时，显然它们应该有不同的文件名。然后，第二个开发人员将采取措施（即重命名其文件，以避免冲突）。

是的，Git中存在某种“邪恶”操作，但原因与以下原因不同：

它们被称为：

一种合并，它引入的更改不会出现在任何父级中

也就是说：将一些没有人要求的东西放入代码中，命名为“邪恶合并”，因为在注释文件时，“git责怪”很难解决这个问题。
这些合并通常与两个版本合并之间的相关（而不是简单的文本冲突）。

---

一个副作用是，不是添加、删除或修改更改的行，而是在合并结果中使用两行（来自合并的两个版本）…

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

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

---

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

Git确实跟踪整个文件（在存储库数据表示中）。但是，基于存储库构建的工具可以自由地显示为跟踪块（如果他们选择这样做的话）。Git确实跟踪整个文件，或者如果您愿意，跟踪整个文件的内容？我也在做同样的事情！！；）：）在过去的3.5年里，我一直在研究ClearCase，现在我们正在从CC迁移到GIT。所以我一直在尝试GIT中的各种选项，并检查CC中的问题是否发生在GIT中。冯，你对大多数问题的回答都很有帮助，非常感谢。“现在我们正在从CC迁移到GIT”，你真幸运。我也在试图把Git偷偷带进我的公司。经过8年多的ClearCase和Subversion（偶尔还有Performce或CM Synergy），这是令人耳目一新的；）你有兴趣在美国工作吗？ask4thunder@gmail.comWell，正如我所评论的，这并不是一个Git现象；使用Git是一种不明智的方式。Git有很大的能力让你做一些你通常不应该做的事情！