假设我们在git中使用以下分支策略：
master分支，用于持续开发新功能。release分支以稳定。 创建release分支后，一些开发人员继续提交master（处理后续版本的功能），而其他开发人员则努力完成当前版本。在release分支存在期间，来自master的提交被而不是合并以保持发布分支的稳定性。
在发布时，release分支中的最终提交将使用发布版本进行标记。然后，从release到master执行合并（显然不是快进，因为两个分支上的并发开发）。
现在想象一下（在更多提交到master之后），我们想要将存储库重置回上一版本的状态。
不会回滚到master中标记的版本提交会导致存储库状态与我们在release分支上的状态不同吗？（除非我是缺少某些东西，情况就是这样，因为在两个分支处于活动开发期间提交到master，即使在回滚master之后仍然在提交历史中，因为它们发生在标记的发布提交之前。）
重新绑定而不是将release分支合并回master会解决这个问题，但对于处理master的多个开发人员而言，这不是一个可行的选择。
有什么想法吗？
编辑：感谢@ jthill的回答，添加图表来解释情况以及为什么我感到困惑。
这是实际发生的事情的图表：
...o---X---o---o---o---M master
\ /
a---b---c---R release
^
(v1.0, final commit in release branch)
现在，这是一个线性提交历史记录从master看起来是什么样的图表（正在推动我错误的心理模型） - 请注意o引用和a / b / c refs根据其提交时间戳混合。这就是让我失望的原因 - 平坦的提交历史记录并未明确表示如果您回滚到引用R，o之后的所有X提交也将被删除！
...o---X---o---a---b---o---c---o---R---M master
^
(v1.0, final commit in release branch)
答案 0 :(得分：1)
从您的文字说明中
- 发布分支中的最终提交已标记为
- 然后，从发布到主
执行合并
我从中得到这张照片：
...o---X---o---o---o...M master
\ /
o---o---o...R release
^
(v1.0, final commit in release branch)
你在这里只命名了三个参考，这张照片中显示了参考。注意
不会回滚到主要
中的标记版本提交
与你描述的tag-then-merge序列不一致，但是v1.0是指[{1}}还是R，你提到的唯一引用是{{1}是M。
回答你的问题：
不会回滚到master中的标记版本提交结果，而不是我们在发布分支上的存储库状态吗？
M会将这三个裁词准确地留在那张照片中，所以，不。
现在：假设我以某种方式误解了你。想想：无论我的误解是什么，为了纠正我，你必须告诉我哪些提交是哪些提交 - 所以如果你现在把它们放回去，你就会有你的愿望。