Pour fusionner une branche de développement dans la branche actuelle, utilisez « git merge dev-branch-name ». Si vous recevez des avertissements de conflit à propos d’une fusion, utilisez « git merge –abort » pour revenir en arrière, ou modifiez les fichiers concernés, puis validez-les.
Git utilise des branches pour isoler les flux de développement, afin d’éviter que la branche de version stable ne soit polluée. Amener le travail d’une succursale dans le flux principal signifie fusionner des succursales. Voici comment procéder.
Qu’est-ce qu’une fusion dans Git ?
Git a été conçu pour rendre la création de branches simple et rapide. Contrairement à d’autres systèmes de contrôle de version, la création de branches sur Git est une affaire triviale. Sur les projets multi-développeurs en particulier, la création de branches est l’un des principaux outils d’organisation de Git.
Branchez les nouveaux efforts de développement en bac à sable afin que le code puisse être modifié ou ajouté sans affecter le code des autres branches, en particulier la branche principale ou principale. Celui-ci contient généralement la version stable de votre base de code.
Isoler ces modifications de votre version de code stable est parfaitement logique. Mais tôt ou tard, le nouveau code sera testé, révisé et approuvé pour être intégré à la branche principale. À ce stade, vous devez fusionner votre branche dans la branche master.
En fait, les branches peuvent avoir des sous-branches, vous pouvez donc fusionner votre branche dans une autre branche au lieu de la branche principale. N’oubliez pas que les fusions prennent toujours une branche et la fusionnent en une cibler branche, quelle que soit cette branche. Si vous souhaitez fusionner votre branche principale dans une autre branche, vous pouvez même le faire également.
Comme la plupart des actions dans Git, vous effectuez des fusions dans votre référentiel local et les poussez vers votre référentiel distant.
Se préparer à fusionner une branche dans Git
Nous avons un petit projet de développement avec un référentiel Git local et un référentiel Git distant. Nous avons créé une branche appelée « bugfix14 » à partir de la branche « master » et avons travaillé sur une solution à un bogue.
Ce travail est terminé et nous avons testé notre code. Tout fonctionne comme prévu. Nous souhaitons appliquer ces modifications à la branche master afin que notre correctif fasse partie de la prochaine version du logiciel.
Il y a une petite préparation à faire avant d’effectuer la fusion. Nous devons nous assurer que la branche cible – dans ce cas, la branche « maître » – et la branche que nous allons fusionner avec elle sont toutes les deux à jour.
Pour ce faire, nous utiliserons le git status commande.
git status
- Sur la branche bugfix14: Il s’agit de notre succursale actuelle.
- Votre branche est à jour avec ‘origin/bugfix’: La branche de notre référentiel local a le même historique de validation que la branche du référentiel distant. Cela signifie qu’ils sont identiques.
- rien à engager Il n’y a pas de modifications dans la zone de préparation qui n’ont pas été validées.
- arbre de travail propre: Il n’y a pas de changements non préparés dans le répertoire de travail.
Tout cela indique que la branche est à jour, et nous sommes prêts à continuer. Si l’un d’entre eux indiquait que des changements existaient, nous devions les mettre en scène, les valider et les pousser vers la télécommande. Si quelqu’un d’autre a travaillé sur ces fichiers, nous devrons peut-être extraire leurs modifications du référentiel distant.
Vérifier la branche dans laquelle nous allons fusionner simplifie le processus de fusion. Cela nous permet également de vérifier qu’il est à jour. Regardons la branche master.
git checkout master
git status
Nous obtenons les mêmes confirmations que la branche « master » est à jour.
EN RELATION: Comment choisir le modèle de workflow et de branchement Git qui convient à votre équipe
Effectuer une fusion
Avant de fusionner, nos commits ressemblent à ceci.
La branche « bugfix14 » a été dérivée de la branche « master ». Il y a eu un commit dans la branche « master » après la création de la branche « bugfix14 ». Il y a eu quelques commits sur la branche « bugfix14 ».
Nous nous sommes assurés que nos deux branches sont à jour et nous avons vérifié la branche « master ». Nous pouvons émettre la commande pour fusionner la branche « bugfix14 » dans la branche « master ».
git merge bugfix14
La fusion a lieu. La branche « bugfix14 » existe toujours, mais maintenant les modifications apportées à cette branche ont été fusionnées dans la branche « master ».
Dans ce cas, la commande merge effectue une fusion à trois. Il n’y a que deux branches, mais il y a trois commits impliqués. Ils sont à la tête de l’une ou l’autre branche et d’un troisième commit qui représente l’action de fusion elle-même.
Pour mettre à jour notre référentiel distant, nous pouvons utiliser le git pousser commande.
git push
Certaines personnes préfèrent supprimer les branches latérales une fois qu’elles les ont fusionnées. D’autres prennent soin de les conserver comme un enregistrement de la véritable histoire de développement du projet.
Si vous voulez supprimer la branche, vous pouvez le faire en utilisant le git branch commande avec le -d (supprimer).
git branch -d bugfix14
Pour supprimer la branche dans le dépôt distant, utilisez cette commande :
git push origin --delete bugfix14
Vous aurez un historique de validation linéaire, mais ce ne sera pas le véritable historique.
EN RELATION: Comment supprimer des branches Git sur des référentiels locaux et distants
Effectuer une fusion accélérée dans Git
Si vous n’avez effectué aucun commit sur la branche « master », votre historique ressemblera à ceci. Cela ressemblera également à ceci si vous avez rebasé votre branche de développement afin qu’elle soit attachée à la fin de la branche « master ».
Comme il n’y a pas de commits dans la branche « master », pour fusionner la branche « bugfix15 », tout ce que Git a à faire est de pointer le pointeur principal « master » vers le dernier commit de la branche « bugfix15 ».
Nous pouvons utiliser l’habituel git merge commande:
git merge bugfix15
Cela nous donne ce résultat.
Qui est le même que celui-ci :
Ce qui revient au même que ceci :
Git effectuera une fusion rapide chaque fois que cela peut. Si les commits sur la branche « master » signifient qu’une fusion rapide n’est pas possible, Git utilisera un fusion à trois.
Vous ne pouvez pas Obliger une fusion en avance rapide – ce n’est peut-être pas possible, après tout – mais vous pouvez déclarer qu’il s’agira d’une fusion en avance rapide ou rien. Il existe une option qui demande à Git d’utiliser une fusion rapide s’il le peut, mais de ne pas faire de fusion à trois voies s’il ne le peut pas. L’option est --ff-only (fusion rapide uniquement).
Cela fusionne la branche « bugfix15 » dans la branche « master », mais seulement si une fusion rapide est possible.
git merge --ff-only bugfix15
Git se plaindra et quittera si ce n’est pas possible.
git merge --ff-only bugfix16
Dans ce cas, il y a eu des validations dans la branche « master », donc une fusion rapide n’est pas possible.
Comment résoudre les conflits de fusion dans Git
Si les mêmes parties du même fichier ont été modifiées dans les deux branches, les branches ne peuvent pas être fusionnées. Une interaction humaine est nécessaire pour résoudre les modifications conflictuelles.
Ici, nous avons apporté des modifications à un fichier appelé « rot.c » dans une branche appelée « bugfix17 » que nous voulons fusionner avec la branche « master ». Mais « rot.c » a également été modifié dans la branche « master ».
git merge bugfix17
Lorsque nous essayons de le fusionner, nous recevons un avertissement indiquant qu’il y a des conflits. Git répertorie les fichiers en conflit et nous indique que la fusion a échoué. Nous pourrions reculer complètement en utilisant le --abort option:
git merge --abort
Mais résoudre les fusions n’est pas aussi effrayant qu’il n’y paraît. Git a fait du travail pour nous aider. Si nous modifions l’un des fichiers en conflit (dans notre cas, nous n’en avons qu’un), nous trouverons les sections de code en conflit mises en évidence pour nous.
Chaque conflit est délimité par sept caractères de moins de « <<<<<<< » et sept caractères supérieurs à « >>>>>>>« , avec sept signes égal « ======= » entre eux.
- Le code au-dessus des signes égal provient de la branche que vous fusionnez dans.
- Le code sous le signe égal est le code de la branche que vous essayez de fusionner.
Vous pouvez facilement rechercher l’un des ensembles de sept caractères et passer d’un conflit à l’autre dans votre dossier. Pour chaque conflit, vous devez choisir quel ensemble de modifications vous allez conserver. Vous devez éditer le code que vous rejetez et les lignes à sept caractères ajoutées par Git.
Nous allons garder le code de la branche « bugfix17 ». Après édition, notre fichier ressemble à ceci.
Nous pouvons maintenant poursuivre la fusion. Mais attention, nous utilisons le commit commande de le faire, pas le merge commande.
Nous validons la modification en mettant en scène le fichier et en le validant comme d’habitude. Nous vérifierons le statut avant de faire le commit final.
git add rot.c
git status
git commit -m "Merged bugfix17"
La fusion est terminée. Nous pouvons maintenant envoyer ceci à notre référentiel distant.
EN RELATION: Comment réparer, modifier ou annuler les commits Git (modification de l’historique Git)
Tout finit par fusionner
Toutes les branches doivent être fusionnées, éventuellement, afin que leurs modifications ne deviennent pas orphelines et oubliées.
La fusion de branches est facile, mais la gestion des conflits peut devenir compliquée dans les grandes équipes occupées. La résolution des conflits peut nécessiter la contribution de chaque développeur juste pour expliquer ce que fait son code et pourquoi il a apporté ses modifications. Vous devez comprendre cela avant de pouvoir prendre une décision éclairée sur les modifications à conserver.
Malheureusement, Git ne peut pas aider avec ça.
EN RELATION: Devriez-vous utiliser un client GUI Git ?