什么是Git提交ID? [英] What is a Git commit ID?

查看:369
本文介绍了什么是Git提交ID?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

如何生成Git提交ID来唯一标识提交?

How are the Git commit IDs generated to uniquely identify the commits?

示例:521747298a3790fde1710f3aa2d03b55020575aa

它如何工作?它们仅对每个项目都是唯一的吗?还是针对全球的Git存储库?

How does it work? Are they only unique for each project? Or for the Git repositories globally?

推荐答案

Git提交ID是 有关提交的每个重要事项的SHA-1哈希 .我不会全部列出,但是这里是重要的...

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...

  • 所有内容,不仅仅是差异.
  • 提交日期.
  • 提交人的姓名和电子邮件地址.
  • 日志消息.
  • 先前提交的ID.

更改其中任何一个,然后提交ID也会更改.是的,具有相同属性的同一提交将在另一台计算机上具有相同的ID.这有三个目的.首先,这意味着系统可以确定提交是否已被篡改.它已经融入到体系结构中了.

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.

第二,仅通过查看ID即可快速比较提交.这使得Git的网络协议非常有效.是否想比较两个提交是否相同?不必发送整个差异文件,只需发送ID.

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.

第三,这是个天才,两个具有相同ID的提交具有相同的历史记录.这就是为什么先前提交的ID是哈希的一部分的原因.如果提交的内容相同但父项不同,则提交ID必须不同.这意味着当比较存储库(例如以推或拉方式)时,一旦Git找到两个存储库之间的共同提交,它就可以停止检查.这使得推拉极为有效.例如...

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]

git fetch origin的网络对话是这样的...

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

  • local嘿,起源,您有哪些分支机构?
  • origin我在E拥有硕士学位.
  • local我没有E,我在B有您的硕士.
  • origin B你说?我有B,是E的祖先.让我给您发送C,D和E.
  • 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.

这也是为什么当您使用rebase重写提交时,其后的所有内容都必须更改的原因.这是一个例子.

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]

假设您重写D,只是稍微更改了日志消息.现在D不再是D,必须将其复制到我们称为D1的新提交中.

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

虽然D1可以将C作为其父级(C不受影响,提交不知道其子级),但它与E,F和G断开连接.如果我们将E的父级更改为D1,则E不再是E.必须将其复制到新的提交E1.

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

以此类推,从F到F1,从G到G1.

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

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

它们都具有相同的代码,只是父母不同(或者在D1的情况下,具有不同的提交消息).

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

这篇关于什么是Git提交ID?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆