1

在某些情况下，我正在开发一个需要与多个协作者实时进行版本管理和冲突解决的分布式程序，并且我正在考虑使用 Git（特别是https://github.com/creationix/js- git ) 在引擎盖下。每个用户都有自己的 ref，但会有一个全局历史记录（很像 GitHub 所做的）。但与 GitHub 不同的是，所有用户的分叉应该是平等的，并且拉取请求不是单向进入上游分叉的。

我正在考虑这样一种情况，其中两个用户刚刚进行了自己的离线更改[提交如下所示的 A 和 B]，他们选择同时从他们的合作者的开发分支中提取。假设合并是使用相同版本的 Git 完成的，并且没有发现任何远程类似的冲突，这两个合并最终会得到相同的树，但是（据我所知）因为执行合并提交的用户有不同名称，合并提交 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，第二个父级是 B（您将提交 B 合并到具有提交 A 的分支中）。对于 C' 则相反（您将提交 A 合并到具有提交 B 的分支中）。

Git 将父提交的哈希值保存在提交对象中。出现的第一个哈希是您当前所在的分支指向的提交。之后是您要合并的提交的哈希值。

计算 sha 哈希时，顺序很重要。鉴于 sha 对此类更改非常敏感，因此两个哈希值相等的机会几乎为零。即使您设法使其他一切保持不变。提交在两个不同的分支上的事实足以摆脱 sha 哈希。

运行git cat-file -p branch-a并git cat-file -p branch-b查看差异。那里将有两行，parent <sha1>并且顺序相反。

于 2013-09-08T21:40:02.453 回答