Git merge : fusionner votre branche avec la branche master !

Lorsque nous travaillons avec une sorte de workflow dans Git, comme Git flow, par exemple, nous finissons par créer plusieurs branches à partir de la branche principale et nous devrons les fusionner lorsque les nouvelles branches seront terminées. La commande git merge aide à cette tâche de joindre les branches.

Au fil du temps, nous pouvons rencontrer des problèmes lors de la fusion de branches, l’un des principaux étant l’occasion où deux développeurs modifient le même fichier et finissent par créer un conflit entre les branches.

De cette façon, nous verrons les alternatives possibles pour la résolution des conflits, les moyens alternatifs pour unifier les branches et bien plus encore ! Suivez le contenu :

  • Qu’est-ce que la fusion Git et comment fonctionne-t-elle ?
  • Quelles sont les différences entre Git merge et Git rebase et quand les utiliser ?
  • Quelles sont les stratégies de fusion pour la fusion Git ?
  • Comment préparer les branches pour la fusion ?
  • Fusion de Git : faire la fusion en pratique
  • Comment trouver les conflits pendant la fusion ?
  • Options à utiliser avec la fusion Git

Qu’est-ce que la fusion Git et comment fonctionne-t-elle ?

Git merge est la commande qui unifie certains historiques forked. En bref, la fusion Git vous permet de prendre les lignes créées depuis la branche Git et fusionner dans la branche principale. Il est important de noter que la commande git branch crée une nouvelle branche à partir de la branche où se trouve le développeur.

Il convient également de noter que la fusion est toujours effectuée à l’aide de la commande Git checkout, car la modification sera effectuée uniquement dans la branche principale et la nouvelle branche ne change pas. Par exemple, nous échangeons des branches avec Git checkout et, juste après, nous faisons le fusionner De la nouvelle bifurcation à la branche principale.

La fusion Git fonctionne en combinant plusieurs séquences de commits en un historique unifié. Il est largement utilisé pour fusionner deux branches. Ainsi, l’algorithme de l’outil prend la fin de chaque branche et trouve le commit de base commun. A partir de là, il crée un commit de cette fusion qui combine les changements de chaque séquence de commit.

Disons que notre nouvelle branche est basée sur la branche branche principale. Maintenant, nous voulons unifier la nouvelle fonctionnalité dans la branche principale.

Exemplification du fonctionnement de la fusion des branches

En exécutant la commande, nous avons la fusion de la branche avec la nouvelle fonctionnalité à la branche actuelle que nous supposerons être la principale. Git choisit automatiquement l’algorithme qui sera utilisé pour cette opération.

Exemplification du fonctionnement de la fusion des branches à la fin.

Le commit de fusion finit par devenir unique avec cette opération. Lors de la création du commit de fusion, Git essaie automatiquement de fusionner l’historique des commits pour vous faciliter la vie. Si Git trouve des données modifiées dans l’historique des deux commits, il ne sera pas en mesure d’effectuer cette opération automatiquement. Ce scénario est appelé conflit de version de code et Git demandera une intervention de l’utilisateur pour continuer l’unification.

Quelles sont les différences entre Git merge et Git rebase et quand les utiliser ?

La fusion Git se fait entre deux branches et le résultat est un nouveau commit avec toutes les modifications faites dans la nouvelle branche. Git rebase effectue une unification des branches en une seule, afin d’obtenir un historique de commit plus propre.

Différences entre git merge et git rebase

L’un des principaux inconvénients du rebasement est la façon dont il modifie la structure des branches impliquées, finissant par réécrire même leur historique de livraison, ce qui peut même entraîner la perte de travail pendant le processus de fusion. Nous ne pouvons pas non plus savoir quand la fusion a été effectuée, puisque le rebasement ne génère pas de commit de fusion.

Selon le flux de travail Git, nous avons une règle appelée « Golden Rule of Rebase » qui nous dit essentiellement de ne pas rebaser sur les branches publiques, car en plus d’être une opération dangereuse, nous finissons par perdre l’historique des commits, ce qui entraîne des décalages entre les branches locales et distantes. Cependant, il est possible d’utiliser les deux commandes de manière efficace dans un flux de travail.

À partir de la branche principale de votre référentiel, nous créons une branche d’une nouvelle fonctionnalité. Dans celui-ci, nous générons quelques changements et ajoutons une nouvelle branche en utilisant Git Commit. Peu de temps après, nous devons fusionner les branches et, pour cela, nous devons effectuer deux étapes : la première consiste à fusionner les modifications apportées dans le master dans notre branche, puis à fusionner la fonctionnalité dans la branche principale.

En analysant calmement, nous pouvons voir que cela n’a pas de sens de créer un commit de fusion dans cette action, il serait beaucoup plus propre si nous pouvions simplement apporter les changements du master à notre branche. Dans cette optique, en utilisant rebase, cette possibilité devient viable. En exécutant la commande ci-dessous, nous faisons effectuer cette opération par Git.



git rebase master

À partir de là, nous devons maintenant procéder à l’unification de la fonctionnalité dans la branche principale, puisque nous avons pris soin des éventuels problèmes de conflits de fichiers et que nous avons pu fusionner les branches de manière simple avec Git merge, créant ainsi un nouveau commit de fusion qui nous sert d’historique de fusion de branche.

De cette façon, nous avons pu utiliser le meilleur des deux mondes pour améliorer notre flux de travail avec l’outil !

Quelles sont les stratégies de fusion pour la fusion Git ?

Git a plusieurs méthodes différentes pour trouver le commit commun d’une fusion. Ces méthodes sont généralement appelées « stratégies de fusion« . Par défaut, la fusion Git choisit par lui-même sa stratégie de fusion, la même chose se produisant avec la commande pull de Git.

Pour choisir une stratégie, le paramètre -s doit être transmis avec le nom de la stratégie. Nous pouvons voir ci-dessous les stratégies de fusion disponibles :

Récursif



git merge -s recursive branch1 branch2

Elle n’exploite que deux branches à la fois, c’est la stratégie par défaut utilisée lors de la fusion et au moment du pull de Git. Il peut également détecter les fusions impliquant des renommages, mais ne peut pas utiliser les copies détectées.

Cette stratégie peut contenir les options suivantes :

  • le nôtre
  • les leurs
  • patient
  • diff-algorithme=[patience|minimal|histogram|myers]
  • renormaliser
  • pas de normalisation
  • sans renommage
  • trouver-renommer[=<n>]
  • sous-arbre[=<caminho>]

Résolvez



git merge -s resolve branch1 branch2

Il ne peut résoudre que les unifications à 2 branches et utilise un algorithme de fusion à 3 voies. Elle tente soigneusement de détecter les ambiguïtés de la fusion croisée, et est également considérée comme la stratégie la plus rapide et la plus sûre.

Pieuvre



git merge -s octopus branch1 branch2 branch3 branchN

C’est la stratégie par défaut pour les fusions avec plus de 2 branches. Comme pour les autres stratégies, si un conflit survient, Octopus refuse de fusionner. Il est souvent utilisé pour regrouper des branches similaires.

Le nôtre



git merge -s ours branch1 branch2 branchN

Le nôtre traite un nombre varié de branches. Le résultat final est toujours la fin de la branche principale, ignorant le changement de toutes les autres branches. Il doit être utilisé pour remplacer l’ancien historique de développement des branches latérales.

Sous-arbre



git merge -s subtree branchA branchB

Il s’agit d’une amplification de la stratégie récursive. Lors de la fusion de la branche A avec la branche B, si B est un sous-arbre enfant de A, B sera d’abord mis à jour pour refléter l’arborescence de A. Ce renouvellement se produit également dans l’arbre ancêtre commun entre les deux branches.

Comment préparer les branches pour la fusion ?

Avant d’effectuer une fusion, nous devons nous assurer que l’unification se fait correctement à travers quelques étapes.

Confirmez que la branche de réception est correcte

Pour effectuer la confirmation, exécutez la commande git status. Vous obtiendrez ainsi la branche qui vous est attribuée. Si vous en avez besoin, exécutez git checkout pour changer de branche. Pour notre cas, nous pouvons exécuter git checkout main, par exemple.

Vérifiez si les branches sont à jour avec les derniers commits.

Tout d’abord, nous devons vérifier si les branches que nous allons fusionner sont avec les commits distants les plus récents. Pour ce faire, exécutez la commande Récupérer gitqui récupérera les informations à distance de toutes les branches. Une fois la récupération terminée, lancez la commande git pull si nécessaire.

Fusion de Git : faire la fusion en pratique

Après avoir préparé les branches, nous pouvons maintenant lancer le programme action de fusion de la commande Git merge, en n’oubliant pas d’utiliser le nom de la branche qui sera fusionnée à partir de la branche réceptrice.

Fusion en avance rapide

Une fusion rapide se produit lorsqu’il existe un chemin linéaire entre l’extrémité de la branche actuelle et la branche que nous voulons fusionner. Ainsi, au lieu de fusionner les branches, Git déplace simplement l’extrémité de la branche actuelle vers l’extrémité de la branche que nous choisissons.

C’est ce qu’on appelle « avance rapide », en portugais « avance rapide« . De cette façon, les historiques sont efficacement unifiés, puisque les commits de la branche désirée sont présents dans la branche courante.

Fusion git rapide

Fusion à trois voies

La fusion à trois se produit lorsque la branche principale progresse pendant que la nouvelle branche est en cours de développement. De cette façon, Git ne peut pas avancer rapidement dans les branches et finit par devoir effectuer une fusion classique, créant finalement le commit de fusion. Ce scénario est très courant dans les équipes de développement, car il peut y avoir beaucoup de changements dans la branche principale.

Comment trouver les conflits pendant la fusion ?

Lorsqu’un conflit survient entre deux ou plusieurs branches, Git demande au développeur ou à la développeuse d’intervenir pour apporter un correctif aux versions qui seront utilisées.

Comment résoudre les conflits ?

La présentation des conflits dépendra de chaque machine. Si vous ne modifiez pas la configuration du programme de fusion dans Git config, le fichier apparaîtra probablement dans le terminal avec le fichier Vim. Donc, pour résoudre les conflits, vous devez regarder dans les fichiers qui sont listés comme étant en conflit pour les marquages numériques : <<<<<&lt ;, =======, et >>>>>>. En voici un exemple :



Aqui vai algum conteúdo que não foi afetado pelo conflito

<<<<<<< main Esse é algum texto conflituoso da branch main
=======Esse é algum texto conflituoso da branch com a funcionalidade
>>>>>>> branch da funcionalidade;

Enfin, vous pouvez résoudre le conflit de la meilleure façon que vous puissiez trouver. Il convient de noter que les conflits ne se produisent que dans les fusions à trois voiesles changements conflictuels ne peuvent pas se produire dans les fusions rapides.

Options à utiliser avec la fusion Git

Nous allons maintenant voir quelques options utiles lors de la fusion des branches, pour une liste complète, consultez la documentation officielle de Git.

Création de commits en avance rapide : -no-ff



git merge main --no-ff

Cette commande est destinée à créer un nouvel engagement même lorsque l’avance rapide est possible.

Arrêt des conflits : -abort



git merge main --abort

Si un conflit survient entre les branches, cette option va abandonner la fusion et restaurer l’état du projet avant la fusion.

Modification du commit de fusion : -no-commit



git merge main --no-commit

Dans cette option, nous avons la possibilité de éditer le commit de fusion avant qu’il ne soit ajouté à l’historique. N’oubliez pas que l’avance rapide ne crée pas de commits de fusion. Dans ce cas, utilisez l’option -no-ff en même temps que -no-commit.

Nous comprenons comment se fait la fusion de branches Git Merge, ses stratégies, ses particularités et ses options. De cette façon, nous nous rendons compte que cette commande est extrêmement utile pour aider les flux de travail individuels et nous pourrons, avec peu de commandes, unifier autant de branches que nécessaire et faire avancer facilement une branche rapidement sans avoir besoin de créer un commit de fusion.

Nous avons également vu comment les conflits de HTML, CSS, Javascript ou tout autre type de données fonctionnent et comment Git merge se comporte dans ces cas. Pour finir, il ne faut pas oublier les options que, comme toute autre commande Git, nous avons à notre disposition, nous pouvons annuler l’avance rapide, éditer les commits avant les fusions et même interrompre la fusion lorsqu’un conflit quelconque se produit.

Vous avez aimé l’article ? Continuez à lire les 10 commandes Git que tout progéniteur doit connaître !