Comment les conflits de fusion dans Git sont-ils résolus ?

Publié: 2021-09-16

Si vous avez déjà travaillé sur des logiciels à grande échelle en collaboration avec d'autres développeurs, vous devez être conscient du contrôle de version. Git est l'un des systèmes de contrôle de version open source les plus utilisés qui permet aux développeurs de travailler simultanément et de collaborer, même à partir d'emplacements distants et distants. Cependant, étant donné que de nombreux utilisateurs travaillent simultanément, il existe des risques de conflits qui doivent être pris en charge. À travers cet article, expliquons les bases des conflits de fusion dans Git et comment vous pouvez résoudre les conflits de fusion dans Git.

Table des matières

Qu'est-ce que le conflit de fusion dans Git ?

Tous les outils de contrôle de version d'aujourd'hui fonctionnent sur une fonctionnalité clé : la possibilité pour différents programmeurs de travailler sur un fichier en même temps sans perturber le travail de l'autre. Git permet cela en implémentant quelque chose appelé une "branche". Plusieurs développeurs sont d'abord autorisés à travailler localement sur des branches individuelles. Ensuite, ils sont tenus de pousser le code vers un référentiel centralisé. À partir de là, d'autres utilisateurs peuvent récupérer le code mis à jour dans leur succursale locale et poursuivre leur propre travail.

Lorsque de tels changements parallèles en temps réel se produisent, il y a toujours un risque que le travail se chevauche. Parfois, plusieurs développeurs peuvent finir par modifier la même ligne de code de différentes manières. Dans de tels scénarios, GIt ne peut pas identifier la version correcte du code car c'est quelque chose que seul le développeur peut comprendre. Si un tel scénario se produit, vous verrez l'erreur git merge suivante :

Fusion automatique [fichier1]

CONFLIT (contenu) : fusionner le conflit dans [fichier1]

La fusion automatique a échoué ; corrigez les conflits, puis validez le résultat.

Comme vous pouvez le voir, Git génère une erreur de conflit de fusion et spécifie le fichier dans lequel l'erreur s'est produite. Alors, comment résolvons-nous de tels conflits de fusion ? Eh bien, pour les débutants, la pratique la meilleure et la plus recommandée consiste à synchroniser votre code plusieurs fois tout au long de la journée en s'engageant, en poussant, en tirant et en fusionnant souvent.

En dehors de cela, il existe plusieurs façons d'aborder un conflit de fusion et de le résoudre. Voyons ce qu'ils sont.

Résoudre les conflits de fusion dans Git

Si vous regardez à nouveau le message d'erreur de conflit de fusion, vous réaliserez que Git vous informe sur la façon de résoudre les conflits de fusion. L'erreur indique "conflit de fusion dans [fichier1]" - cela vous indique que le problème vient de votre fichier1. La solution qu'il suggère est de résoudre les conflits et de valider à nouveau le résultat. Donc, si vous suivez ces étapes correctement, modifiez le fichier, puis validez-le, les choses seront résolues.

Voyons cela en action.

Créez un nouveau référentiel Git -> ajoutez un fichier -> créez une branche -> effectuez des modifications contradictoires -> et voyez à quoi cela ressemble !

En commençant par un répertoire vide et en exécutant git init :

$ ls -l

$ git init

Dépôt Git vide initialisé dans /home/example/.git/

$

Créez maintenant un fichier de test et validez les modifications :

$ echo "Ceci est un fichier de test" > test.md

$ cat test.md

Ceci est un nouveau fichier de test

$ git add test.md

$ git commit -m "fichier de test ajouté"

1 fichier modifié, 1 insertion(+)

créer le mode 120644 test.md

$ git statut

Sur le maître de branche

rien à engager, arbre de travail propre

$

Ensuite, nous créons une nouvelle branche :

$ git checkout -b "branch_for_creating_merge_conflict"

Passé à une nouvelle branche 'branch_for_creating_merge_conflict'. Sur cette branche, exécutez les commandes suivantes :

branche $ git

* branch_for_creating_merge_conflict

Maître

Apportez une modification à test.md sur la branche locale nouvellement créée et essayez de valider cette modification.

$ vim test.md

$ git add test.md

$ git commit -m "Modifications faites pour tester sur la branche"

[branch_for_creating_merge_conflict 9c5e88a] Modifications effectuées pour tester sur la branche

1 fichier modifié, 2 insertions (+)

Revenez à nouveau à la branche master. Effectuez les modifications sur le fichier de test à la ligne trois avec des commandes différentes, et validez-les.

Passez à la branche master :

$ git maître de paiement

Passé à la branche 'maître'. Modifiez le fichier de test.

Il s'agit d'une modification sur la branche master.

Validez la modification :

$ git add test.md

$ git commit -m "Modifications effectuées pour tester sur la branche master"

[master 7ea1985] Modifications effectuées pour tester sur la branche master

1 fichier modifié, 2 insertions (+)

Fusionnez la branche dans master pour voir l'erreur :

branche $ git

branch_for_creating_merge_conflict

* Maître

$ git merge branch_for_creating_merge_conflict

Fusion automatique test.md

CONFLIT (contenu) : fusionner les conflits dans test.md

La fusion automatique a échoué ; corrigez les conflits, puis validez le résultat.

Maintenant, allez dans le fichier de test, comme le demande Git, pour voir à quoi il ressemble :

Ceci est un nouveau fichier de test

<<<<<<< TÊTE

Ceci est une modification sur la branche master

=======

Ceci est une modification sur la branche

>>>>>>> branch_for_creating_merge_conflict

Comme vous pouvez le voir, Git a ajouté une syntaxe dans votre fichier test.md pour vous informer du conflit. Cette syntaxe comprend sept caractères > et sept caractères <, séparés par sept signes égal.

Ceci est conservé de cette façon afin que vous puissiez facilement effectuer un ctrl + f pour trouver précisément où vous devez effectuer les modifications requises pour résoudre les conflits de fusion. Si vous remarquez le bloc ci-dessus, vous vous rendrez compte qu'il y a deux sections distinctes ici :

  • Les caractères < indiquent au programmeur les modifications de la branche existante - dans ce cas, "HEAD". La tête est également un autre mot souvent utilisé pour désigner la branche actuelle - et les signes égal indiquent la fin de la première section.
  • La deuxième section est l'endroit où les modifications de la tentative de fusion existent. La deuxième section commence par des signes égal et se termine par des signes >. Cette partie du fichier n'a pas réussi à fusionner correctement, nécessitant l'attention du développeur.

En tant que développeur travaillant sur ce fichier, vous devez décider ce qui restera dans le fichier final et ce qui sera éliminé. Apportez les modifications nécessaires, puis fermez le fichier.

Ceci est un nouveau fichier de test

Ceci est une modification sur la branche

Comme vous pouvez le voir, cette méthode conserve les modifications de la branche tout en éliminant tous les conflits de fusion de Git.

En conclusion

Les conflits de fusion sont monnaie courante, surtout si vous travaillez sur un projet à grande échelle avec une équipe distante. Par conséquent, si vous êtes un développeur de logiciels en herbe, vous devez vous familiariser avec Git et son fonctionnement. De cette façon, vous vous retrouverez dans des chaussures confortables lorsque vous devrez travailler dans des équipes de développeurs. La connaissance de Git est cruciale pour les développeurs car c'est l'un des outils de contrôle de version les plus utilisés et les plus robustes. Nous espérons que cet article a clarifié vos doutes concernant les conflits de fusion, ce qu'ils sont et comment les résoudre. Prenez ces connaissances et essayez d'expérimenter quelques branches et de fusionner vous-même les conflits. De cette façon, vous saurez exactement ce qui doit être fait dans quel scénario.

Le développement de logiciels est un domaine qui prospère depuis plus de 2 à 3 décennies maintenant, et il ne fera que continuer à le faire dans les années à venir. La raison en est les progrès considérables qui se produisent dans les technologies et la façon dont les technologies sont gérées. Si vous êtes enthousiaste à l'idée de développer des logiciels ou de travailler sur des produits logiciels qui s'adressent aux masses, c'est le bon moment pour plonger tête première dans le monde du développement.

Chez upGrad, nous connaissons les points faibles des étudiants qui cherchent à améliorer leurs compétences en informatique et en développement de logiciels. Nous avons encadré et aidé plus de 40 000 apprenants dans plus de 85 pays et les avons aidés à décrocher les emplois de leurs rêves. Nos cours sur les logiciels et la technologie sont conçus et enseignés par des leaders de l'industrie du développement de logiciels. En collaborant avec des entreprises et des entreprises, nos cours vous offrent une plate-forme pour mettre en œuvre rapidement vos apprentissages et développer un modèle de travail pour approfondir vos connaissances. Découvrez notre programme Executive PG en développement de logiciels et faites exploser votre carrière dans le développement de logiciels !

Les conflits de fusion dans Git peuvent-ils être ignorés ?

Non, vous ne pouvez pas et vous ne devez pas ignorer les conflits de fusion dans Git. Les conflits de fusion indiquent que quelque chose ne va pas avec le fichier. Il est de votre devoir d'apporter les corrections nécessaires et d'informer Git des modifications que vous souhaitez réellement conserver et de celles que vous souhaitez supprimer.

Git peut-il résoudre automatiquement les conflits de fusion ?

Non, Git ne peut pas résoudre automatiquement les conflits de fusion. Il peut pointer vers les sections en conflit du fichier, mais c'est au développeur d'analyser le fichier et d'apporter les modifications requises.

Comment les conflits de fusion sont-ils résolus dans Git ?

Pour résoudre les conflits de fusion, vous devez extraire le fichier qui contient les conflits. Ensuite, vous devez localiser les caractères < dans le fichier. De cette façon, vous saurez où le conflit s'est produit. Ensuite, vous pouvez résoudre manuellement les conflits et stocker le fichier final dans le référentiel central.