version-control - Mercurial 工作流 - 我什么时候可以 rebase ，什么时候应该 merge ？

Question

我们已经在工作中使用 Mercurial 几个月了。我们对工作流程进行了几次修改，结果如下:

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

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

这对我们有用了一段时间，但仍然有一些困难让我们继续前进:“嗯嗯，也许有更好的方法，感觉不太自然”。

我们遇到的最大问题是当我们有一个功能分支在我们的本地机器上变老时。

例子:

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

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

我们有时会做些什么来缓解这个问题，我们将默认值 merge 回 EpicNewFeature 以使其“跟上速度”。这简化了我们在 QA 上的 merge ，但它通常仍然是本地 merge 的一部分。

我读过关于 rebase 的内容，它应该有助于使下一次 merge 快进，因为你(据我所知)在中间注入(inject)历史，改变你自己的历史。

我读到的关于 rebase 的大部分地方都警告你如果你已经推送了你的分支就不要这样做，如果有人可能已经拉取了你的更改则绝对不会这样做。你怎么能确定这一点？我们经常推送到中央存储库进行备份，我们通常只是 hg pull 一切。

您是否看到了可以帮助我们改进当前工作流程的东西？更频繁地 rebase 对我们有帮助吗？

Answer 1

我想你误解了什么rebasing做。它的工作原理是简单地 merge 到存储库的顶端，然后删除原始链接。这与进行“差异”并将其应用于尖端几乎相同。

您仍然会遇到您试图避免的所有相同的 merge 冲突。

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