Comment éviter les conflits de fusion lorsque différentes méthodes (etc.) sont ajoutées au même endroit?

Question

Préface: ce n'est pas une question générale sur les conflits de fusion, mais un cas très spécifique qui ne cesse de me déranger. C'est assez trivial, mais cela revient à un (léger) tracas assez souvent pour se démarquer. Je ne suis pas préoccupé par la fusion générale, il s'agit juste de sauver quelques secondes ici et là pour une résolution de conflit très mécanique, en évitant d'abord ce conflit. Je suis également absolument conscient que c'est pas un un "problème de git" ou quelque chose comme ça.

Cela dit, supposons que nous avons un fichier source d'une classe:

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

Cela commence identique master et plusieurs branches de fonction. Maintenant, nous mettons en œuvre nos fonctions, nous ajoutons plus de méthodes à cette classe:

Branche 1:

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

    def new_method1 
     ... 
    end 
end 

Branche 2:

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

    def new_method2 
     ... 
    end 
end 

Les nouvelles méthodes ne sont pas liés et vont coexister avec bonheur lorsque les deux branches sont fusionnées à master.

De toute évidence, cela entraînera un conflit de fusion. La raison est claire: nous avons changé le fichier source exactement au même endroit, et de toute évidence, git ne peut pas (et ne devrait pas) décider magiquement pour nous que ce n'est pas un «vrai» conflit; git devrait choisir laquelle des méthodes devrait être placée en premier, etc.

Une façon d'éviter le conflit serait d'insérer les nouvelles méthodes à différents endroits dans le fichier (en supposant que l'ordre n'a pas d'importance), mais nous ne veut vraiment pas dépenser beaucoup d'efforts (ou pas du tout, en fait) pour garder une trace mentale où insérer des choses ou ce qui se passe dans d'autres fonctionnalités. La question, alors: y a-t-il une autre manière, peut-être une convention de codage, que vous appliquez régulièrement, qui évite en quelque sorte ce conflit de fusion?

Answer 1

C'est une bonne question. Cependant, il existe des moyens d'atténuer le problème, sous certaines conditions. Dans le cas idéal, au moment de la conception d'un cours, vous décidez de quoi il sera fait (variables, méthodes, etc.), et vous pouvez déjà choisir les noms appropriés pour ceux-ci. Dans ce cas, vous devez écrire stubs de ces méthodes dans le commit qui introduit la classe.

Ces talons servent alors comme des « points d'ancrage » pour un système de contrôle de version en ligne tels que Git:

class MyClass 

    def initialize 
     # TODO 
    end 

    def get_ID 
     # TODO 
    end 

    def set_ID 
     # TODO 
    end 
end 

Après cette « première » commit, différents contributeurs sont libres de changer le corps de différentes méthodes : dans mon exemple, Alice peut implémenter get_ID et Bob peut implémenter set_ID sans craindre de se heurter à un conflit de fusion plus loin, car les lignes def et end de chaque méthode sont déjà présentes dans la validation d'origine.