我应该在 rebase 之前将 master 合并到共享的稳定集成分支吗?

Should I merge master to a shared stable integration branch before rebase?

我们的团队似乎 运行 一遍又一遍地陷入这个问题。当我们开始一个项目时,我们从 master 创建一个集成分支并将其命名为 stable。现在,每个开发人员都从 stable 分支出来,一旦完成,他们就会向 stable 创建一个拉取请求,并在关闭它之前进行压缩和合并。

当我们想要 merge stable 回到 master 时,问题就出现了。我们通常 rebasemaster 之上,但这会导致很多冲突,因为 2 个月后 master 的提交比我们分支时要多得多。

我读了一些帖子,例如 - Git Workflows: Rebasing Published/Shared Branches and some of them seem to advocate merging master to stable from time to time before doing the final rebase of stable on top of master at the time of creating a pull request and then there was one What is the right git workflow with shared feature branches?,其中说从 master 反向合并到 stable 是个坏主意。

我的问题是 - 不时将 master 合并到 stable 是否是防止我们每次或正在经历的 rebase 冲突地狱的理想解决方案那里有更好的解决方案吗?如果这已经得到回答,请告诉我。

我们不能 merge stablemaster 更快,因为 master 需要最新最好的端到端功能生产就绪代码。

Is merging master to stable from time-to-time the ideal solution here to prevent the rebase conflict hell which we go through every time or are there any better solutions out there?

在您的特定工作流程中,在更新稳定版的同时主动修改主版...是的,尽管这不是最佳做法。

理想情况下,master 应该不会 在您的集成分支(稳定)更新时进化太多。
此类工作流的示例:,它使用 "next" 分支作为集成,但随后会将功能分支本身直接重新合并到 master(自上次发布以来没有太大变化)