Merge : Qu'est-ce qu'un merge en Git ?

Qu'est-ce qu'un merge en Git ?

Le merge (ou fusion) est une opération fondamentale de Git qui permet de combiner l'historique de deux branches en une seule. Lorsqu'un développeur a terminé son travail sur une branche de fonctionnalité, le merge est l'étape finale qui intègre ses modifications dans la branche principale (souvent main ou develop). C'est le point de convergence où le travail individuel rejoint le projet commun.

Git est conçu pour faciliter le travail en parallèle via les branches. Le merge est le mécanisme complémentaire qui permet de réconcilier ces travaux parallèles. La commande git merge analyse les différences entre les deux branches, identifie les modifications compatibles et les combine automatiquement. Lorsque les modifications portent sur les mêmes lignes de code, un conflit de merge survient et nécessite une intervention humaine.

Chez KERN-IT, le merge est étroitement lié à notre processus de pull request. Chaque merge dans la branche principale est précédé d'une revue de code et d'une validation des tests automatisés, garantissant que seul du code de qualité rejoint le tronc commun.

Pourquoi le merge est important

Le merge est l'opération qui donne tout son sens au branching. Sans lui, les branches seraient des impasses : du code isolé qui ne rejoindrait jamais le projet principal.

• Intégration du travail d'équipe : le merge est le moment où les contributions individuelles sont réunies. C'est la clé de voûte de la collaboration dans un projet Git.
• Préservation de l'historique : contrairement à certaines opérations destructives, le merge préserve l'intégralité de l'historique des deux branches. Chaque commit reste traçable.
• Livraison de fonctionnalités : dans un workflow Gitflow ou GitHub Flow, le merge d'une branche feature dans main marque la livraison officielle d'une fonctionnalité.
• Résolution de divergences : lorsque deux développeurs ont modifié le même code en parallèle, le merge est le moment de réconciliation où les différences sont résolues explicitement.

Comment ça fonctionne

Git propose deux types principaux de merge. Le fast-forward merge est le cas le plus simple : il survient lorsque la branche cible n'a reçu aucun nouveau commit depuis la création de la branche source. Git se contente alors de déplacer le pointeur de la branche cible vers le dernier commit de la branche source, sans créer de commit de merge supplémentaire.

Le three-way merge est nécessaire lorsque les deux branches ont divergé (elles contiennent chacune des commits que l'autre n'a pas). Git identifie alors le commit ancêtre commun aux deux branches et crée un nouveau commit de merge qui combine les modifications des deux côtés. Ce commit de merge a deux parents, ce qui crée une structure en losange dans le graphe de l'historique.

La résolution de conflits est l'aspect le plus délicat du merge. Un conflit survient lorsque les deux branches ont modifié les mêmes lignes d'un même fichier. Git marque les zones conflictuelles dans le fichier avec des marqueurs spéciaux (<<<<<<<, =======, >>>>>>>) et demande au développeur de choisir manuellement quelle version conserver ou de combiner les deux.

Merge vs Rebase

Le rebase est une alternative au merge qui produit un historique linéaire. Au lieu de créer un commit de merge, git rebase rejoue les commits d'une branche au sommet d'une autre. Le résultat est un historique plus propre, mais l'opération réécrit les commits, ce qui peut poser problème sur les branches partagées.

La règle d'or est simple : utilisez le rebase pour les branches locales non partagées et le merge pour intégrer les branches dans le tronc commun. Chez KERN-IT, nous combinons les deux : rebase local pour nettoyer l'historique avant de créer la PR, puis squash merge pour l'intégration finale.

Exemple concret

Deux développeurs KERN-IT travaillent simultanément sur le même projet. Le premier développe un nouveau module de reporting sur la branche feature/reporting, tandis que le second corrige des bugs sur fix/data-validation. Le fix est mergé en premier dans main via une pull request.

Lorsque le développeur du module reporting crée sa pull request, GitHub détecte un conflit : les deux développeurs ont modifié le même fichier de modèle. Le développeur récupère les dernières modifications de main, résout le conflit en conservant les corrections de son collègue tout en ajoutant ses nouveaux champs, et pousse la résolution. La PR est ensuite mergée sans problème.

Bonnes pratiques

1. Mergez fréquemment main dans vos branches : récupérez régulièrement les dernières modifications de la branche principale pour limiter les conflits lors du merge final.
2. Résolvez les conflits avec soin : prenez le temps de comprendre les deux versions du code avant de résoudre un conflit. Un conflit mal résolu introduit des bugs subtils et difficiles à tracer.
3. Utilisez le squash merge pour les feature branches : cela produit un historique propre dans main avec un commit par fonctionnalité.
4. Ne forcez jamais un merge : si Git signale des conflits, résolvez-les correctement plutôt que de forcer la fusion.
5. Testez après le merge : même si les tests CI passent, effectuez un test manuel rapide pour vérifier que l'intégration fonctionne comme attendu.

Conclusion

Le merge est le moment de vérité dans le flux de développement Git. C'est l'opération qui transforme des travaux parallèles en un projet cohérent. Bien maîtrisé, il permet une collaboration fluide et un historique de projet clair. Mal géré, il peut introduire des régressions et de la confusion. La clé est d'adopter des pratiques de merge cohérentes au sein de l'équipe et de s'appuyer sur les outils d'automatisation pour garantir la qualité à chaque intégration.