git - GIT PUSH 到底做了什么？

Question

我似乎无法找到一个很好的解释。

我知道 git pull 做了什么:

1) fetch ，即来自服务器的所有额外提交都被复制到本地存储库中，并且 origin/master 分支指针移动到提交链的末尾

2) a 将origin/master 分支的 merge 到master 分支，master 分支指针移动到新创建的commit，而origin/master 指针保持不动。

我假设 git push 做了一些非常相似的事情，但我不确定。我相信它会执行其中之一，或类似的事情，或其他(？):

复制所有本地提交并在那里进行 merge (与 git pull 所做的相反)；但在这种情况下，服务器没有我本地的主分支，所以我看不到它 merge 的是什么

要么

将我的 master 分支 merge 到 origin/master 中，将结果提交推送到服务器并将其链接到现有的最终提交旁边，同时移动服务器的 master；这似乎不对，因为那时我的本地来源/主服务器与服务器的不同步。

我目前正在使用 git 进行基本操作，所以我做得很好，但我想完全了解这些内部结构。

Answer 1

假设您已经了解 git 的“对象”模型(您的提交和文件等都只是“git 数据库中的对象”，“松散”对象——那些没有打包以节省空间的对象——存储在 .git/objects/12/34567... 等中)。 ..

你是对的: git fetch 检索对象“他们”( origin ，在这种情况下)你没有，并在他们身上贴上标签: origin/master 等。更具体地说，您的 git 在互联网电话(或任何其他合适的传输)上调用他们的并询问:您有哪些分支，以及那些提交 ID 是什么？他们有 master 并且 ID 是 1234567... ，所以你的 git 要求 1234567... 和你还没有的任何其他需要的对象，并使你的 0x25184 对象 141313 指向 0x2518122231413131333

这里对称的 origin/master 部分是这样的:你的 git 像往常一样在同一个互联网电话上调用他们的 git，但这一次，不是仅仅询问他们的分支，你的 git 告诉他们你的分支和你的 git 存储库对象，然后说:“我让你将 1234567... 设置为 git push 怎么样？”

他们的 git 会查看您发送的对象(新提交 master 以及您拥有但他们没有的任何其他对象，他们需要接受它)。然后他们的 git 考虑将他们的 56789ab... 设置为 56789ab... 的请求。

作为 Chris K already answered ，这里没有发生 merge :您的 git 只是建议他们的 git 用这个新的提交 ID 覆盖他们的 master。由他们的 git 决定是否允许这样做。

如果“他们”(无论他们是谁)没有设置任何特殊规则，那么 git 在这里使用的默认规则非常简单:如果更改是“快进”，则允许覆盖。它还有一个附加功能:如果更改是在设置了“force”标志的情况下完成的，则也允许覆盖。在这里设置强制标志通常不是一个好主意，因为默认规则“仅快进”通常是正确的规则。

这里显而易见的问题是:究竟什么是快进？我们稍后会讲到。首先，我需要对标签或“引用”进行一些扩展以使其更加正式。

Git的引用

在 git 中，一个分支或一个标签，甚至像 stash 和 56789ab... 之类的东西都是引用。它们中的大多数位于 master 中，这是 git 存储库的子目录。 (一些顶级引用，包括 HEAD ，就在 .git/refs/ 本身中。)所有引用都是包含像 HEAD 这样的 SHA-1 ID 的文件 1。 SHA-1 ID 很麻烦，人们无法记住，因此我们使用名称，例如 .git(在这种情况下是一个标签，git 本身的 2.1.0 版)来为我们保存它们。

一些引用是——或者至少是打算——完全静态的。标签 7452b4b5786778d5d87f5c90a94fab8936502e20 不应引用上述 SHA-1 ID 以外的内容。但有些引用资料更具动态性。具体来说，您自己的本地分支，例如 v2.1.0 ，是移动目标。一种特殊情况 v2.1.0 甚至不是它自己的目标:它通常包含移动目标分支的名称。因此，“间接”引用有一个异常(exception): master 通常包含字符串 HEAD 或 HEAD ，或类似的内容；并且 git 不会(也不能)对引用强制执行“永不更改”规则。特别是分支机构变化很大。

你怎么知道一个引用是否应该改变？嗯，很多这只是按照惯例:分支移动而标签不移动。但是你应该问:你怎么知道一个引用是一个分支，一个标签，还是什么？

引用的命名空间: ref: refs/heads/master 、 ref: refs/heads/branch 等。

除了特殊的顶级引用之外，所有 git 的引用都在 refs/heads/ 中，正如我们上面已经提到的。但是，在 refs/tags/ 目录(或“文件夹”，如果您使用的是 Windows 或 Mac)中，我们可以拥有一整套子目录。在这一点上，Git 有四个明确定义的子目录:refs/ 包含您所有的分支，refs/ 包含您所有的标签，refs/heads/ 包含您所有的“远程跟踪分支”，以及 refs/tags/他们变得有点复杂)。

由于您的所有分支都在 refs/remotes/ 中，因此 git 可以判断应该允许更改这些分支，并且由于您的所有标签都在 refs/notes/ 中，因此 git 可以判断出这些不应该更改。

Twig 的自动运动

当你进行新的提交，并且在像 refs/heads/ 这样的分支上时，git 会自动移动引用。您的新提交创建时其“父提交”是前一个分支提示，一旦您的新提交安全保存，git 将更改 refs/tags/ 以包含新提交的 ID。换句话说，它确保分支名称，即 master 子目录中的引用，始终指向最尖端的提交。

(实际上，从作为存储在存储库中的提交图的一部分的提交集合的意义上讲，分支是由存储库中的提交构成的数据结构。它与分支名称的唯一联系是分支本身的提示提交存储在具有该名称的引用标签中。这在以后很重要，如果以及何时随着存储库增加更多提交而更改或删除分支名称。现在只需要记住:有“分支提示”(即“分支名称”指向的地方)和分支作为提交的子集的子集之间的差异。有点不幸的是，git 倾向于将这些不同的概念混为一谈名称，“分支”。)

究竟什么是快进？

通常您会在 merge 的上下文中看到“快进”，通常将 merge 作为 master 中的第二步完成。但实际上，“快进”实际上是标签移动的一个属性。

让我们画一点提交图。 heads 小节点代表提交，每个节点都有一个箭头指向其父节点(或父节点)的左、左上或左下(或在一种情况下，两个箭头)。为了能够通过名称引用三个，我会给它们大写字母名称而不是 git pull 。此外，这个基于角色的艺术作品没有箭头，所以你必须想象它们；请记住，它们都指向 left 或 left-ish，就像三个名字一样。

            o - A   <-- name1
          /
o - o - o - o - B   <-- name2
      \       /
        o - C       <-- name3

当您要求 git 更改引用时，您只需要求它在标签中粘贴一个新的提交 ID。在这种情况下，这些标签位于 o 中，因此是分支名称，因此它们应该能够采用新值。

如果我们告诉 git 将 o 放入 refs/heads/ ，我们会得到:

            o - A
          /
o - o - o - o - B   <-- name1, name2
      \       /
        o - C       <-- name3

请注意，提交 B 现在没有名称，只有通过查找 name1 才能找到它左侧的 A ... 这很难，因为 0x251812231343.141 没有名称Commit o 已被废弃，这两个提交已成为“垃圾收集”的资格。 (在 git 中，在“reflog”中留下了一个“ghost name”，它使带有 A 的分支保持大约 30 天。但这完全是一个不同的主题。)

告诉 git 将 A 放入 A 怎么样？如果我们接下来这样做，我们会得到:

            o - A
          /
o - o - o - o - B   <-- name1, name2, name3
      \       /
        o - C

在这里，提交 A 仍然有办法找到它:从 B 开始，向下和向左工作，到它的另一个(第二个)父提交，你会找到提交 name3 。所以提交 C 没有被放弃。

像这样更新 B 不是快进，但更新 C 是。

更具体地说，当且仅当对象(通常是提交)用于指向的引用仍然可以通过从新位置开始并沿所有可能的向后路径向后工作时，引用更改是“快进” .在图形方面，如果旧节点是新节点的祖先，则它是快进的。

通过 merge 使 C 成为快进

当您唯一要做的就是添加新提交时，会发生分支名称快进；而且，如果您添加了新的提交，那么您还 merge 了其他人添加的任何新提交。也就是说，假设你的仓库中有这个，在你做了一个新的提交之后:

             o   <-- master
           /
...- o - o       <-- origin/master

此时，“向上和向右”移动 name1 将是一个快进。但是，其他人出现并更新了另一个( name3 )repo，因此您执行 push 并从他们那里获得新的提交。你的 git 移动你的 origin/master 标签(在你的 repo 的快进操作中，因为它发生):

             o   <-- master
           /
...- o - o - o   <-- origin/master

在这一点上，将 origin 移动到 git fetch 不会是一个快进，因为它会放弃一个新的提交。

但是，您可以执行 origin/master 操作以在您的 origin/master 上进行新提交，并使用两个父提交 ID。让我们将这个标记为 master(用于 merge ):

             o - M  <-- master
           /   /
...- o - o - o   <-- origin/master

您现在可以将 git merge origin/master 返回到 master 并要求他们设置他们的 M — 您正在调用 git push — 等于您的(新的)a251813131313252513131343 的(新的)操作!

请注意，您也可以执行 origin ，但让我们将其留给不同的 stackoverflow 发布。 :-)

1事实上，git引用总是从各个子目录中的单个文件开始，但是如果一个引用很长一段时间没有更新，它往往会被“打包”(以及所有其他大部分静态引用)到一个充满压缩引用的单个文件。这只是节省时间的优化，这里的关键不依赖于确切的实现，而是使用 git 的 master 和 origin/master 命令从引用中提取当前的 SHA-1，或者更新引用以包含新的SHA-1。