Git - 什么是git commit ID？ [英] Git - What is a git commit ID?

问题描述

如何生成唯一标识提交的git commit IDs？

示例：
521747298a3790fde1710f3aa2d03b55020575aa

它是如何工作的？它们对于每个项目都是唯一的吗？或git仓库全局？

解决方案

Git提交ID是关于提交的每个重要内容的SHA-1散列。我不打算把它们全部列出，但是这里是重要的...

• 内容，所有这些，不仅仅是
  
• 提交日期


• 提交者姓名和电子邮件地址。


• 日志消息。
>

• 前一个提交的ID。

更改任何提交ID和提交ID更改。是的，具有相同属性的相同提交将在不同的机器上具有相同的ID。这有三个目的。首先，这意味着系统可以判断提交是否被篡改。第二，通过查看ID可以快速比较提交。这使得Git的网络协议非常高效。想要比较两个提交以查看它们是否相同？不必发送完整差异，只需发送ID。

第三，这是天才，两个具有相同ID的提交具有相同的ID历史。这就是为什么以前提交的ID是散列的一部分。如果提交的内容相同但父母不同，则提交ID必须不同。这意味着比较存储库（如推或拉），一旦Git发现两个存储库之间共同的提交，它可以停止检查。这使推拉非常有效。例如...

  origin 
 A  -  B  -  C  -  D  -  E [master] 
 
 A  -  B [origin / master] 
  

git fetch origin 就像这样...

• local 你有什么分支？


• origin 我有E的主人。


• 本地我没有E，我有你的主人在B。


• 来源 B你说？我有B，它是E的祖先。让我寄给你C，D和E。
  

这也是为什么当你用rebase重写一个commit时，更改。这是一个例子。

  A  -  B  -  C  -  D  -  E  -  F  -  G [master] 
  

假设您重写D，只是稍微改变日志消息。现在D不能再是D了，它必须被复制到一个新的提交中，我们称D1。

  A  -  B -  C  -  D  -  E  -  F  -  G [master] 
 \ 
 D1 
  



虽然D1可以将C作为其父（C不受影响，提交不知道他们的孩子），但它与E，F和G断开连接。如果我们将E的父亲更改为D1，则E不能再是E了。它必须复制到一个新的提交E1中。

  A  -  B  -  C  -  D  -  E  -  F  -  G [master ] 
 \ 
 D1  -  E1 
  

用F到F1等等G到G1。



  A  -  B  -  C  -  D  -  E  -  F  -  G 
 \ 
 D1  -  E1  -  F1  -  G1 [master] 
  

它们都有相同的代码，父母（或在D1的情况下，不同的提交信息）。


How are git commit IDs generated to uniquely identify commits?

Example: 521747298a3790fde1710f3aa2d03b55020575aa

How does it work? Are they only unique for each project? or for git repositories globally?

解决方案

A Git commit ID is a SHA-1 hash of every important thing about the commit. I'm not going to list them all, but here's the important ones...

• The content, all of it, not just the diff.
• Commit date.
• Committer's name and email address.
• Log message.
• The ID of the previous commit(s).

Change any of that and the commit ID changes. And yes, the same commit with the same properties will have the same ID on a different machine. This serves three purposes. First, it means the system can tell if a commit has been tampered with. It's baked right into the architecture.

Second, one can rapidly compare commits just by looking at their IDs. This makes Git's network protocols very efficient. Want to compare two commits to see if they're the same? Don't have to send the whole diff, just send the IDs.

Third, and this is the genius, two commits with the same IDs have the same history. That's why the ID of the previous commits are part of the hash. If the content of a commit is the same but the parents are different, the commit ID must be different. That means when comparing repositories (like in a push or pull) once Git finds a commit in common between the two repositories it can stop checking. This makes pushing and pulling extremely efficient. For example...

origin
A - B - C - D - E [master]

A - B [origin/master]

The network conversation for git fetch origin goes something like this...

• local Hey origin, what branches do you have?
• origin I have master at E.
• local I don't have E, I have your master at B.
• origin B you say? I have B and it's an ancestor of E. That checks out. Let me send you C, D and E.

This is also why when you rewrite a commit with rebase, everything after it has to change. Here's an example.

A - B - C - D - E - F - G [master]

Let's say you rewrite D, just to change the log message a bit. Now D can no longer be D, it has to be copied to a new commit we'll call D1.

A - B - C - D - E - F - G [master]
         \
          D1

While D1 can have C as its parent (C is unaffected, commits do not know their children) it is disconnected from E, F and G. If we change E's parent to D1, E can't be E anymore. It has to be copied to a new commit E1.

A - B - C - D - E - F - G [master]
         \
          D1 - E1

And so on with F to F1 and G to G1.

A - B - C - D - E - F - G
         \
          D1 - E1 - F1 - G1 [master]

They all have the same code, just different parents (or in D1's case, a different commit message).

这篇关于Git - 什么是git commit ID？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！