在我的工作环境中，首先我们计划在10月发布一个版本，因此我们创建了以下结构
大师 - ＆gt;开发 - ＆gt;特征
目前正在10月发布的功能分支中进行更改。
现在我们正在为8月发布另一个项目。所以我有以下选项
选项1： 1）不要将为10月发布创建的功能分支的更改合并到开发分支 2）分析了Develop for August发布的另一个功能分支 3）8月发布完成后，将更改合并到develop分支和October功能分支
选项2： 因为我们计划将功能分支（Oct）的变化经常合并到Develop分支，以便进行SIT部署 1）从8月的硕士分支出另一个发展分支 2）然后从这个Develop分支创建一个8月发布的功能分支 3）定期将更改合并到Develop分支。发布后，将更改合并到Master，Develop 10月分支和功能分支
选项3： 创建发布分支
大师 - ＆gt;开发 - ＆gt;发布 - ＆gt;特征
1）创建特定于发布和管理合并的发布分支
请让我知道哪种方法是正确的，并且具有最低合并要求。
〜感谢
答案 0 :(得分：2)
请告诉我哪种方法正确...
没有正确的方法，但有些方法比其他方法更好。
...并且具有最低合并要求。
矛盾的是，您希望经常分支和合并更多，但变化较少。
积累了大量变化的长期分支积累了复杂性，使得它们很难进行qa，管理和合并。版本之间的月份也累积了许多必须同时删除用户的功能。这些都使得合并，集成和发布过程变得缓慢而复杂。
然后你现在遇到了一些问题：你有一个不完整的，大型的10月发布分支。发布时间表已经进入开发过程。现在你被要求删除8月份的版本，你如何处理10月份分支中的所有代码？这是不灵活的。
相反，有一个长寿命的分支，一切都是开发的。在隔离的，短期的功能分支中单独开发功能。在合并之前对它们进行QA。这为您提供了一个长期存在的分支，始终准备好发布。
它可能看起来像这样。
I - J L - M - N [feature1]
/ \ /
A - B - C ----- F - G ----- K [master]
\ / \
D - E O - P [feature2]
这显示两个已完成的功能D - E和I - J已通过质量检查并已合并为主数据。由于QA已经在功能分支上完成，因此master将部署到生产中。有两个开放的功能分支。这些分支的开发人员会定期运行git rebase master，以便他们了解master中最新经过全面测试的代码。这通过始终将其分支保持在master的尖端并且逐步处理冲突而不是在最后的大块中来简化合并过程。
请注意，没有直接提交到master，它只会通过功能分支合并进行更改。这意味着master始终经过测试，可靠且可随时部署。正在进行的各个功能不会相互干扰，并且可以依赖稳定的主分支;如果有什么事情发生，他们知道这是因为他们的工作，而不是因为有人打破了开发部门。
现在您可以随时发布，master随时可以使用。发布计划和开发过程彼此独立。您可以按照设定的时间表从master部署，也可以在合并后立即部署。
您将作为单独的分支和QA处理10月发布的功能并合并它们。如果突然改变优先级，就像8月发布的一组功能一样，那么就像以前一样将工作转移到这些功能。当8月截止日期到来时，master已准备就绪并已部署。
如果有10月份的功能，您不希望在8月部署，请将代码保留，但使用配置开关将其关闭。
这避免了必须管理多个长寿分支，并且并行重叠更改并在它们之间进行合并。相反，您有多个短期分支，每个分支用于单个功能。如果要跟踪已部署的内容，请使用标记，而不是分支。