0

假设我们在 git 中使用以下分支策略：

  • 不断开发新功能的master分支。
  • release在即将发布的版本之前的某个时间点创建以稳定的分支。

创建release分支后，一些开发人员继续致力于master（为以后的版本开发功能），而其他开发人员则致力于完成当前版本。在分支存在期间，不会合并来自的release提交以保持发布分支的稳定性。master

在发布时，release分支中的最终提交被标记为发布版本。release然后，从into执行合并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（这导致了我错误的心理模型）——请注意，orefs 和// arefs基于它们的提交时间戳混合在一起。这就是让我失望的地方——平坦的提交历史并没有清楚地表明，如果你回滚到 ref ，随后的所有提交也将被删除！bcRoX

...o---X---o---a---b---o---c---o---R---M  master
                                   ^
                                 (v1.0, final commit in release branch)
4

1 回答 1

1

从您的文字描述中，

  • 发布分支中的最终提交被标记
  • 然后，从 release 到 master 执行合并

我从中得到这张照片：

 ...o---X---o---o---o...M  master
         \             /
          o---o---o...R    release
                      ^
                    (v1.0, final commit in release branch)

您在这里只命名了三个 refs，即这张图片中显示的那些。请注意

不会回滚到master 中的标记发布提交

与您描述的 tag-then-merge 序列不相符，但无论v1.0是指Ror M，您提到的唯一 ref 更改 sinceM是master.

要回答您的问题：

回滚到 master 中标记的发布提交不会导致与我们在发布分支上的不同的存储库状态吗？

git checkout -B master M将把这三个裁判留在那张照片中的确切位置，所以，不。

现在：假设我以某种方式误解了你。想一想：不管我有什么误解，要纠正我，你必须告诉我哪些 refs 是关于哪些提交的——所以如果你现在把它们放回去，你就会有你的愿望。

于 2013-11-08T03:39:02.190 回答