合并拉取请求后git标记会发生什么

Question

如果您有这样的git提交树，会发生什么：

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

并且您接受一个pull请求，该请求的更改早于之前标记的提交;标签现在是否包含合并拉取请求的提交？

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

Answer 1

在git中，标记指向特定的提交对象。如果您确实已完成git pull --rebase，那么您的图表如下所示：

A-B-C-D

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

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

因此，您的问题的答案是，v0.9标记始终指向首次创建标记时的D版本。因此，如果您重写了历史记录，那么您将拥有一个标记，该标记指向当前分支的树中不再存在的提交。

但是，如果你只是意味着有人已经提交并推送到FBG和C分支，那么在推动BC和D之前，那么会发生什么将取决于当你做所需的拉动时你是进行合并还是变硬使用现有历史记录更新本地分支。

默认是合并。这会使您的图形看起来像这样：

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

你的分支头指向M并且树的每个分支中的B和C将是不同的（即使你们从其他地方挑选了相同的提交）。

<强>更新

TL; DR：

• 谁先提交（时间）并不重要：顺序取决于图表和你选择组合和/或改变图表（merge，rebase，cherry-pick）。你决定最终的结构是什么样的。
• 提交对象（标记指向的东西）永远不会更改，因此您的标记提交将不会更新
• 由于提交不会更改，因此在重写历史记录时，即使差异相同，您实际上也有新提交对象。它看起来似乎正在发生变化，但实际上它们在图表中被替换为看起来非常相似的东西。