Comment utiliser la fusion Git
Publié: 2023-01-03Git 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 ?
Se préparer à fusionner une branche dans Git
Effectuer une fusion
Effectuer une fusion accélérée dans Git
Comment résoudre les conflits de fusion dans Git
Tout finit par fusionner
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 dans une branche cible , 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 la commande git status
.
statut git
- Sur la branche bugfix14 : Il s'agit de notre branche actuelle.
- Votre branche est à jour avec 'origin/bugfix' : La branche de notre dépôt local a le même historique de commit que la branche du dépôt distant. Cela signifie qu'ils sont identiques.
- rien à valider Il n'y a aucun changement dans la zone de préparation qui n'ait pas été validé.
- arbre de travail propre : il n'y a pas de modifications non planifiées 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.
maître de caisse git
statut git
Nous obtenons les mêmes confirmations que la branche « master » est à jour.
CONNEXION : Comment choisir le modèle de flux de travail 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 fusion 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 voies . 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 la commande git push .
git pousser
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 souhaitez supprimer la branche, vous pouvez le faire en utilisant la commande git branch
avec l'option -d
(supprimer).
branche git -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.
CONNEXION: 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 la commande habituelle git merge
:
git fusion 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 qu'il le pourra . Si les commits sur la branche "master" signifient qu'une fusion rapide n'est pas possible, Git utilisera une fusion à trois voies .
Vous ne pouvez pas forcer 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 fusion 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 l'option --abort
:
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 inférieurs à « <<<<<<<
» et sept caractères supérieurs à « >>>>>>>
», avec sept signes égal « =======
» entre eux .
- Le code au-dessus des signes égal provient de la branche dans laquelle vous fusionnez.
- 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 notez que nous utilisons la commande commit
pour le faire, pas la commande merge
.
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 ajouter rot.c
statut git
git commit -m "Correction de bogue fusionnée17"
La fusion est terminée. Nous pouvons maintenant envoyer ceci à notre référentiel distant.
CONNEXION : Comment réparer, modifier ou annuler les commits Git (modification de l'historique de 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.
CONNEXION : Devriez-vous utiliser un client GUI Git ?