git - 在 gitflow 工作流中处理 pull 请求的工作流(不经常发布)？

Question

我们之前的工作流程类似于 gitflow，一切都从 master 分支出来，master 总是反射(reflect)生产。准备发布时，功能分支将 merge 到主分支中，修复不同功能之间可能存在的冲突，为发布创建标签，推送到主分支，仅此而已。

所以现在我们想将 pull 请求集成到这个工作流程中，但让分支的开发人员继续负责解决冲突。当时的想法是仍然从 master 分支出来，然后向一个名为 releaseX 的新分支发出 pull 请求，所有将进入下一个版本的新代码都在这里。

问题是，当新功能和其他功能之间的 releaseX 发生冲突时，开发人员如何解决这些问题？在 github 本身进行 merge 是 Not Acceptable ，将 releaseX merge 到功能分支中也是 Not Acceptable (它会引入不相关的功能，并且最终会使功能更难不投入生产)。

我们最终只为 merge 创建了一个分支，类似于 resolution/releaseX_my_beautiful_feature。

(目前，更多地遵循类似 githubflow 的模型(而不是 gitflow)，持续部署并且没有真正的发布概念，对我们来说不是最好的解决方案。)

你们在使用 pull 请求和发布时采用什么工作流程？

Answer 1

正如@ckrusek 所说 Atlasssian有一个关于不同类型工作流的很好的文档。关于 gitflow + pull 请求工作流程，他们推荐的是:

• 功能分支开发
• 功能做 pull 请求开发
• 发布分支 develop(分支命名约定:release-* 或 release/*)。发布分支仅用于准备发布，任何尚未开发的功能都将推迟到下一个发布周期。
• 将release分支 merge 到master和develop
• 维护/热修复分支分支 master
• maintenance/hot-fixes 分支 merge 到 master 和 develop

当然，仍然没有办法不在 develop 中混合不相关的功能到我们的功能分支中。

基本上， pull 请求工作流意味着更频繁的发布，为了处理这些，我们需要有功能标志，以便在需要时关闭生产中未经充分测试的功能。该模型为我们带来的是一个包含发布概念和管理发布方式的工作流。