Как избежать конфликтов объединения при использовании разных методов (и т. Д.) В одном месте?

Question

Предисловие: это не общий вопрос о конфликтах слияния, а очень конкретный случай, который продолжает прослушивать меня. Это довольно тривиально, но это сводится к (легкой) стычке, достаточно часто выделяющейся. Меня не волнует общее слияние, это всего лишь экономия нескольких секунд здесь и там для очень механического разрешения конфликтов, избегая упомянутого конфликта в первую очередь. Я также абсолютно понимаю, что это не «проблема с git» или что-то в этом роде.

Это говорит, что у нас есть исходный файл класса:

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

Это начинается тождественны в master и несколько филиалов особенность. Теперь, когда мы реализуем наши возможности, мы добавим больше методов этого класса:

Branch 1:

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

    def new_method1 
     ... 
    end 
end 

Branch 2:

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

    def new_method2 
     ... 
    end 
end 

Новые методы не связаны и счастливо сосуществовать когда обе ветви сливаются обратно в master.

Очевидно, что это приведет к конфликту слияния. Причина ясна - мы изменили исходный файл в точно таком же месте, и, очевидно, git не может (и не должен) волшебно решать для нас, что это не «реальный» конфликт; git должен был бы выбрать, какой из методов следует разместить первым и т. д.

Одним из способов избежать конфликта было бы вставить новые методы в разные места в файле (при условии, что порядок не имеет значения), но мы на самом деле не хотят тратить много сил (или вообще на всех), чтобы мысленно отслеживать, куда вставлять материал или что происходит в других функциях.

Вопрос: тогда есть другой способ, может быть, какое-то соглашение о кодировании, которое вы регулярно применяете, что каким-то образом избегает конфликта слияния?

Answer 1

Это хороший вопрос. Однако есть способы смягчения проблемы при определенных условиях.

В идеальном случае, во время проектирования класса, вы решаете, из чего он будет сделан (переменные, методы и т. Д.), И вы уже можете выбрать подходящие имена для них. В этом случае вы должны написать stubs этих методов в коммите, который вводит класс.

Эти окурки будут затем действовать в качестве «якоря» для системы управления версиями линии на основе таких как Git:

class MyClass 

    def initialize 
     # TODO 
    end 

    def get_ID 
     # TODO 
    end 

    def set_ID 
     # TODO 
    end 
end 

После этого «первого» фиксации, различные авторы могут свободно изменять тело различных методов : в моем примере Алиса может реализовать get_ID, и Боб может реализовать set_ID, не опасаясь столкнуться с конфликтом слияния дальше по дороге, потому что линии def и строк каждого метода уже присутствуют в исходной фиксации.