GIT
Merge : Pas de "conflicts", pas de soucis ?
Julien Braure, Responsable Technique @DeliaTechnologies
March 2, 2023
10 min
Dans notre série d'article sur le versioning, abordons le moment du "Merge". Cette étape de base se veut très simple, en théorie. Mais en pratique il faut rester vigilant car l’absence de conflits ne garanti pas l’absence de problèmes...
C'est le moment où nous voulons récupérer les changements provenant d'une branche, pour les intégrer dans une autre branche.
Par exemple, le cas le plus commun d'un merge est : après avoir travaillé sur une branche (feature, bugfix, ...), nous voulons inclure ce travail dans la branche principale (généralement main sur git).
Ce 1er cas est le plus simple. Pendant que nous travaillions sur notre branche, la branche main n'a pas reçu de modifications. Lorsque nous réalisons le merge de la branche feature/login, il n'y a pas de conflicts, et tout fonctionne aussi bien sur main (G) que sur notre branche (F).
Bien entendu votre code sur F est stable et les tests sont tous passants, c’est le même état sur G.
Malheureusement, il n'y a pas de garantie que la branche main n'ait pas évolué, et dans un projet réel, avec plusieurs développeurs, main change rapidement.
Ici nous avons démarré une 2ème branche, par exemple bugfix/login, que nous voulons merger dans main. Cependant, durant notre travail, la branche main a changé (elle est passée de G à K). Les raisons peuvent être multiples, disons qu'un autre développeur travaillait sur une autre branche (démarrée également a partir de G) et l'a mergée avant nous (dans K).
Dans cette situation, nous sommes tentés de merger notre branche dans main pour obtenir L.
Nous n'avons pas eu de conflicts, c'est bien... mais ne soyons pas contents trop vite...
Est-ce que l'absence de merge-conflict nous garantit pour autant que:
La réponse à toutes ces questions est: peut être, mais rien ne le garantit :-/
En effet, nous tentons un build, mais le projet ne compile plus... zut
👉 Un merge-conflict arrive seulement et seulement si des lignes identiques (ou très proches avec git) ont été modifiées (ajoutées et/ou supprimées) dans un fichier.
Il faut donc comprendre que si l'on ne travaille pas sur les mêmes lignes ou les mêmes fichiers, nous évitons les conflicts, ... mais pas les problèmes. En effet, le simple fait que le commit J renomme une fonction (ou un fichier), alors que nous avons rajouté un appel à cette méthode dans la branche, le code ne compilera donc plus lors du merge L.
Afin de se protéger du danger des merges, que devons-nous donc faire ?
Il faut rebase sa branche avant de la merger dans main.
Cela permet, en effet, de déplacer le problème dans la branche, au lieu de l'avoir sur main. Dans ce cas, on peut relancer le build (compile + tests) du projet sur la branche et réparer ce qui doit l’être. Une fois le build ok sur la branche, nous pouvons merger la branche dans main.
Pour cela, 2 méthodes :
Git est un outil très puissant (bien plus puissant que SVN, où cette méthode n'est pas possible). Git permet en effet de "déplacer" nos commits H et I qui partaient de G, pour les rattacher à K. Cette opération s'effectue avec git rebase.
A noter: lors d'un git rebase
Gardez en tête que si vous n'avez pas de merge-conflict avec la méthode 1, il est très peu probable que vous en ayez avec git rebase. Cependant, en fonction du contenu de vos commits que vous allez rebase, il est tout de même possible d'obtenir des conflicts durant le rebase. Dans ce cas, pas de panique, il suffit de les résoudre (éditer les fichiers, puis les ajouter au staging area avec git add), puis au lieu de git commit, faire simplement git rebase --continue.
Si quelque chose se passe mal et vous vous sentez perdu, pas de panique, vous pouvez annuler le rebase en cours et retourner à la case depart, avec un simple git rebase --abort
Dans un autre article nous creuserons d'autres modes plus avancés de git rebase, comme git rebase --interactive, qui vous permettent de manipuler vos commits, changer leur ordre, en supprimer un, en fusionner certains...
Après un git rebase, il faut absolument éviter de git pull avant d’avoir push sa branche, sinon vous aller obtenir un merge de votre branche avant rebase (I) avec votre propre branche après rebase (I’) dans un nouveau merge-commit (W) 😭.
C’est très mauvais car cela a dupliqué les commits dans le graph d’historique...
Pas de panique, si vous faites cette erreur, il suffit d’annuler cette situation avec git reset --hard HEAD^. La branche locale bugfix/login pointera de nouveau vers I' 👍
Réservez un moment avec notre équipe RH en quelques clics, pour voir ensemble le meilleur moyen de nous rejoindre. Vous avez des questions sur Delia Technologies ? C'est le moment de les poser !
Rencontrer notre équipe