所以我意识到这是一个标题，所以让我澄清一下。我有一个有15个开发人员的环境，在任何给定的点上，我们中最多有5个人可能正在处理同一组代码。这是一个PHP网络应用程序，它有很多遗留/程序代码，因此我们经常编辑相同的文件，而且我们的一些更改可能非常深远。
因此，集成有点棘手，但更重要的是，有时会开发一个功能，通过多轮QA＆amp;通过营销进行审核，同时需要部署其他较小的功能。
目前，为了避免事情陷入QA /集成，integration分支是一个死胡同的分支，当一些事情真正准备就绪时，它直接从其功能分支合并进入master，并推送master以部署到实际网站。
我试图创建一个更顺畅的工作流程，其中功能合并到QA中，然后QA合并到master作为部署，但我需要解决不具备的功能问题准备好与integration上的小功能混合使用。我愿意探索一些替代方法来处理更长时间运行的功能，而不是将它们合并到integration分支中，但我自己也会碰壁。
答案 0 :(得分：1)
你需要采用“候选人”的想法。
我在这里解释了这样做的过程：http://dymitruk.com/blog/2012/02/05/branch-per-feature/
如果您对此工作流程有任何疑问，请与我们联系。
答案 1 :(得分：0)
事实是，使用N个特征，你有N +（N选2）+（N选3）+（N选4）+ ... + 1种不同的组合。
在英语中，那就是“天啊，有很多组合”。
因此，您不会为功能的每个可能子集创建集成分支：您只测试您关注的组合。如果某些事情本身没有为黄金时间做好准备，那么它就无法与其他功能同时进入黄金时段。一旦所有进入特定版本的功能成熟，您就可以创建一个集成分支，将所有这些功能组合在一起，QA然后发送它。
您可以进行“高级集成”测试，看看2,3,4个左右的功能如何相互配合，但这些分支在质量保证方面不具有“权威性”：因为您没有最后一组将要发送到那里，你不能打电话给任何你真正的QA。
因此，您没有 “集成”分支 - 每个集成分支用于一个完整批准为QA准备的东西。如果有什么东西在那里做得不好，整个分支将失败QA，所以没有任何东西会从坏分支蔓延到部署状态 - 这意味着你永远不必说“这一点是好的，那一点这很糟糕，拉下这个，在 QA过程之后留下“：这将创建一个基本上未经测试的功能组合。