1

いくつかのコンテキストでは、複数の共同作業者とリアルタイムでバージョン管理と競合解決を行う必要がある分散プログラムに取り組んでおり、Git の使用を検討しています (具体的にはhttps://github.com/creationix/js- git ) ボンネットの下。各ユーザーは独自の ref を持ちますが、グローバル履歴があります (GitHub のように)。ただし、GitHub とは異なり、すべてのユーザーのフォークは等しくなければならず、プル リクエストは上流のフォークへの一方向ではありません。

私は、2 人のユーザーが独自のオフライン変更[以下に A と B として示されているコミット]を行ったばかりで、共同作業者の開発ブランチから同時にプルすることを選択するシナリオを考えています。マージが同じバージョンの Git で行われ、競合に似たものは何も見つからないと仮定すると、2 つのマージは同じツリーになりますが、(私の知る限り) マージ コミットを行うユーザーは異なるマージ コミット C と C' のハッシュは異なります (したがって、異なります)。

  ...A---C
 /    \ /
O      /
 \    / \
  ...B---C'

問題は、競合がなく、C と C' のツリーと親が同一である場合、将来的に簡単に早送りできるようにするために、それらが同じコミットであるように見せたいということです。 、よりクリーンなコミットグラフの表示を可能にします。

私の見方では、名前、電子メール、およびコミット時間がマージコミットで自動的に同一に設定された場合 (つまり、親の最新のコミット時間に automerge@example.com によってマージされた場合)、C と C' は同一ですか？では、信頼できるアップストリーム ソースから C/C' を取得したのと同じでしょうか? このアプローチで注意すべき落とし穴や危険性はありますか? または、Git は、私が知らないいくつかの機能でこれを自動的に処理できますか?

4

1 に答える 1

2

C と C' の親の順序が逆になっています。C の最初の親は A で、2 番目の親は B です (コミット B をコミット A を持つブランチにマージします)。C 'の場合は逆です（コミットAをコミットBを持つブランチにマージしました）。

Git は、親コミットのハッシュを commit オブジェクトに保存します。表示される最初のハッシュは、現在のブランチが指しているコミットです。その後、マージするコミットのハッシュが続きます。

sha ハッシュを計算するときは、順序が重要です。sha がこの種の変更に非常に敏感であることを考えると、2 つのハッシュが等しい可能性は事実上ゼロです。他のすべてを同じに保つことができたとしても。コミットが 2 つの異なるブランチにあるという事実は、sha ハッシュを破棄するのに十分です。

実行git cat-file -p branch-aしgit cat-file -p branch-bて違いを確認します。そこに2行parent <sha1>あり、順序が逆になります。

于 2013-09-08T21:40:02.453 に答える