我们的团队似乎一次又一次地遇到这个问题。当我们开始一个项目时，我们从master创建一个集成分支，并将其命名为stable。现在，每个单独的开发人员都从stable分支出来，一旦完成，他们就会向stable创建拉取请求，并在关闭之前进行挤压和合并。
当我们想merge stable回到master时，就会发生问题。通常，我们rebase位于master之上，但这会导致许多冲突，因为下线master的提交数比分支开始时多了两个月。
我阅读了一些帖子，例如-Git Workflows: Rebasing Published/Shared Branches，其中有些似乎主张不定期合并master与stable，然后再进行{{1 }}在创建请求请求时位于rebase之上，然后有一个What is the right git workflow with shared feature branches?表示从stable到master的反向合并是一个坏主意。
我的问题是-不时将master合并到stable是这里的理想解决方案，可以防止我们每次经历的master冲突地狱或有没有有更好的解决方案吗？如果已经回答了，请告诉我。
由于stable需要最新，最强大的端到端功能生产就绪代码，因此我们无法rebase merge到stable早点。
答案 0 :(得分：1)
这里不时将主服务器合并为稳定服务器是防止我们每次都要经历的变基冲突地狱的理想解决方案，还是那里有更好的解决方案？
在您的特定工作流程中，主动修改master并更新稳定版...是的，即使这不是最佳实践。
理想情况下，在集成分支（稳定）更新时，master应该不发展很多。
这样的工作流程的一个示例：gitworkflow，它使用“下一个”分支作为集成，但是随后将功能分支本身直接重新合并到master（自上次发行以来没有太大变化）