version-control - 版本控制中的二分法是否受益于使用 rebaseif 工作流？

Question

rebaseif mercurial 扩展程序在拉动时自动执行 rebase 的过程，只有在 merge 可以自动完成且没有冲突的情况下才进行 rebase 。 (如果有冲突需要手动解决，它不会 rebase ，让您准备好手动 merge 两个分支。)当开发人员在代码的不同部分工作时，这会简化和线性化历史记录，尽管任何 rebase 都会抛出当开发人员工作时，会带走一些关于世界状况的信息。我倾向于同意像 this 这样的论点。和 this在一般情况下，rebase 不是一个好主意，但我发现 rebase-if 哲学对非冲突情况很有吸引力。我对此持观望态度，尽管我知道当代码的不同部分发生变化时仍然存在逻辑错误的风险(和 the author of rebaseif extension has come to feel it’s a bad idea. 。)

我最近经历了一次复杂而痛苦的二分法，我认为我们的存储库中有大量短分支 merge 是二分法没有实现其隐含的 O(lg n) promise 的主要原因。我发现自己需要多次运行“bisect --extend”，以将范围扩展到 merge 之外，一次通过几个变更集，基本上使平分 O(n)。我还发现跟踪平分的进展情况以及了解到目前为止我获得的信息非常复杂，因为在查看存储库的图表时我无法遵循分支。

是否有更好的方法来使用 bisect(以及查看和理解修订历史)，或者我是否正确，如果我们在开发中更多地使用 rebaseif，这个过程会更顺利。或者，您能否帮助我更具体地了解在非冲突情况下使用 rebase 可能会出现什么问题:它是否有可能导致应该避免的问题？

我更普遍地标记它(不仅仅是 mercurial)，因为我认为 rebaseif 匹配更典型的 git 工作流程:git 用户可能已经看到了陷阱。

Answer 1

我认为答案很简单:您必须在艰难的平分 或冒险的 rebase 之间做出选择。

或者，介于两者之间:只有在 rebase 不太可能悄悄破坏事物的情况下才 rebase 。如果 rebase 仅涉及几个变更集，而且这些变更集在语义上与它们 rebase 所依据的变更相距甚远，则 rebase 通常是安全的。

这是一个示例，其中无冲突 merge 破坏了一些东西:

假设两个分支从具有以下内容的文件开始:

def foo(a):
    # do
    # something
    # with a (an integer)

...

foo(4)

在分支 A 中，这被更改为:

def foo(a):
    # now this function is 10 times faster, but only work with positive integers
    assert a > 0
    # do
    # something with
    # with a

...

foo(4)

在分支B中，改为:

def foo(a):
    # do
    # something
    # with a (an integer)

...

foo(4)

...

foo(-1) # now we have a use case where we need to call foo with -1

在语义上，这两个编辑相互冲突。然而，Mercurial 愉快地 merge 它们而没有冲突(在这两种情况下，当 rebase 或进行常规 merge 时):

def foo(a):
    # now this function is 10 times faster, but only work with positive integers
    assert a > 0
    # do
    # something with
    # with a

...

foo(4)

...

foo(-1) # now we have a use case where we need to call foo with -1

merge 的优点是它允许在以后的某个时间点了解哪里出了问题，因此您可以相应地修复问题。 rebase 可能会丢弃您了解自动 merge 引起的错误所需的信息。