Question

我想在新项目中使用git-flow。我已经阅读了一些文章并观看了github项目中建议的一些截屏视频。关于版本控制还有一个不明确的地方。让我们假设下面的场景，其中Cx是一个提交，提交之上或之下的数字是该时间点的分支版本。

              0.1     0.1       0.1          0.2
- develop ---- C1 ---- C2 ------ C4 ------ Merge ----
- release/0.2           \ --- C3 --- C5 ---/
                             0.2    0.2

所以，在发布后分支发布/ 0.2后，有一种灰色区域（在我看来）。提交C4不完全是0.1也不是0.2。合并释放后，显影分支将突然变为0.2 / 0.2开发，但C4不是0.2版本的一部分。就个人而言，如果我查看了一个存储库并看到了对v0.2的更新，我会假设该合并提交之前的每个提交都包含在该版本中。以下是我的期望：

             0.1    0.1    0.2    0.2    0.2
- develop --- C1 --- C2 --- C3 --- C5 --- C4

我的假设是错的吗？是不是我们不关心开发的样子，但我们只关心master（因为它是dev + release分支的结果）？我想在下一个版本中，所有这些提交都将根据需要包含在内。

P.S。什么是你用于夜间的神器版本？例如0.1快照？在正常的半衰期之后，0.1-SNAPSHOT <1。 0.1不成立。另外，根据git flow，你不知道你的下一个版本将是什么，直到你分支，所以0.2-SNAPSHOT也是'不允许'。

Answer 1

我说你有点误会。这就是它应该是这样的：

              0.1     0.1       0.2          0.2
- develop ---- C1 ---- C2 ------ C4 ------ Merge ----
- release/0.1           \ --- C3 --- C5 ---/
                             0.1    0.1

C3和C5只是用于稳定0.1版本的错误修正。一旦创建了发布分支，开发分支将包含下一个版本。 git-flow在哪里说你不知道你的下一个版本是什么？您应该知道接下来计划的版本，从而相应地调整版本，或者只是增加次要版本，只要您只执行向后兼容的更改并在引入向后不兼容的更改时立即碰撞主版本。 Noone说你不能在没有发布中间版本的情况下进行开发。

Git Flow - 当发布分支“活跃”时，开发的版本是什么？

1 个答案: