Options et exemples de stratégie de merge Git
Lorsqu'une tâche est terminée, testée et prête à être de nouveau mergée dans la ligne de développement principale, votre équipe doit choisir la politique à adopter. Quelles sont les options de stratégie de merge possibles ? Dans cet article, nous étudierons les possibilités et expliquerons brièvement la méthode adoptée par Atlassian. À la fin, vous devriez disposer des outils nécessaires pour choisir les options les plus adaptées à votre équipe.
Stratégies de merge Git
Un merge se produit lorsque deux branches sont associées. Git prend deux pointeurs de commit (ou plus) et essaie de trouver un commit de base commun aux deux. Git dispose de plusieurs méthodes différentes pour rechercher un commit de base, appelées « stratégies de merge ». Dès que Git trouve un commit de base commun, il crée un « commit de merge » qui combine les changements des commits de merge spécifiés. Techniquement, le terme « commit de merge » désigne un commit normal, qui présente deux commits parent.
git merge sélectionne automatiquement une stratégie de merge, sauf indication contraire. Les commandes git merge et git pull peuvent être transmises avec l'option -s (stratégie). Cette option -s peut être ajoutée avec le nom de la stratégie de merge souhaitée. Sauf indication contraire, Git sélectionne la stratégie de merge la plus adaptée en fonction des branches fournies. Voici une liste des stratégies de merge disponibles.
Ressource connexe
Commande git log avancée
DÉCOUVRIR LA SOLUTION
Découvrir Git avec Bitbucket Cloud
Stratégie « recursive »
git merge -s recursive branch1 branch2Cette stratégie fonctionne sur deux têtes. « recursive » est la stratégie de merge par défaut lorsque vous faites un pull d'une branche ou la mergez. De plus, elle peut identifier et gérer les merges impliquant des changements de nom, mais ne peut actuellement pas utiliser les copies détectées. Il s'agit de la stratégie de merge par défaut lorsque vous faites un pull d'une branche ou la mergez.
Résolution
git merge -s resolve branch1 branch2Elle peut uniquement résoudre deux têtes à l'aide d'un algorithme de merge à trois branches. Elle s'efforce de bien détecter les quelques ambiguïtés de merge, et est généralement considérée comme sûre et rapide.
Stratégie « octopus »
git merge -s octopus branch1 branch2 branch3 branchNLa stratégie de merge par défaut pour plus de deux têtes. Lorsque plusieurs branches sont transmises, « octopus » est automatiquement utilisée. Si un merge présente des conflits qui nécessitent une résolution manuelle, « octopus » refusera la tentative de merge. Elle est principalement employée pour regrouper des têtes de branche aux fonctionnalités similaires.
Stratégie « ours »
git merge -s ours branch1 branch2 branchNLa stratégie « ours » fonctionne sur N branches. Le résultat du merge sortant est toujours celui de l'élément HEAD de la branche actuelle. Le terme « ours » implique que la préférence ignore dans les faits tous les changements provenant des autres branches. Il est utilisé pour combiner l'historique de branches aux fonctionnalités similaires.
Stratégie « subtree »
git merge -s subtree branchA branchBC'est une extension de la stratégie « recursive ». Lors du merge de A et B, si B est une sous-arborescence enfant de A, B est d'abord mise à jour pour refléter la structure d'arborescence de A. Cette mise à jour est également effectuée sur l'arborescence ancêtre commune à A et B.
Types de stratégies de merge Git
Merges explicites
Les merges explicites constituent le type de merge par défaut. Ils sont dits « explicites », car ils créent un commit de merge. Cette action modifie l'historique des commits et indique explicitement où un merge a été exécuté. Le contenu du commit de merge est également explicite dans la mesure où il montre les commits parent du commit de merge. Certaines équipes évitent les merges explicites, car les commits de merge peuvent ajouter des « interférences » à l'historique du projet.
Merge implicite via un rebase ou un fast-forward merge
Merge squash, généralement sans merge explicite
Options et exemples de stratégie de merge Git « recursive »
La stratégie « recursive » mentionnée ci-dessus dispose de son propre sous-ensemble d'options opérationnelles supplémentaires.
oursÀ ne pas confondre avec la stratégie de merge « ours ». Ce conflit d'options est résolu automatiquement en privilégiant la version « ours ». Les changements introduits par la version « theirs » sont automatiquement intégrés s'ils n'entrent pas en conflit.
theirsLe contraire de la stratégie « ours ». L'option « theirs » favorise l'arborescence de merge étranger dans la résolution des conflits.
patienceCette option consacre davantage de temps à éviter les erreurs de merge sur des lignes de correspondance sans importance. Elle doit être privilégiée lorsque les branches à merger sont extrêmement divergentes
diff-algorithimignore-*
ignore-space-change
ignore-all-space
ignore-space-at-eol
ignore-cr-at-eolUn ensemble d'options qui ciblent les caractères d'espacement. Toute ligne qui correspond au sous-ensemble de l'option transmise sera ignorée.
renormalizeCette option effectue un check-out et un check-in sur les trois arborescences Git, tout en résolvant un merge à trois branches. Elle doit être utilisée pour merger des branches ayant des états checkin et checkout différents.
no-normalizeDésactive l'option « renormalize », ce qui annule la variable de configuration merge.renormalize.
no-renamesCette option permet d'ignorer les fichiers renommés lors du merge.
find-renames=nIl s'agit d'un comportement par défaut. Le merge « recursive » assure les renommages de fichiers. Le paramètre n peut être utilisé pour transmettre un seuil de similarité de renommage. La valeur par défaut de n est de 100%.
subtreeCette option s'inspire de la stratégie « subtree ». Tandis que la stratégie « subtree » fonctionne sur deux arborescences et modifie leur correspondance sur un ancêtre commun, cette option fonctionne plutôt sur les métadonnées de chemin de l'arborescence pour les faire correspondre.
Notre politique de merge Git
Atlassian préfère nettement utiliser des merges explicites. Pourquoi ? Les merges explicites offrent tout simplement une parfaite traçabilité et un contexte sur les fonctionnalités mergées. Nous recommandons vivement de faire un rebase de nettoyage de l'historique local avant de partager une branche de fonctionnalité pour revue. Cette action ne change en rien la politique, elle l'enrichit.
Partager cet article
Thème suivant
Lectures recommandées
Ajoutez ces ressources à vos favoris pour en savoir plus sur les types d'équipes DevOps, ou pour les mises à jour continues de DevOps chez Atlassian.
Le blog Bitbucket
Parcours de formation DevOps
