git – 当在同一位置添加不同的方法(等)时,如何避免合并冲突？

2024年1月20日 222次阅读

前言：这不是关于合并冲突的一般性问题,而是一个让我烦恼的非常具体的案例.这是非常微不足道的,但它确实相当于(轻微)麻烦,经常足以脱颖而出.我并不担心一般合并,这只是为了解决非常机械的冲突解决方案,通过首先避免冲突来节省几秒钟.我也绝对意识到这不是一个“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

新方法没有关系,并且当两个分支合并回主服务器时,它们将很乐意共存.

显然这会导致合并冲突.原因很明显 – 我们在完全相同的位置更改了源文件,显然git不能(也不应该)神奇地决定我们这不是“真正的”冲突; git必须选择首先放置哪种方法,等等.

避免冲突的一种方法是在文件中的不同位置插入新方法(假设顺序无关紧要),但我们真的不想花费太多精力(或者根本没有,实际上)精神上保持跟踪插入内容的位置或其他功能中发生的情况.

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

最佳答案 这是一个很好的问题.但是,在某些条件下,有一些方法可以缓解这个问题.

在理想的情况下,在设计类时,您可以决定它将由什么构成(变量,方法等),并且您已经可以为这些类选择合适的名称.在这种情况下,您应该在引入该类的提交中编写这些方法的存根.

那些存根将作为基于行的版本控制系统(如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每个方法的行已经存在于原始提交中.

点赞