Mercurial工作流程 - 什么时候可以重新定义，何时合并？

Question

我们一直在使用Mercurial工作了几个月。我们已经修改了我们的工作流程一段时间，结果是：

初始快照在 staging 上，然后我们将其克隆到我们的中央存储库，并且每个人都克隆了本地。

• 当我们处理feature / bugfix时，我们总是从staging更新到最新的默认值，以便从最新的生产副本开始。
• 然后我们将功能分支推送到中央存储库进行备份，使其可供团队使用等。
• 我们继续我们的QA系统并拉出功能分支并将其合并到那里。
• 如果QA在功能上签收，我们会将其合并到同一台机器上的稳定分支中。
• 然后我们将稳定分支拉到分段，将其合并到那里并进行汇总测试。
• 如果一切顺利，我们会将所有内容复制到实时系统中。

这对我们来说已经有一段时间了，但仍有一些让我们离开的原因：“mmmmh，也许有更好的方式，它不太自然”。

我们遇到的最大问题是我们的本地计算机上有一个功能分支。

示例：

• 我的系统上有分支62_EpicNewFeature。
• 优先事项得到重组，EpicNewFeature停止工作:(
• 6个月后，我终于恢复了EpicNewFeature的工作

此时，该分支落后于当前默认值。如果我完成它并尝试将其合并到 QA 上，我将会遇到很多冲突（为此你几乎总是保留QA上的内容。）

我们有时会采取什么措施来缓解这个问题，我们将默认值合并到EpicNewFeature中，以使其“达到速度”。这简化了我们在QA上的合并，但它通常仍然是本地合并的一部分。

我已经阅读了关于变基的信息，这有助于使下一次合并成为一个快进因为你（从我的理解）注入中间的历史，改变你自己的历史。

我读到的关于rebase的大多数地方警告说，如果你已经推动了你的分支，你就不要这样做，如果有人可能已经撤消了你的修改，那绝对不会。你怎么能确定这一点？我们经常推送到中央存储库进行备份，我们通常只需要提取所有内容。

您是否看到了有助于我们改进当前工作流程的内容？变态会更经常帮助我们吗？

Answer 1

我认为你误解了rebasing的作用。它的工作原理是简单地合并到存储库的顶端，然后切掉原始链接。这与采取“差异”并将其应用于尖端的行为几乎相同。

你仍然会遇到你想要避免的所有相同的合并冲突。

通常，处理这些冲突的最简单方法是零碎的。不要试图一次性合并到提示。