Discussion :

[Whaouu]

Bonjour,
Je suis très loin d'être un bon pratiquant de Git et j'éprouve des difficultés à gérer correctement les conflits quand j'effectue un git pull origin master.

Pourriez-vous m'indiquer la méthode la plus simple pour y arriver ?
Merci par avance pour vos conseils.

[Obsidian]

Bonjour,

En premier lieu, dans l'expression git pull origin master, master est une « refspec » : https://git-scm.com/book/fr/v2/Les-t...Git-La-refspec

Une refspec est une expression qui te permet d'indiquer en une seule fois quelle est la source, l'éventuelle destination si elle n'est pas implicite, et un «+ » optionnel qui permet de commander l'opération même s'il ne s'agit pas d'une « avance rapide » (donc rapatriement avec fusion).

Dans la situation présente, cela veut dire que tu essaies de récupérer le contenu de la branche « master » située sur le serveur et de la fusionner avec ta branche locale courante, laquelle n'est pas forcément master. La manière normale de faire lorsque tu travailles sur une branche déjà configurée pour suivre une branche distante (ce qui est le cas lorsque tu as récupéré ton dépôt avec git clone) est d'utiliser git pull seul. Vérifie donc déjà avec git branch que tu te trouves bien sur la branche master de ton côté lorsque tu appelles cette commande.

On considère à présent que tu sais pourquoi il y a un conflit (si ce n'est pas le cas, fais-le nous savoir).
Git va donc bien essayer de fusionner les branches locales et distantes pour les faire redevenir identiques.

• Si les modifications apportées d'un côté et l'autre ne se chevauchent pas, alors c'est automatique et Git ne t'embêtera pas avec ;
• Si, en revanche, elles s'appliquent sur le même fichier au même endroit, alors Git va te demander de choisir le contenu qu'il faut retenir.

Dans cette dernière situation, Git va en fait altérer le contenu du fichier concerné sans l'enregistrer, comme si c'était toi qui l'avait directement modifié (donc visible avec git diff et git status). Dans la section du fichier où se trouve le conflit, tu vas trouver un bloc directement rédigé comme suit :

Code source :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
<<<<<<<

Modifications effectuées en local

=======

Modifications effectuées sur la branche distante

>>>>>>>

Ce bloc est inséré comme s'il s'agissait de modifications ordinaires. Il te suffit donc de remplacer la totalité de ce bloc (marqueurs <<<<<<< et >>>>>>>) parce ce qui, selon toi, devrait s'y trouver une fois la résolution effectuée. Tu peux en reprendre le contenu, soit celui de la première partie, soit celui de la seconde, soit un mélange des deux, soit encore quelque chose de complètement différent si tu es sûr de toi.

Lorsque c'est fait, tu résous tous les autres blocs de la même façon puis tu ajoutes simplement ton fichier avec git add comme tu le ferais normalement et tu commites.

À ce stade, la seule différence avec un commit ordinaire est le fait que Git sait que tu es en train de résoudre un conflit et te fais donc confiance si tu lui dis qu'il est résolu. Il pourra donc le déclarer comme étant la fusion des deux branches distinctes, qui seront donc redevenues identiques. Ce commit de fusion aura alors deux « parents », l'un d'eux étant ton dernier commit local, l'autre étant le dernier commit distant.

Tu peux alors pousser l'état de ta branche sur le serveur avec git push. Celui-ci l'acceptera car le commit de fusion aura bien pour parent (l'un des deux) le dernier commit en date sur la branche de son côté et il pourra alors directement le mettre à jour.

[Whaouu]

Bonjour Obsidian,

Merci pour ta réponse. Je vois que je n'ai pas assez donné de détails sur mon problème.

Pour le moment, j'effectue un test de "Git Extensions" dans le but de faire un POC. Le but de la démonstration est de :

• Créer une branche de travail qui est basée sur le master.
• Travailler sur la nouvelle branche. Y faire des commits/push.
• Mettre à jour la branche de travail avec les dernières modifications de la branche "master" afin de régler d'éventuels conflits avant de pousser les fichiers de la branche de travail vers le master.
• Après résolution des conflits, pousser les modifications de la branche de travail vers le master.
• Supprimer la branche de travail.

J'ai effectué quelques tests en ligne de commande. Ce n'est peut-être pas très optimisé, mais j'obtiens le résultat recherché :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
Création d’une branche basée sur master et positionnement sur la nouvelle branche :
git checkout master
git branch 23_02_2024
git checkout 23_02_2024

L’utilisateur met à jour les fichiers sur la nouvelle branche. Il les envoie sur le GIT suivi d’un commit / push dans la branche “23_02_2024” :
git add .
git commit -m "BR17"
git push origin 23_02_2024

Mise à jour de la branche locale “23_02_2024” avec les dernières modifications de la branche “master” :
git fetch origin master
git merge origin/master

Résolution de conflit :
git status
# Modifier le(s) fichier(s) pour résoudre le conflit
git add .
git commit -m "Résolution des conflits"

Mise à jour de la branche master et synchronisation avec “23_02_2024” :
git checkout master
git pull
git checkout 23_02_2024
git fetch origin master
git merge origin/master
git push origin 23_02_2024

Fusion de la branche locale vers master :
git checkout master
git merge 23_02_2024
git push origin master

Je voudrais refaire ces opérations via l'interface de Git Extensions et là, je me perds dans les menus, les options, etc.

J'aurais besoin d'un bon connaisseur de Git Extension qui puisse me guider pas à pas dans les étapes pour obtenir le même résultat qu'en ligne de commande.

J'espère que ma requête est plus explicite.