Avec le travail qui se déroule sur un projet de développement, Git est une bénédiction. Cependant, si vous avez beaucoup d’acteurs, un ou deux d’entre eux se marcheront sur les pieds. Pour votre projet, cela signifie que deux développeurs peuvent travailler sur la même suite de code et qu’ils peuvent tous deux faire des commits. Dans ce cas, vous devez mettre en place des stratégies de fusion Git pour résoudre le conflit.
Bien qu’une fusion Git puisse être simple, il y a souvent d’autres cas où vous avez besoin d’une approche avancée. Vous utiliserez alors des stratégies telles que la fusion récursive, la fusion à trois, et bien d’autres encore. Il se peut même que vous ayez besoin d’annuler une fusion Git à un moment donné.
Ce tutoriel aborde quelques techniques complexes de fusion Git à ajouter à votre panoplie d’outils. En fait, nous pouvons d’abord plonger dans les bonnes choses !
Introduction aux stratégies de fusion Git
Le concept de base d’une fusion est simple : vous joignez deux branches ensemble afin de transformer plusieurs commits en un seul. Cependant, il existe un certain nombre de techniques que vous pouvez employer pour vous assurer que vous livrez et fusionnez le bon code.
Nous allons examiner quelques stratégies importantes que vous devez comprendre. Elles ne sont pas classées dans l’ordre et, à un moment donné de votre carrière de développeur, vous aurez peut-être besoin de toutes les utiliser. De plus, vous aurez besoin d’une solide compréhension des concepts de base de Git, tels que les pointeurs, les branches et les commits.
La différence entre les fusions à deux et à trois voies
Il est utile de comprendre la différence entre une fusion à deux voies et sa compagne à trois voies. La plupart des stratégies de fusion que nous allons étudier traitent de situations à trois voies. En fait, il est plus simple de parler de ce qu’est une fusion à trois. Considérez l’exemple suivant :
- Vous avez une branche principale avec plusieurs commits et une branche de fonctionnalités qui a également des commits.
- Cependant, si la branche principale effectue maintenant d’autres modifications, les deux branches vont diverger.
- En termes simples, la branche principale et la branche des fonctionnalités ont toutes deux des commits que l’autre n’a pas. Si vous les fusionnez en utilisant une approche bidirectionnelle, vous perdez un commit (probablement sur main)
- Au lieu de cela, Git va créer un nouveau commit de fusion à partir des branches main et feature actuelles.
En bref, Git va regarder trois snapshots différents pour fusionner les changements : la tête de la branche principale, la tête de la branche des fonctionnalités, et l’ancêtre commun. Ce sera le dernier commit commun à la branche principale et à la branche des fonctionnalités.
En pratique, vous n’aurez pas à vous soucier de savoir si une certaine stratégie de fusion est à deux ou à trois voies. Souvent, vous devez utiliser une stratégie indépendamment de cela. Dans tous les cas, il est utile de savoir comment Git « pense » lorsqu’il s’agit de fusionner des branches et des dépôts.
Fusion rapide
La première stratégie peut ne pas nécessiter d’action de votre part. Une fusion rapide déplace le pointeur vers le dernier commit sur main sans créer de commit supplémentaire (ce qui peut être déroutant). C’est une approche propre que de nombreux développeurs utiliseront en standard.
La technique commence avec une branche principale qui peut ou non avoir des commits. Dans ce cas, vous ouvrez une nouvelle branche, travaillez sur le code et faites des commits. À ce stade, vous devez également fusionner ces modifications avec la branche principale. Une fusion en avance rapide a une exigence à remplir :
- Vous devez vous assurer qu’aucune autre modification n’est effectuée sur la branche principale pendant que vous travaillez sur votre nouvelle branche.
Cela n’est pas toujours possible, surtout si vous travaillez dans une grande équipe. Néanmoins, si vous choisissez de fusionner vos commits avec une branche principale qui est à jour et qui n’a pas ses propres commits, cela effectuera une fusion rapide. Vous pouvez le faire de différentes manières :
git merge <branch>
git merge --ff-only
La plupart du temps, vous n’aurez pas besoin de spécifier que vous souhaitez effectuer une fusion rapide. Ce type de fusion se produit sur des projets en solo ou avec de petites équipes. Dans un environnement rapide, il s’agit d’une fusion rare. D’autres fusions sont donc plus courantes.
Fusion récursive
La fusion récursive est souvent la solution par défaut, car elle apparaît dans des situations plus courantes que les autres types de fusion. Une fusion récursive consiste à effectuer des modifications sur une branche, mais d’autres modifications sont effectuées sur la branche principale.
Lorsqu’il est temps de fusionner, Git va recourir à la récursivité sur la branche afin d’effectuer son commit définitif. Cela signifie qu’un commit de fusion aura deux parents une fois que vous l’aurez terminé.
Comme pour une fusion rapide, vous n’aurez normalement pas besoin de spécifier une fusion récursive. Cependant, vous pouvez vous assurer que Git ne choisira pas quelque chose comme une fusion rapide en utilisant les commandes et les drapeaux suivants :
git merge --no-ff
git merge -s recursive <branch1> <branch2>
La deuxième ligne utilise l’option de stratégie -s et le nommage explicite pour effectuer une fusion. Contrairement à une fusion rapide, une fusion récursive crée un commit de fusion dédié. Pour les fusions à double sens, une stratégie récursive est solide et fonctionne bien.
Ours and theirs
Une situation courante au cours du développement est celle où vous créez une nouvelle fonctionnalité au sein de votre projet qui n’obtiendra finalement pas le feu vert. Dans de nombreux cas, vous aurez beaucoup de code à fusionner qui est également co-dépendant. Une fusion « ours » est la meilleure façon de résoudre ces conflits.
Ce type de fusion peut gérer autant de branches que nécessaire et permet d’ignorer toutes les modifications sur les autres branches. C’est idéal si vous souhaitez faire le vide autour d’anciennes fonctionnalités ou de développements non désirés. Voici la commande dont vous avez besoin :
git merge -s ours <branch1> <branch2>Un merge ours signifie essentiellement que la branche actuelle contient le code de jure. Cela est lié aux fusions « theirs », qui traitent l’autre branche comme correcte. Cependant, vous devez passer une autre option de stratégie ici :
git merge -X theirs <branch2>
L’utilisation des fusions « ours » et « theirs » peut être déroutante, mais il est généralement prudent de s’en tenir aux cas d’utilisation typiques (garder tout ce qui se trouve dans la branche actuelle et jeter le reste).
Octopus
Gérer des têtes multiples – c’est-à-dire fusionner plus d’une branche dans une autre – peut être un scénario délicat pour une fusion git. Vous pourriez dire que vous avez besoin de plus de deux mains pour résoudre les conflits. C’est parfait pour une fusion octopus.
Les fusions octopus sont en quelque sorte l’opposé des fusions ours et theirs. Le cas d’utilisation typique est celui où vous voulez inclure plusieurs commits pour des fonctionnalités similaires et les fusionner en un seul. Voici comment procéder :
git merge -s octopus <branch1> <branch2>
Cependant, Git refusera une fusion octopus si vous devez faire une résolution manuelle en cours de route. Pour les résolutions automatiques, une fusion octopus sera un défaut si vous avez besoin de fusionner plusieurs branches en une seule.
Resolve
Une des façons les plus sûres de fusionner des commits, une fusion par résolution est idéale si vous avez une situation qui implique des fusions croisées. C’est aussi une méthode de résolution rapide à mettre en œuvre. Vous pouvez également l’utiliser pour des histoires de fusion plus complexes – mais seulement celles à deux têtes.
git merge -s resolve <branch1> <branch2>
Parce qu’une fusion résolue utilise un algorithme à trois voies pour travailler à la fois avec votre branche actuelle et celle dont vous vous inspirez, elle peut ne pas être aussi flexible que d’autres méthodes de fusion. Cependant, pour le travail dont vous avez besoin, la fusion par résolution est presque parfaite.
Subtree
Ce compagnon de la fusion récursive peut vous dérouter. Nous allons essayer de l’expliquer à l’aide d’un exemple clair :
- Tout d’abord, considérez deux arbres différents – X et Y. Il s’agit souvent de deux dépôts.
- Vous voulez fusionner les deux arbres en un seul.
- Si l’arbre Y correspond à l’un des sous-arbres de X, l’arbre Y est modifié pour correspondre à la structure de X.
Cela signifie qu’une fusion de sous-arbres est fantastique si vous voulez combiner plusieurs dépôts en un seul article définitif. Elle apportera également les modifications nécessaires à l’arbre « ancêtre » commun aux deux branches.
git merge -s subtree <branch1> <branch2>
En bref, une fusion subtree est ce que vous voulez si vous avez besoin de combiner deux dépôts. En fait, vous pourriez avoir du mal à comprendre quelle stratégie de fusion vous convient le mieux. Nous aborderons plus loin quelques outils qui pourraient vous aider.
Avant cela, il y a quelques conflits de fusion avancés que vous devez savoir résoudre.
Comment gérer des conflits de fusion Git plus complexes
Fusionner des branches dans Git revient à gérer des conflits et à les résoudre. Plus la taille de votre équipe et de votre projet est importante, plus les risques de conflits sont élevés. Certains d’entre eux peuvent être complexes et difficiles à résoudre.
Étant donné que les conflits peuvent consommer du temps, de l’argent et des ressources, vous devez trouver un moyen de les étouffer dans l’œuf rapidement. Dans la plupart des cas, deux développeurs travaillent sur la même suite de codes et décident tous deux de s’engager.
Cela peut signifier que vous ne serez pas en mesure de lancer la fusion en raison de modifications en attente ou que vous rencontrerez une défaillance au cours de la fusion, ce qui nécessitera une intervention manuelle. Une fois que votre répertoire de travail est « propre », vous pouvez commencer. Souvent, Git vous informera d’un conflit une fois que vous aurez commencé la fusion :
Cependant, pour plus d’informations, vous pouvez lancer un git status et voir les détails :
À partir de là, vous pouvez commencer à travailler sur les différents fichiers à l’origine du conflit. Certains des outils et des techniques dont nous parlerons plus loin vous aideront.
Abandonner et réinitialiser les fusions
Parfois, il est nécessaire d’interrompre la fusion et de repartir à zéro. En fait, les deux commandes que nous mentionnons conviennent à des situations où vous ne savez pas encore quoi faire avec un conflit.
Vous pouvez choisir d’interrompre ou de réinitialiser une fusion en cours avec les commandes suivantes :
git merge --abort
git reset
Ces deux commandes sont similaires, mais vous les utiliserez dans des circonstances différentes. Par exemple, l’abandon d’une fusion ramènera simplement la branche à l’état où elle se trouvait avant la fusion. Dans certains cas, cela ne fonctionnera pas. Par exemple, si votre répertoire de travail contient des modifications non validées, vous ne pourrez pas lancer une annulation.
Cependant, réinitialiser une fusion signifie que vous ramenez les fichiers à un état « bon » connu. Cette dernière option est à prendre en compte si Git ne parvient pas à démarrer la fusion. Notez que cette commande supprimera toutes les modifications que vous n’avez pas validées, ce qui signifie qu’il s’agit d’un acte délibéré qui nécessite une certaine attention.
Vérifier les conflits
La majorité des conflits de fusion seront simples à vérifier et à résoudre. Cependant, dans certains cas, vous aurez besoin de creuser plus profondément afin de comprendre pourquoi un conflit se produit et comment commencer à le résoudre.
Vous pouvez obtenir plus de contexte après une git merge en utilisant un checkout :
git checkout --conflict=diff3 <filename>
Cette méthode utilise la navigation typique qu’offre une extraction et crée une comparaison entre les deux fichiers qui montre le conflit de fusion :
D’un point de vue technique, cette opération permet d’extraire à nouveau le fichier et de remplacer les marqueurs de conflit. Vous pouvez effectuer cette opération plusieurs fois au cours d’une résolution. Ici, si vous passez l’argument diff3 , vous obtiendrez la version de base et les alternatives dans les versions « our » et « their ».
Notez que l’option d’argument par défaut est merge, que vous n’avez pas à spécifier à moins que vous ne changiez le style de conflit de fusion par rapport à la valeur par défaut.
Ignorer l’espace négatif
L’espace négatif et son utilisation sont un sujet de discussion courant. Certains langages de programmation utilisent différents types d’espacement, et même des développeurs individuels utilisent des formats différents.
Les espaces par rapport aux tabulations sont un champ de bataille que nous ne rejoindrons pas. Cependant, si vous avez des situations où le formatage change de l’un à l’autre en fonction du fichier et de la pratique de codage, vous pourriez rencontrer ce problème de fusion Git.
Vous saurez que c’est la raison pour laquelle la fusion a échoué parce qu’il y aura des lignes supprimées et ajoutées lorsque vous regarderez le conflit :
C’est parce que Git regarde ces lignes et considère l’espace négatif comme une modification.
Cependant, vous pouvez ajouter des arguments spécifiques à la commande git merge qui ne tiendront pas compte des espaces négatifs dans les fichiers concernés :
git merge -Xignore-all-space
git merge -Xignore-space-change
Bien que ces deux arguments semblent similaires, ils présentent une différence unique. Si vous choisissez d’ignorer tous les espaces négatifs, Git le fera. Il s’agit d’une approche générale, mais à l’inverse, -Xignore-space-change ne considérera comme équivalentes que les séquences d’un ou plusieurs caractères à espacement négatif. Ainsi, il ignorera les espaces simples en fin de ligne.
Pour plus de sécurité, vous pouvez également revoir la fusion en utilisant la commande --no-commit, afin de vérifier que vous ignorez et comptez les espaces négatifs de la bonne manière.
Fusionner les journaux
La journalisation est cruciale pour presque tous les logiciels qui transmettent des données. Pour Git, vous pouvez utiliser le journal pour obtenir plus de détails sur un conflit de fusion. Vous pouvez accéder à ces informations en utilisant git log:
Il s’agit essentiellement d’une station de vidage de fichier texte pour chaque action au sein d’un dépôt. Cependant, vous pouvez ajouter des arguments supplémentaires pour affiner la vue et ne voir que les commits que vous souhaitez :
git log --oneline --left-right <branch1>...<branch2>
Ceci utilise un « Triple Dot » pour fournir une liste des commits impliqués dans deux branches pendant une fusion. Il filtrera tous les commits que les deux branches partagent, ce qui laissera une sélection de commits à examiner plus en détail.
Vous pouvez également utiliser git log --oneline --left-right --merge pour n’afficher que les commits de part et d’autre d’une fusion qui « touchent » un fichier conflictuel. L’option -p vous montrera les changements exacts pour un « diff » spécifique, mais notez que cela ne concerne que les commits non fusionnés. Il existe une solution de contournement à ce problème, que nous aborderons plus loin.
Utiliser le format de diff combiné pour enquêter sur un conflit de fusion Git
Vous pouvez utiliser la vue que vous obtenez avec git log pour examiner les conflits de fusion. Dans des circonstances typiques, Git fusionne le code et met en scène tout ce qui réussit. Cela vous laissera seulement les lignes conflictuelles, et vous pouvez les voir en utilisant la commande git diff:
Ce format de « diff combiné » ajoute deux colonnes d’informations supplémentaires. La première vous indique si une ligne est différente entre votre branche (« ours ») et la copie de travail ; la seconde vous donne la même information pour la branche « theirs ».
En ce qui concerne les signes, un signe plus indique qu’une ligne est ajoutée à la copie de travail mais pas dans ce côté spécifique de la fusion, et un signe moins indique que la ligne est supprimée.
Notez que vous pouvez également voir ce format de diff combiné dans le journal de Git en utilisant quelques commandes :
git show
git log --cc -p
La première est une commande que vous utilisez sur un commit de fusion pour voir son historique. La seconde commande utilise la fonctionnalité de -p pour afficher les modifications d’un commit non fusionné à côté du format de diff combiné.
Comment annuler une fusion Git
Des erreurs peuvent survenir, et vous pouvez effectuer des fusions sur lesquelles vous devez revenir. Dans certains cas, vous pouvez simplement modifier le commit le plus récent en utilisant git commit --amend. Cela ouvrira l’éditeur pour vous permettre de modifier le dernier message de commit.
Bien que vous puissiez revenir sur des conflits de fusion plus complexes et sur les modifications qui en résultent, cela peut s’avérer difficile car les livraisons sont souvent permanentes.
Il y a donc de nombreuses étapes à suivre :
- Tout d’abord, vous devez examiner les commits et trouver les références aux fusions dont vous avez besoin.
- Ensuite, vérifiez les branches pour examiner l’historique des commits.
- Une fois que vous avez connaissance des branches et des commits dont vous avez besoin, il existe des commandes Git spécifiques en fonction de l’action souhaitée.
Examinons-les plus en détail et commençons par le processus de révision. Ensuite, nous vous montrerons un moyen rapide d’annuler une fusion Git, puis nous examinerons des commandes spécifiques pour des cas d’utilisation plus avancés.
Réviser les commits
La commande git log --oneline est très utile si vous souhaitez voir les identifiants de révision et les messages de commits relatifs à la branche courante :
La commande git log --branches=* vous montrera les mêmes informations mais pour toutes les branches. Quoi qu’il en soit, vous pouvez utiliser les ID de référence à côté de git checkout pour créer un état « detached » HEAD. Cela signifie que vous ne travaillerez sur aucune branche d’un point de vue technique, et qu’une fois que vous revenez sur une branche établie, vous « orphan » les modifications.
En tant que tel, vous pouvez utiliser le checkout presque comme un bac à sable sans risque. Cependant, si vous souhaitez conserver les modifications, vous pouvez extraire la branche et lui donner un nouveau nom à l’aide de git checkout -b <branch-name>. C’est une bonne façon d’annuler une fusion Git, mais il y a des façons plus nuancées de le faire pour des cas d’utilisation avancés.
Utiliser git reset
La plupart de vos conflits de fusion peuvent se produire sur un dépôt local. Dans ce cas, git reset est la commande dont vous avez besoin. Cependant, cette commande a plus de paramètres et d’arguments à connaître. Voici comment utiliser cette commande en pratique :
git reset --hard <reference>
La première partie de cette commande – git reset --hard – comporte trois étapes :
- Elle déplace la branche de référence à son emplacement avant le commit de fusion.
- La réinitialisation matérielle fait ressembler l’index (c’est-à-dire le prochain instantané de validation proposé) à la branche de référence.
- Elle fait en sorte que le répertoire de travail ressemble à l’index.
Lorsque vous invoquez cette commande, l’historique des livraisons supprime les commits ultérieurs et réinitialise l’historique à l’ID de référence. C’est une manière propre d’annuler une fusion Git, mais elle n’est pas adaptée à tous les cas.
Par exemple, vous provoquerez une erreur si vous essayez de pousser un commit local réinitialisé vers un dépôt distant contenant ce commit. Dans ce cas, vous pouvez utiliser une autre commande.
Utiliser git revert
Bien que les commandes git reset et git revert semblent similaires, il existe des différences importantes. Dans les exemples précédents, le processus d’annulation consiste à déplacer les pointeurs de référence et HEAD vers un commit spécifique. C’est un peu comme mélanger des cartes à jouer pour créer un nouvel ordre.
À l’inverse, git revert crée un nouveau commit basé sur les modifications du backtracking, puis met à jour les pointeurs de référence et fait de la branche le nouveau « tip ». C’est aussi la raison pour laquelle vous devriez utiliser cette commande pour les conflits de fusion de dépôt distant.
Vous pouvez utiliser git revert <reference> pour annuler une fusion Git. Notez que vous devez toujours spécifier une référence de commit, sinon la commande ne fonctionnera pas. Vous pouvez également passer HEAD à la commande pour revenir au dernier commit.
Cependant, vous pouvez donner à Git plus de clarté sur ce que vous voulez faire :
git revert -m 1 <reference>
Lorsque vous invoquez la fusion, le nouveau commit aura deux « parents » L’un est lié à la référence que vous avez spécifiée, et l’autre est l’extrémité de la branche que vous voulez fusionner. Dans ce cas, -m 1 indique à Git de conserver le premier parent – c’est-à-dire la référence spécifiée – en tant que « ligne principale ».
L’option par défaut pour git revert est -e ou --edit, ce qui ouvrira l’éditeur afin de modifier le message de commit avant de revenir en arrière. Cependant, vous pouvez également passer --no-edit, ce qui n’ouvrira pas l’éditeur.
Vous pouvez également passer -n ou --no-commit, ce qui indique à git revert de ne pas créer un nouveau commit, mais d' »inverser les modifications et de les ajouter à l’index staging et au répertoire de travail.
La différence entre la fusion et le rebasage dans Git
Au lieu d’utiliser la commande git merge, vous pouvez également utiliser git rebase. Il s’agit également d’un moyen d’intégrer des modifications dans un répertoire, mais avec une différence :
- Une fusion à trois voies est utilisée par défaut lorsque vous utilisez
git merge. Elle combine des instantanés de deux branches actuelles et les fusionne avec un ancêtre commun aux deux branches pour créer un nouveau commit. - Le rebasage consiste à prendre une modification corrigée d’une branche divergente et à l’appliquer à une autre, sans avoir besoin de l’ancêtre. Cela signifie qu’il n’y aura pas de nouveau commit.
Pour utiliser cette commande, passez à la branche sur laquelle vous souhaitez effectuer un rebasage. De là, vous pouvez utiliser la commande suivante :
git rebase -i <reference>
Dans de nombreuses situations, votre référence sera votre branche principale. L’option -i lance un « rebasage interactif » Cela vous donne la possibilité de modifier les commits au fur et à mesure qu’ils sont transférés. Vous pouvez utiliser cette option pour nettoyer l’historique des commits, ce qui est l’un des grands avantages de l’utilisation de git rebase.
L’exécution de la commande affichera une liste de commits potentiels à déplacer dans l’éditeur. Cela vous permet de modifier l’apparence de l’historique des commits. Vous pouvez également fusionner des commits si vous remplacez la commande pick par fixup. Une fois que vous aurez sauvegardé vos modifications, Git effectuera le rebasage.
Dans l’ensemble, vous utilisez Git merge pour de nombreux conflits. Cependant, le rebasage présente également de nombreux avantages. Par exemple, alors que la fusion est simple à utiliser et vous permet de préserver le contexte entourant votre historique de fusion, le rebasage peut être plus propre car vous pouvez simplifier l’historique de vos commits en un seul.
Malgré cela, vous devez être plus prudent avec le rebasage, car le potentiel d’erreurs est énorme. De plus, vous ne devriez pas utiliser cette technique sur des branches publiques, car le rebasage n’affectera que votre dépôt. Pour corriger les problèmes résultants, vous devrez faire encore plus de fusions et vous verrez plusieurs commits.
Outils qui vous aident à mieux gérer une fusion Git
Compte tenu de la complexité des conflits de fusion Git, vous pouvez avoir besoin d’un coup de main. Il existe de nombreux outils disponibles pour vous aider à réaliser une fusion réussie, et si vous utilisez Intellij IDEA, vous disposez d’une méthode intégrée en utilisant le menu Branches :
VSCode inclut également une fonctionnalité similaire dans son interface utilisateur (UI). Les anciens utilisateurs d’Atom constateront que Microsoft a poursuivi sa fantastique intégration de Git, avec la possibilité de se connecter à GitHub sans autres extensions ou modules.
Vous disposez également d’autres options grâce à la palette de commandes. C’est également le cas dans les éditeurs qui s’appuient sur le framework open source de VSCode, comme Onivim2 :
L’avantage ici, comme pour tous les outils de cette liste, est que vous n’avez pas besoin de la ligne de commande pour effectuer des fusions. Vous devez généralement sélectionner une branche source et une branche cible dans un menu déroulant, puis laisser l’éditeur effectuer la fusion. Cependant, vous n’êtes pas obligé d’adopter une approche non interventionniste. Vous pouvez examiner les modifications après coup, puis effectuer la validation dont vous avez besoin.
Sublime Text est un éditeur qui propose une interface graphique distincte pour travailler avec Git. Si vous utilisez cet éditeur, Sublime Merge pourrait être un ajout idéal à votre flux de travail :
Quel que soit votre choix d’éditeur de code, il inclut souvent la possibilité de travailler avec Git sans utiliser la ligne de commande. C’est même le cas avec Vim et Neovim, en utilisant l’extension Git Fugitive de Tim Pope, qui est fantastique et simple à utiliser.
Cependant, il existe quelques outils de fusion tiers dédiés qui se concentrent uniquement sur cette tâche.
Applications dédiées à la fusion Git
Par exemple, Mergify est un moyen de fusionner du code au niveau de l’entreprise qui s’intègre dans votre pipeline et votre flux de travail d’intégration continue et de livraison continue (CI/CD) :
Certaines de ses fonctionnalités vous permettent d’automatiser la mise à jour de vos pull requests avant la fusion, de les réorganiser en fonction de leur priorité et de les mettre en lots. Pour une solution open source, Meld pourrait être utile :
Sa version stable est compatible avec Windows et Linux et fonctionne sous licence GPL. Elle vous offre des fonctionnalités de base pour comparer les branches, modifier vos fusions, etc. Vous bénéficiez même de comparaisons à deux ou trois voies et de la prise en charge d’autres systèmes de contrôle de version tels que Subversion.
Résumé
Git est un outil essentiel pour collaborer et gérer efficacement les modifications de code. Cependant, si plusieurs développeurs travaillent sur le même code, des conflits peuvent survenir. Les stratégies de fusion de Git vous aideront à résoudre ces conflits, et il existe de nombreuses façons de le faire. Pour des stratégies de fusion Git plus complexes, vous devez vous tourner vers des tactiques avancées.
Cela peut même être aussi simple que d’ignorer les espaces négatifs ou de parcourir les journaux de recherche. Cependant, vous n’êtes pas toujours obligé d’utiliser la ligne de commande. Il existe de nombreuses applications pour vous aider, et votre éditeur de code utilise souvent une interface intégrée.
Si vous souhaitez bénéficier d’un hébergement d’applications de haute qualité, nous avons ce qu’il vous faut. Nos services d’hébergement d’applications basés sur le cloud garantissent que votre application complète est prête en un rien de temps.
Laquelle de ces stratégies de fusion Git vous permettra de vous sortir d’un mauvais pas ? Faites-nous en part dans la section des commentaires ci-dessous !
Laisser un commentaire