问题描述
在一个持续开发的Web项目中使用了类似于Git Flow的分支策略，其中包括develop分支、master分支、feature分支和hotfix分支。用户希望简化这个策略并且去掉develop分支。用户认为develop分支只是出于历史原因而存在，并且由于它始终是一个经过测试的版本，他认为将其与master分支分开是不必要的。用户认为去掉develop分支将简化发布流程，因为不再需要额外的合并操作。
用户提出了以下约束条件：
1. 发布是有计划的，不应完全自动化。
2. 虽然feature分支通常存在时间很短，但有些feature分支可能会存在几周（例如重新设计），但仍需要进行测试（目前作为对develop分支的开放pull request）。
3. 有时需要在验收测试失败后暂停某些功能。
用户还提出了以下问题：
1. 目前我正在为测试构建pull request和为发布构建合并提交。我可以统一这两个过程吗？
2. 当master分支领先于最新发布版本时，如何处理hotfix？我应该直接从hotfix分支构建和部署发布吗？
3. 对于已经合并的功能，有没有一种合理的方法来处理它们不包含在发布中的情况？对于这些情况，单独的develop分支真的有优势吗？大多数情况下，我最终还是要手动撤销和重新撤销提交。
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1
在你的情况下，我建议你保留master分支，并使用标签来表示发布版本。这样你就去掉了一个分支，但实际上只是语法上的变化。这种改变没有带来任何积极的影响，只是为了改变而改变。
如果你真的去掉develop分支，那么代码的集成将会变慢，feature分支的存在时间会更长，特别是在接近发布日期时。这将增加每次合并的难度并减慢整个过程。
在你提出的约束条件下，我没有看到这种改变带来任何积极的影响。这将需要放宽约束条件，特别是第一个约束条件。
方案2
在我看来，你所面临的问题实际上是你最初采用的分支策略的副作用：你实际上是通过master分支将新的开发代码（即将来的生产代码）与当前的生产代码进行整合。这导致了矛盾的要求和问题，因为通常未来的代码与当前的代码不同：
– 新的开发会破坏生产环境 – 在将develop分支合并到master分支后出现回归问题。
– 稳定生产环境会减慢未来的开发 – 你需要稳定develop分支以使其足够好以合并到master分支。
去掉develop分支并不会帮助（太多）- 你并没有消除问题，只是将问题的develop特定部分转移到了master分支。
更好的方法是将生产环境放在当前/未来开发的后面，以防止与未来发布的开发干扰，如下图所示：
请注意，上图中只涉及发布分支，而不涉及主干上的内容。
对于你的情况，这个方法将如何工作：
– develop分支消失，如你所希望的，被吸收到master分支中。
– master分支是你的主干，这是开发发生的地方，没有速度限制（它永远不会与生产环境合并）。
– 生产环境是一个或多个从master标签/标记中拉出的release分支，被认为足够接近生产质量（如果需要，可以在该分支中解决一些剩余的待办事项）。这些分支只能直接接收热修复和/或从master分支中挑选的修复，它们永远不会与master分支或其他分支合并。
– 热修复直接提交到release分支。
如果一个热修复只适用于一个生产版本而不适用于master分支，它通常会先提交到master分支，然后再将其cherry-pick/double-commit到release分支。
现在看看进入master分支的内容（已经超过了当前release分支的边缘），你有两个选择：
– 继续使用feature分支，就像你现在做的那样，只是它们基于master分支而不是develop分支。将它们转换为热修复仍然是可能的-你只需要将它们rebase到相应的release分支而不是master分支。
– 切换到持续集成并获得其好处（可以逐步进行），包括逐渐减少拉取的feature分支。
如果你喜欢这个方法，以下是如何从现有情况过渡到这个方法：
– 建立一个发布命名策略：
– 你不能使用相同名称的正在进行的发布分支。
– 你不能（实际上不应该）rebase或同步生产发布分支。
– 立即从master分支拉出一个releaseX分支，遵循上述命名策略。
– 停止将提交放入develop分支，它们很快将直接放入master分支。
– 将develop分支合并到master分支。
– 告诉开发人员将他们的工作区从develop分支切换到master分支。
– 允许提交到master分支。
– 如果需要，删除develop分支（或永久锁定/只读以供参考）。
总结
在你的情况下，去掉develop分支可能会导致代码集成变慢并增加合并的难度。你可以考虑保留master分支，并使用标签来表示发布版本。另一种方法是采用更好的分支策略，将生产环境放在当前/未来开发的后面，以防止与未来发布的开发干扰。你还可以考虑使用feature flags来处理不包含在发布中的功能。请根据你的具体情况选择最适合你的解决方案。