git流确保了以下方式,即对master和release的更改最终在development中结束:
热修复程序从master分支并合并回development。如果有 它在那里合并并只传播到开发的活动发布分支 一旦发布被合并到主控和开发中。
对发布的更改只有在发布 完成
我想知道为什么在发布完成之前会有延迟。 简单地将master合并到release并在发生对master的更改时进行开发,以及在release发生更改时进行release开发,难道不是容易得多吗?
这样我就可以在所有相关分支中立即得到反映,并且不需要考虑在何时何地合并。
我能想到的唯一解释是,git流认为合并频率较低的好处大于跨分支拥有最新/同步的代码基的好处。
问题是 develop 用于:集成分支,用于一起测试功能。 积极的 master (以及它的修补程序)会破坏集成。
develop
master
所以我更喜欢用 吉特沃斯 (那个 I present here ):您可以对任何 feature 顶部分支 主人 (可以随时合并修补程序的位置)。 通过重新调整您的 特征 Branch,您正在最新的 主人 (以及它的修补程序)。
feature
主人
特征
稍后,您可以合并任何 特征 你需要的分支” next “ 发展 分支机构)
next
发展
最后,当您知道您实际上为下一个版本选择了哪个特性分支时,您将(再次)合并 特征 分支到 主人 .
