在我们公司,我们正从SVN转到Git(是的,迟到总比不迟到好)。因此,我们还尝试简化版本控制过程。为此,我发现了一篇有趣的文章:VincentDriessen的成功Git分支模型。
从本文中我可以看出,developer假设线性版本。要说清楚:
v1.0.0 --> v1.0.1 --> v1.0.2 --> v1.1.0 --> v1.1.1 etc
未提及对旧版本的支持。例如:我们最多支持三个主要版本,因为有些客户端不想升级。假设我们有以下版本:
v7.0.0 --> v8.0.0 --> v9.0.0 --> v10.0.0
当
v8.0.0
发布后在v9.0.0
中发现一个严重的bug时,我们签出tagv8.0.0
,修复bug,并将其合并回develop
和master
分支。合并到master
获取标记v8.0.1
。在我看来有点奇怪,因为有两件事:
master
时间线看起来像v7.0.0 --> v8.0.0 --> v9.0.0 --> v8.0.1 --> v10.0.0
。我完全知道这是可能的,但这也可以接受吗?当我从
hotfix
合并到master
(此时master
位于v9.0.0
)并用v8.0.1
标记它时,我是否也得到了v8.0.0
和v9.0.0
之间引入的特性?提前谢谢!
最佳答案
对我来说,标记v8.0.1
应该是合并master
之前的提交。如果你想修补新版本,那么你也可以合并其他标签。
v8.0.0 --> v9.0.0 --> v10.0.0
\ \ \
v8.0.1 --> v9.0.1 --> v10.0.1/master