我们之前的工作流程类似于gitflow，一切都是主分支，master总是反映生产。在准备发布时，功能分支将合并为主服务器，修复不同功能之间可能存在的冲突，为发布创建标记，推送到主服务器以及它。
所以现在我们要将pull请求集成到此工作流程中，但让分支机构的开发人员仍然负责修复冲突。然后我的想法仍然是从master分支出来，然后对一个名为releaseX的新分支执行pull请求，其中所有新代码都将进入下一个版本。
问题是，当新功能与其他功能之间的releaseX存在冲突时，开发人员如何解决这些问题？在github中进行合并本身是不可接受的，将releaseX合并到功能分支中也不是（它会引入不相关的功能，这会使功能更难以进入生产）。
我们最终得到的是为合并创建一个分支，例如resolution / releaseX_my_beautiful_feature。
（目前，跟随更多类似githubflow的模型（而不是gitflow），持续部署并没有真正的发布概念，对我们来说不是最好的解决方案。）
您在使用拉取请求和发布时采用了哪些工作流程？
答案 0 :(得分：2)
正如@ckrusek所说，Atlasssian有一份关于不同工作流程的好文件。关于gitflow + pull请求工作流程，他们建议：
当然，我们仍然无法将开发中不相关的功能混合到我们的功能分支中。
基本上，拉请求工作流意味着更频繁的发布，为了处理这些，我们需要有功能标志，以便在需要时关闭生产中未经过如此测试的功能。这个模型给我们带来的是一个工作流，它结合了发布的概念和管理它们的方法。