我们有以下远程分支:masterstagingdevelop
每个都绑定到自己的服务器，并将在提交被推送时部署。
团队成员将在基于master并合并到develop的特性分支myfeaturea上工作。在这个场景中，这个特性被认为还没有准备好投入生产。
另一个团队成员基于master制作myfeatureb，并希望合并到develop，但不能，因为develop包含与第一个团队成员冲突的代码
我们如何确保分支是同步的，但也只有批准的功能分支才能进入生产环境，而不是任何未准备好/未批准的功能分支提交?
如果特性分支基于develop，然后被批准用于生产，那么该特性将包含来自develop的未准备好用于生产的提交。
我需要一个一致的流程和策略，以便能够合并和测试基于master的不同功能分支，因此它们独立于其他开发人员的工作，并自动准备合并到master中。但是我们也需要测试它们，所以我们也不能让它们在develop上发生冲突。
那么我们是否应该以某种方式从develop完全删除提交，当被认为没有准备好?
这听起来与软件工程网站上讨论的一个问题中的工作流非常相似，并且我对该问题的大部分回答都是相关的。
我认为你正在寻找的工作流程不存在，因为你有两个基本冲突的需求:
- 你希望功能分支是独立的，这样它们中的任何一个都可以合并到master，而不需要其他的。
- 您希望能够在单个测试服务器上测试这些功能的组合。
一旦您将两个功能分支合并到develop并在那里测试它们，就违反了要求1:您只测试了合并的分支，因此您不知道将一个分支合并到master会有什么影响。因此，一种解决方案是放弃该需求，并将develop视为真正的集成测试:
- 将一个特性合并到
develop表示您希望它包含在下一个版本中。 - 在
develop中发现的问题必须通过合并修复来修复。在最坏的情况下，你可能不得不恢复整个功能，并在以后重新应用它。 - 正常发布是通过将整个
develop合并到master，有时develop上的所有测试都通过了。 - 功能分支只有在紧急"hotfix"需要"jump the queue"时才会直接合并到
master。这些分支应该单独测试，而不是合并到develop。
另一个选择是放弃需求2，并独立测试特性分支:
- 完全废弃
develop分支。测试一个永远不会发布的代码版本是浪费时间。 - 要测试一个特性，首先使用
master上当前的所有更改更新它，然后将其部署到测试服务器。 - 如果测试通过，立即合并到
master并发布。
这些工作流有很多变化，你可以在网上找到讨论，但没有一个可以同时给你独立和组合的分支。
你选择了一条艰难的道路。这么多独立的分支机构将永远是一个负担。如果您继续使用这种方法，那么是的，您应该从开发分支中删除合并提交。
如果我理解正确的话，feature branches从master开始。为什么不从发展开始呢?一旦批准，将功能合并到开发中。然后合并发展成分期。然后将staging合并到master中。任何在开发分支上的合并，如果还没有合并到分级中，都可以被强制退出。
我想建议一个更明智的策略:
- 您只从
master和功能分支开始(放弃develop)- 当一个特性准备被合并时，它被合并到
master - 如果一个特性没有准备好被合并，它不会被合并到任何东西，并留在它的特性分支
- 当一个特性准备被合并时，它被合并到
- 如果您想要一个用于暂存的分支，作为主站的快照，请在暂存阶段开始时创建一个暂存分支