版本控制中的二等分是否可以从使用rebaseif工作流程中受益？

Question

只有在没有冲突的情况下自动完成合并时,rebaseif mercurial扩展才会自动执行该过程.(如果存在要手动解决的冲突,则不会进行rebase,让您准备手动合并两个分支.)当开发人员在代码的不同部分工作时,这会简化并线性化历史记录,尽管任何rebase都会抛出当开发人员开始工作时,远离一些关于世界状况的信息.我倾向于喜欢争执同意这个和这个,在一般情况下,垫底是不是一个好主意,但我觉得底垫,如果理念呼吁非冲突情况.虽然我明白当代码的不同部分发生变化时仍然存在逻辑错误的风险(并且rebaseif扩展的作者已经认为这是一个坏主意.)

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

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

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

Answer 1

我认为答案很简单:你必须在硬二等分之间进行分配或者有风险的变基.

或者介于两者之间:只有在不太可能无效地破坏事物的情况下才能进行反转.如果一个rebase只涉及一些变更集,这些变更集在语义上远离它们被重新定义的变化,那么通常可以安全地进行变基.

这是一个无冲突合并破坏事物的例子:

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

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很乐意合并它们而不会发生冲突(在两种情况下,在重新定位或进行常规合并时):

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

合并的优点在于它可以让您在以后的某个时间点了解错误,因此您可以相应地修复问题.rebase可能会丢弃您需要的信息,以了解自动合并导致的错误.