git - merge pull 请求后 git 标签会发生什么

Question

如果你有一个像这样的 git 提交树会发生什么:

A-B-C-D          D <-- v0.9 (tag)

并且您接受了一个 pull 请求，该请求的更改早于先前标记的提交；标签现在会包含来自 merge pull 请求的提交吗？

A-F-B-G-C-D      D <-- ? v0.9 (tag)

Answer 1

在git中，tag指向具体的commit对象。如果您实际上已经执行了 git pull --rebase，那么您的图表将如下所示:

A-B-C-D

A-F-B'-G-C'-D'

实际的提交对象取决于树的状态和出身，因此即使从 C 到 D 的差异与 C' 和 D' 之间的差异完全相同，它们也是不同的提交对象。

所以你的问题的答案是 v0.9 标签在第一次创建标签时总是指向 D 的版本。因此，如果您重写了历史记录，您将拥有一个标记，该标记指向一个已不在当前分支的树中的提交。

但是，如果您的意思是有人在您推送 B C 和 D 之前提交并推送到分支 F B G 和 C，那么会发生什么将取决于您在执行所需的 pull 操作时是进行 merge 还是 rebase 使用现有历史记录更新您的本地分支。

默认是 merge 。这将使您的图形看起来像这样:

A-F-B-G-C
 \       \
  B-C-D---M

你的分支头将指向 M，而树的每个分支中的 B 和 C 将是不同的(即使你们都从其他地方挑选了相同的提交)。

更新

tl;博士:

• 谁先提交(时间)并不重要:顺序取决于图表和您组合和/或更改图表的选项( merge 、 rebase 、挑选)。您决定最终结构的样子。
• 提交对象(标签指向的东西)永远不会改变，所以你标记的提交不会更新
• 由于提交不会改变，当重写历史时，您实际上拥有新 提交对象，即使差异相同。看起来事情正在发生变化，但实际上它们在图表中被看起来非常相似的东西所取代。