git - 在Git中以交互方式进行基础调整时，什么是 “label”

Question

当进行交互式基础调整时，Git将打开一个包含可以使用的命令的编辑器。其中三个命令与label有关。

# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# .       create a merge commit using the original merge commit's
# .       message (or the oneline, if no original merge commit was
# .       specified). Use -c <commit> to reword the commit message.

这是什么label，怎么使用呢？

Answer 1

chepner's comment是完全正确的:标签是git rebase --rebase-merges的工作方式。如果您不使用--rebase-merges，则无需进一步了解。

rebase 为一个概念

通过复制提交来对一般工作进行基础调整，就像通过git cherry-pick一样。这是因为不可能更改任何现有的提交。最后，当我们使用git rebase时，我们想要对现有的某些提交进行一些更改(取决于我们的微妙或公然)。

从技术上说，这是根本不可能的，但是如果我们看看我们(人类)如何使用Git并找到提交，那毕竟很容易。我们根本不更改提交!相反，我们将它们复制到新的和改进的提交中，然后使用新的提交而忘记(或放弃)旧的提交。

查找提交:绘制图形

我们使用Git并查找提交的方式是依赖于这样一个事实，即每个提交都记录其直接前任或父提交的哈希ID。这意味着提交形成了向后看的链:

... <-F <-G <-H   <--branch

分支名称branch保存了链中最后一次提交的实际原始哈希ID。在这种情况下，无论实际提交的哈希ID是什么，我们都使用字母H作为替代来绘制它。

提交H包含早期提交的原始哈希ID作为我们的元数据的一部分，我们将其称为G。我们说H指向G，并且branch指向H。

提交G当然指向其父F，后者又指向了更远的地方。因此，当我们使用Git时，我们从一个分支名称开始，该分支名称同时为我们和Git记住链中的最后一个提交。从那里开始，Git向后工作，通过链一次一次提交。

merge 提交只是具有至少两个父级的提交，而不是通常的提交。因此， merge 提交M看起来像这样:

...--J
      \
       M   <-- somebranch
      /
...--L

其中J和L是 merge 的两个父对象。通常(尽管不是绝对必要)，历史记录先 fork ，然后 merge :

          I--J
         /    \
...--G--H      M--N--...
         \    /
          K--L

我们可以将I-J和K-L称为分支，或者可以将M和/或N之前的所有内容(包括M和/或I-J)都视为一个分支-毕竟，必须有一些分支名称指向某个向右的提交。我们还如何首先找到commit K-L？

(如果愿意，我们可以随时添加指向任何提交的分支名称。添加分支名称意味着这些提交现在都位于其他分支上，而不是它们之前所在的分支之上。删除名称会删除该分支从包含那些提交的分支集合中分支。)

在 merge 提交中向后走是很棘手的:Git必须开始查看两个派生，这里是git log和git rev-list派生。 Git在内部使用priority queue使用A-B-C和HEAD进行此操作，尽管我们在此不做任何详细说明。

无论如何，这里的关键是因为提交存储了父哈希ID，并且所有箭头都指向后方，所以提交形成了Directed Acyclic Graph或DAG。我们(和Git)使用分支名称查找提交，该分支名称根据定义指向DAG某个部分中的最后一次提交。从那里我们有Git向后走。

简而言之

假设我们在这里采用一些现有的简单提交链，例如branch:

...--o--o--*--o--o   <-- master
            \
             A--B--C   <-- branch (HEAD)

并将它们复制到新提交中，如下所示:

                   A'-B'-C'  <-- HEAD
                  /
...--o--o--*--o--o   <-- master
            \
             A--B--C   <-- branch

这使用Git的分离式HEAD模式，其中HEAD直接指向提交。因此，名称branch仍然可以找到原始提交，而现在分离的C可以找到新副本。无需过多担心新副本中到底有什么不同，如果现在我们迫使Git将名称C'移到branch而不是HEAD上，该怎么办呢？也就是说，根据图纸，我们将执行以下操作:

                   A'-B'-C'  <-- branch (HEAD)
                  /
...--o--o--*--o--@   <-- master
            \
             A--B--C

移动了HEAD之后，我们还重新附加了git cherry-pick，以便我们可以恢复到常规的日常Git模式，而不是处于重新设置的中间。现在，当我们查找提交时，我们会找到新的副本，而不是原始的副本。新副本是新副本:它们具有不同的哈希ID。如果我们确实记得哈希ID，我们会看到...，但是我们通过从分支名称开始并向后工作来查找提交，当我们这样做时，我们已经完全放弃了原始文档，只看到了新的副本。

因此，无论如何，在没有 merge 的情况下，这就是rebase的工作方式。 Git:

列出了一些要复制的提交；

将git cherry-pick分离到副本应放置的位置；

一次复制一次提交，就像通过HEAD(通常实际上是*)一样；然后

移动分支名称并重新附加@。

(这里有很多极端的情况，例如:如果您以分离的HEAD开始会发生什么，以及 merge 冲突会发生什么。我们将忽略所有这些情况。)

关于 cherry-pick 的一些知识

以上，我说:

Without worrying too much about what exactly is different in the new copies ...

到底有什么不同？好吧，提交本身会保存所有文件的快照以及元数据:进行提交的人的姓名和电子邮件地址，日志消息等，并且对于Git的DAG而言，父哈希ID最重要)的提交。由于新副本的出现时间不同(旧的基础是@，新的基础是A)，显然父哈希ID必须更改。

假定通过将新提交的父级设置为当前提交而添加新提交有效，则更新的父级会在复制过程中自动发生，因为我们复制提交时，一次只能提交一次。也就是说，首先我们 check out commit A'，然后将A'复制到@。 B的父级自动为B'。然后，我们将B'复制到A'，并且git cherry-pick的父级自动为H。因此，这里没有真正的魔力:这只是日常的基本Git。

但是快照也可能有所不同，这才是G真正出现的地方。Cherry-pick必须将每次提交视为一组更改。要将提交视为更改，我们必须将提交的快照与提交的父级快照进行比较。

也就是说，给定:

...--G--H--...

通过首先将H提取到一个临时区域，然后将H提取到一个临时区域，然后比较这两个临时区域，我们可以看到git cherry-pick中发生了什么变化。对于相同的文件，我们什么也没说。对于不同的文件，我们会生成一个差异列表。这告诉我们A-B-C中发生了什么变化。

因此，为了让A复制提交，只需将提交变成更改即可。这需要查看提交的父级。对于*的提交，这没问题:B的父级是A； C的父级是B；且*的父级是A。 Git可以找到第一组更改-@与A'-并将更改应用到A中的快照，然后以这种方式创建B。然后，找到A' -vs- B的更改，并将这些更改应用于git rebase进行feature，依此类推。

对于普通的单亲提交，这很好用。对于 merge 提交，它根本不起作用。

复制 merge 是不可能的，因此不要尝试重新设置基准

假设我们有一组带有 merge 气泡的提交，并且这组提交本身可以重新设置基础:

           I--J
          /    \
         H      M   <-- feature (HEAD)
        / \    /
       /   K--L
      /
...--G-------N--O--P   <-- mainline

我们现在想在提交P之前在git rev-list上提交I-J。如果这样做，默认结果是:

...--G-------N--O--P   <-- mainline
                    \
                     H'-I'-J'-K'-L'  <-- feature (HEAD)

或者:

...--G-------N--O--P   <-- mainline
                    \
                     H'-K'-L'-I'-J'  <-- feature (HEAD)

(为了节省空间，我没有费心在废弃的提交中进行绘制。)

在重新定级过程的“列表提交复制”部分中，由K-L来选择M和M的顺序。只需简单地删除commit M( merge ):导致 merge commit git cherry-pick的两个分支被扁平化为一条简单的线性链。这样就避免了需要复制提交git merge的情况，但代价是有时不能很好地复制提交(具有很多 merge 冲突)，并且如果我们想保留它的话，当然会破坏我们小的 merge 气泡。

Cherry-pick无法复制 merge ...

虽然您可以在 merge 提交上运行git rebase，但是生成的提交是普通的非 merge 提交。此外，您必须告诉Git使用哪个 parent 。 Cherry-picking从根本上必须区分提交的父对象与提交的对象，但是 merge 有两个父对象，而Git根本不知道要使用两个父对象。您必须告诉它哪个...，然后它复制差异所找到的更改，而这并不是git rebase的全部内容。

...为了重新设置基础并保持 merge ，git merge重新执行 merge

这对于H的所有含义是，为了“保留” merge ，Git必须自己运行H'。

也就是说，假设我们得到了:

           I--J
          /    \
         H      M   <-- feature (HEAD)
        / \    /
       /   K--L
      /
...--G-------N--O--P   <-- mainline

我们想要实现:

                         I'-J'
                        /    \
                       H'     M'  <-- feature (HEAD)
                      / \    /
                     /   K'-L'
                    /
...--G-------N--O--P   <-- mainline

Git的rebase可以做到这一点，但是要做到这一点，它必须:

将I复制到K并在此处放置标记；

选择I'或K'中的一个复制到J或L中，然后再复制I-J或J'；假设我们选择git checkout做；

放下一个指向H'的标记；

K之前使用标记制作的L复制；

现在将K'和L'复制到git checkout和J'，并在此处放置标记

到目前为止，作为中间结果，我们有:

                         I'-J'   <-- marker2
                        /
                       H'  <-- marker1
                      / \
                     /   K'-L'   <-- marker3
                    /
...--G-------N--O--P   <-- mainline

Git现在可以使用标记2进行git merge提交L'的提交，使用标记3在提交M'上运行H'，从而产生commit J'，这是一个新的 merge ，使用L'作为 merge 基础，并使用feature和HEAD作为两个分支提示提交。

一旦 merge 完成，整个基础就可以完成，Git可以删除标记并像往常一样将分支名称git rebase --rebase-merges移开。

如果我们比较聪明，有时可以让label充当三个标记之一，但是每次仅删除标记会更直接。我不确定reset实际使用哪种技术。
merge，merge和HEAD命令创建并使用各种标记。 git merge命令要求-C指向将成为结果 merge 的第一个父项的提交(因为merge以这种方式工作)。有趣的是，该语法表明此处禁止使用 Octopus merge :它们应该可以正常工作，因此应该被允许。

(--rebase-merges命令中的--ours可以使用原始 merge 提交的原始哈希ID，因为它始终不变。如果您将-X ours与一组包含 merge 的提交一起使用，则标签将由Git从提交消息，直到最近为止这里还存在一个错误。)

旁注:邪恶 merge 和--ours merge 无法生存

当Git重新执行 merge 时，它仅使用常规 merge 引擎。 Git不知道 merge 期间使用的任何标志，也不知道作为“恶意 merge ”引入的任何更改。因此，ojit_code或ojit_code或其他更改只会在此类重新设置过程中丢失。当然，如果 merge 中存在 merge 冲突，您将有机会重新插入邪恶的 merge 更改，或者完全按自己的意愿重做 merge 。

另请参阅Evil merges in git?