git - 当在同一位置添加不同的方法(等)时，如何避免 merge 冲突？

Question

前言:这不是关于 merge 冲突的一般问题，而是一个一直困扰着我的非常具体的案例。这是非常微不足道的，但它确实构成了一个(轻微的)麻烦，经常足以脱颖而出。我不关心一般的 merge ，这只是通过首先避免所述冲突来在这里和那里节省几秒钟的时间来解决非常机械的冲突。我也绝对知道这不是“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

新方法不相关，当两个分支 merge 回 master 时会愉快地共存。

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

避免冲突的一种方法是在文件的不同位置插入新方法(假设顺序无关紧要)，但我们真的不想花费太多精力(实际上根本不想花费任何精力)在头脑中跟踪插入内容的位置或其他功能中发生的事情。

那么问题是:是否有另一种方法，也许是您经常应用的某种编码约定，以某种方式避免这种 merge 冲突？

Answer 1

这是个好问题。但是，在某些情况下，有一些方法可以缓解这个问题。

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

然后，这些 stub 将充当基于行的版本控制系统(例如 Git)的“ anchor ”:

class MyClass

    def initialize
        # TODO
    end

    def get_ID
        # TODO
    end

    def set_ID
        # TODO
    end
end

在“第一次”提交之后，不同的贡献者可以自由更改不同方法的主体:在我的示例中，Alice 可以实现 get_ID，Bob 可以实现 set_ID，无需害怕在以后遇到 merge 冲突，因为每个方法的 def 和 end 行已经存在于原始提交中。