ClearCaseでは、ディレクトリの2つの異なるバージョンで同じ名前の2つのファイルが見つかった場合、および要素のOIDが異なるが名前が同じである場合に、悪の双子が発生します。
GITでは、SHA1 IDは常に一意であり、同じ名前のファイルは常に異なるSHA1IDを持ちます。
邪悪な双子の概念はありませんが、2人以上の開発者が同じディレクトリに同じファイル名で異なる内容のファイルを作成する可能性があります。マージ中に、両方のファイルが完全に異なる場合、開発者は自分の変更をそのままにして、他の変更を残してコードを失う可能性があります。
ClearCaseと同様の問題がGITにあるかどうか、または各SHA1 IDが一意であるかどうかを誰かに知らせてもらえますか？GITに悪の双子の問題はありません。
Gitは、個々のファイルやディレクトリではなく、ツリー全体のレベルで追跡を行うため、OIDのような概念はありません。
互換性のないファイルへの変更を含む履歴をマージする場合（たとえば、両方が異なる内容の新しいファイルを追加した場合）、Gitはマージの競合を生成し、ユーザーが競合を解決するか、マージを中止できるように停止します。
もちろん、Gitはマージを行うユーザーに正しいことを強制することはできませんが、競合の一方の側面を完全に無視することはおそらくより困難です。Gitでは、競合はファイルを保持するディレクトリではなく、ファイル自体に発生します。つまり、競合はファイルの内容に関するものであり、代わりにOIDをディレクトリにリンクする必要があります。もちろん、使用するツールによっては、ユーザーは「すべての競合で私の側に立つ」を押すだけでもかまいませんが、Gitは少なくとも気にしません（怠惰なラウトの上司や同僚は非常に気にするかもしれませんが！）。
いいえ、ただしヘッドが外れています。申し訳ありませんが、自分自身を助けることができませんでした:)
2番目の開発者がプッシュを実行する前にプルすると、ファイルが競合として表示されます。ファイルが完全に異なる場合、ファイル名が異なる必要があることは明らかです。次に、2番目の開発者が何かを行います（つまり、競合が発生しないようにファイルの名前を変更します）。
はい、Gitにはある種の「邪悪な」操作がありますが、ClearCaseの邪悪な双子と同じ理由ではありません。
それらは邪悪なマージと呼ばれます：
どの親にも表示されない変更を導入するマージ。
つまり、ファイルに注釈を付けるときに「git blame」が解決するのが難しいコーナーケースであるため、「evilmerge」という名前のコードに誰もそこにいることを要求しなかったものを入れます。
これらのマージは通常、2つのバージョンのマージ間のセマンティックの競合に関連しています（単純なテキストの競合ではありません）。
副作用として、変更された行を追加、削除、または変更する代わりに、（マージされる2つのバージョンからの）両方の行がマージ結果に表示されることになります...
ああ邪悪な双子のエラー、それは私を取り戻します。いいえ、gitでそのようなエラーが発生することはありません。Gitは、ファイルのチャンクを追跡するため、実際にはファイル全体を追跡しません。