Question

Git使用SHA1哈希来标识提交对象，并根据Git Book提交对象包含：

一棵树
指向旧提交（父级）的指针
时间戳
作者姓名
提交者名称
...

让我感到惊讶的是，在提交对象中需要 author 和 commiter ，实际上，当将提交合并到另一个相同的存储库时，它很快就会出现问题，因为提交哈希会改变！

我的观点由GitHub说明，在您的 Fork Queue 中，一旦您的更改与原始项目合并，您甚至可以找到自己的提交！它通常是“metaconflict”，因为发起更改的人是相同的，谁提交不应该更改提交的性质 ...

那么，为什么需要呢？是滥用作者和提交者吗？我理解两者的需要，我没有 为什么都应该包含在提交哈希中，为什么不在其他地方？< / p>

是否可以不同意在不同的repos中提交的相同更改应该被标识为相同，因此从哈希中排除提交者的名称？

Answer 1

即使作者以外的其他人提交到树，提交者字段也允许您保留作者身份。这在“拉”开发模型中至关重要，在这种模型中，维护人员可能会从可能不允许直接推送到存储库的各个开发人员那里获取更改。在没有这些字段的版本控制系统中，作者似乎是有权推动更改的任何人。

由于作者可能已经在一个分支中进行了更改，但两者都有助于确定实际上对某个分支进行了更改的人员，但后来又将其更改为另一个分支。

Answer 2

这是因为有时候作者不是该项目的成员;例如，他们提交了一个补丁，或者分叉了自己的git repo。当项目成员签署变更并提交时，它将保留作者的归属以及有关谁承诺并批准变更的信息。

Answer 3

提到的身份证明是关键。

当你意识到Git能够强烈签署提交时，这一切都将开始变得更有意义;这样，没有人能够创造历史，甚至没有负责人的名字：）

发表评论 ： Git也是关于信任，来源的可验证性。简而言之：提交者负责提交并签名（字面意思）;作者是首先提交补丁的人 - 这可能是某人'在外面'，某人'不信任'。（如果您无法理解这一点，请考虑Linux内核项目，重新安全漏洞或后门：Linux用户确实需要验证他们使用的内核是否受到可信社区成员的审核！

其他信息：“真实”问题

在我用作示例的情况下，我是提交的作者，它是由主项目的所有者提交的，当我查看我的fork队列时，我看到我自己的提交（同一作者）要求（再次）到我的叉子？没有办法告诉它是一回事！

啊有真正的问题！所以你不担心为什么提交校验和包括评论和其他元数据。您也不必担心为什么有提交者和作者字段[1]

除非是ff（快进）合并，否则合并提交具有不同的提交ID会让您感到恼火。现在有一个很好的问题！ 以下是答案：

提交ID也取决于父提交，因此提交ID只能在

时相同

父ID是相同的
提交的树'快照'是相同的

发生这种情况的唯一情况是使用forks（引用相同的提交）和快进合并（导致...相同的引用）[2]。

所以只要你合并，cherry-pick或rebase（三个类似的操作，在这个上下文中）甚至一个提交到另一个分支（在不同的父提交下读取），它根据定义，将具有不同的提交ID，无论校验和是什么元数据。这是因为树历史记录不同，这是此时唯一相关的元数据。

真正的问题是：您如何避免看到重复的提交？

更喜欢合并樱桃挑选/ rebase
- 合并时，生成的提交将有两个父提交;这使得git能够进行合并跟踪并自动消除重叠提交（即已经合并的提交）。 git diff，git merge-base，git log rev1 ^rev2，git show-branch都尊重此逻辑）。这就是为什么重复合并（纵横交错，鸽子尾巴等）在git上“神奇地”工作的原因。 [3]
  - SKEPTICS ：如果你向上游发送拉取请求，他们可能不会合并你的分支，这使得这个建议很难实现。然而，没有什么能阻止你
    - 在接受你的工作后合并他们的分支（同样的最终结果，更多的工作）
    - 在他们接受你的工作后（相同的最终结果），将你自己的分支机构改掉他们的分支机构。

使用例如git log --left-right --graph --oneline --cherry-pick BRANCH1...BRANCH2检查发生樱桃挑选或重组的分支之间的差异。从联机帮助页中，这完全符合您的要求：

  --cherry-pick
       Omit any commit that introduces the same change as another commit on the "other side" when the set of commits are limited with symmetric
       difference.

       For example, if you have two branches, A and B, a usual way to list all commits on only one side of them is with --left-right, like the example
       above in the description of that option. It however shows the commits that were cherry-picked from the other branch (for example, "3rd on b" may
       be cherry-picked from branch A). With this option, such pairs of commits are excluded from the output.

最后，如果您的情况经常与经常性冲突合并（例如在使用非中心主题分支时），请参阅“git rerere --help”，这对我来说超出了这个答案的范围。

[1]你甚至不担心commit notes，这是带外的，没有修改或校验和 ... sic

[2]在techno babble中：提交历史形成加密强大的merkle树。当提示提交（HEAD）的sha1总和匹配时，它在数学上遵循（a）树内容（b）分支历史（包括所有签名和提交者/作者凭证）是相同的。这是git和其他SCM的一个巨大的安全功能。

[3]另见git log --merges --boundaries --decorate和版本规格，例如rev1 ... rev2（注意三点;见man git-rev-parse）

Git比较提交的标准，为什么包括提交者？

3 个答案:

其他信息：“真实”问题