我们的团队似乎一遍又一遍地遇到这个问题。当我们开始一个项目时，我们从master创建一个集成分支，并将其命名为stable。现在，每个开发人员都从stable分支出来，一旦完成，他们就会向stable创建拉取请求并在关闭之前进行压缩和合并。
当我们想要merge stable回到master时，问题就出现了。我们通常rebase在master之上，但这导致了许多冲突，因为master比我们分支时有更多的提交。
我读了一些帖子，比如 - Git Workflows: Rebasing Published/Shared Branches，其中一些似乎主张将master合并到stable，然后在创建拉动请求时在rebase上做stable的最终master然后有一个What is the right git workflow with shared feature branches?说这个从master回到stable是一个坏主意。
我的问题是 - 是时候将master和stable合并在一起是理想的解决方案，以防止我们每次经历的rebase冲突地狱还是有更好的解决方案吗？如果已经回答，请告诉我。
我们不能更快地merge stable到master，因为master需要最新和最好的端到端功能生产准备代码。
是不是将主人和稳定的时间合并到这里是理想的解决方案，以防止我们每次经历的反叛冲突地狱或者那里有更好的解决方案吗？
在您的特定工作流程中，在更新稳定版的同时主动修改master ...是的，即使这不是最佳实践。
理想情况下，在更新集成分支（稳定）时，master不应该发展很多。 这种工作流程的一个例子：gitworkflow，它使用“下一个”分支作为集成，但然后将功能分支本身直接重新合并到master（自上次发布以来没有太大变化）