6

前言：这不是关于合并冲突的一般问题，而是一个非常具体的案例，一直困扰着我。这是非常微不足道的，但它确实相当于一个（轻微的）麻烦，经常足以脱颖而出。我不关心一般的合并，这只是为了节省几秒钟的时间来解决非常机械的冲突，首先避免所说的冲突。我也绝对知道这不是“git问题”或类似的东西。

也就是说，假设我们有一个类的源文件：

class Xyz
    ...
    ...
   def last_method
      ...
   end
end

master这在和几个功能分支中一开始是相同的。现在，当我们实现我们的功能时，我们向这个类添加更多方法：

分支 1：

class Xyz
    ...
    ...
    def last_method
        ...
    end

    def new_method1
        ...
    end
end

分支 2：

class Xyz
    ...
    ...
    def last_method
        ...
    end

    def new_method2
        ...
    end
end

新方法不相关，当两个分支合并回master.

显然这会导致合并冲突。原因很清楚——我们在完全相同的位置更改了源文件，显然 git 不能（也不应该）神奇地为我们决定这不是“真正的”冲突；git 必须选择应该首先放置哪些方法，等等。

避免冲突的一种方法是在文件的不同位置插入新方法（假设顺序无关紧要），但我们真的不想花太多精力（或实际上根本不）来保持精神上的跟踪在哪里插入东西或在其他功能中发生了什么。

那么问题是：是否有另一种方式，也许是一些编码约定，你经常应用，它以某种方式避免了这种合并冲突？

4

1 回答 1

2

这是一个很好的问题。但是，在某些条件下，有一些方法可以缓解这个问题。

在理想情况下，在设计一个类时，您决定了它的构成（变量、方法等），并且您已经可以为它们选择合适的名称。在这种情况下，您应该在引入该类的提交中编写这些方法的存根。

然后，这些存根将充当基于行的版本控制系统（例如 Git）的“锚点”：

class MyClass

    def initialize
        # TODO
    end

    def get_ID
        # TODO
    end

    def set_ID
        # TODO
    end
end

在这个“第一次”提交之后，不同的贡献者可以自由地更改不同方法的主体：在我的示例中，Alice 可以实现get_ID，Bob 可以实现set_ID，而不必担心在以后遇到合并冲突，因为每个方法的def和end行已经存在于原始提交中。

于 2015-08-14T13:58:26.360 回答