我怎样才能找到阻止快速前进合并的因素

Question

我们在这里做的是Git Flow，但是现在我们需要在Git Flow启动之前创建一个热修复分支。在创建release和develop分支之前，我们有一个v906b03标签。我们也有v914和v915标签从Git Flow启动后。

方法如下:

$ git checkout master
$ git reset --hard v906b03 #make sure that master "passed by" v906b03
$ git branch v906b03-hotfix
$ git merge v914 #this merge should be a fast-forward
$ git merge v915 #this merge should be a fast-forward

现在，我得到的是递归归并与v914的归并。我试图找到什么v906b03提交不能从v914没有运气。我试过git log --oneline --not v914 v906b03，但它是空的。我也试过git log --oneline v914..v906b03，应该是一样的，也是空的。

怎么回事?

Answer 1

合并标签的默认行为是使用--no-ff作为合并选项

在Git 2.17 (Q2 2018)中不再是这样了

参见juno C Hamano (gitster)的commit adcc94a (14 Feb 2018)。

(由juno C Hamano - gitster合并)

merge:在合并跟踪标签

时允许快进

很久以前在fab47d0("合并:强制编辑和关闭模式时(2011-11-07, Git v1.7.9-rc0)，"git merge"是为了在合并标签时总是创建一个合并提交，即使是在侧分支时被合并的分支是当前分支的后代。

这个默认值对于上游维护者所做的合并是很好的集成由下游贡献者签名的工作，但将离开当下游贡献者拉一个更新时，无意义的no-ff合并Release标记，使它们的长时间运行的主题分支能够跟上上游。
当主题上没有本地工作时，这样的合并应该简单地快进到发布标记所指向的提交。

再次更新合并标签对象的"git merge"的默认值

• (1) --no-ff(即创建合并提交，即使是侧分支如果被合并的标签不在预期的位置refs/tags/层次结构和
• (2) --ff(即允许在可能的情况下快速更新)，否则

Answer 2

我在http://git.661346.n2.nabble.com/git-merge-lt-tag-gt-behavior-td7580058.html上找到了一个参考，说明合并标记的默认行为是使用--no-ff作为合并选项。我甚至尝试使用--ff没有成功，但使用提交散列甚至git show-ref <tag>都可以做到。

Answer 3

如果从v906b03合并到v914和v915只是快速前进，那么您可以立即在v915上创建v906b03-hotfix，而根本不合并。

还有你为什么要把母版移到v906b03?(重置——硬)