À cette étape :
Vous modifiez le fichier index.html, en sachant que votre collègue a déjà apporté des modifications (que vous avez récupérées).
État actuel du fichier
Après git pull, le fichier index.html contient :
Contenu actuel :
<h1>Welcome to our awesome website</h1>
Votre modification :
<h1>Bienvenue sur notre site web incroyable</h1>
mon-site-web/
index.html (M)
about.html (non
modifié)
services.html (non
modifié)
contact.html (non
modifié)
css/
style.css (non modifié)
img/
logo.png (non modifié)
banner.jpg (non
modifié)
État de Git
Zone de transit (Staging)
Vide
Dépôt local
Dernier commit local : v1.1 (synchronisé)
À cette étape:
- Vous avez ajouté vos modifications à la zone de transit
- Vous exécutez la commande
git commit -m "message" pour créer un commit
- Le commit enregistre un instantané des fichiers dans la zone de transit
- Le message décrit les changements effectués dans ce commit
- Vos modifications sont maintenant sauvegardées localement dans l'historique des commits
- Le tout est prêt pour un PUSH (ou presque...)
Commande à exécuter
git commit -m "Modification de la page d'accueil"
Aperçu des changements
--- a/index.html
+++ b/index.html
@@ -1,6 +1,6 @@
-<h1>Welcome to my website</h1>
+<h1>Bienvenue sur mon site web</h1>
<p>Ceci est notre site web.</p>
</body>
</html>
Arborescence du projet
mon-site-web/
index.html committed
about.html (non
modifié)
services.html (non
modifié)
contact.html (non
modifié)
css/
style.css (non modifié)
img/
logo.png (non modifié)
banner.jpg (non
modifié)
État de Git
Dépôt propre
Les modifications ont été commitées. Prêt pour un push.
Ce qui se passe :
Le push échoue car le dépôt distant contient des
modifications que vous ne possédez pas localement.
- Vous exécutez
git push
- Git détecte que le dépôt distant a une version plus récente du même fichier
- Git refuse d'accepter le push pour éviter de perdre les modifications de votre collègue
- Le push échoue avec un message d'erreur
Message d'erreur typique
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
État de la synchronisation
Dépôt local
Commit v1.1 (votre modification)
Dépôt distant (serveur)
Commit v1.1 (du collègue) - DIFFÉRENT !
⚠️ CONFLIT : Les deux versions
modifient le même fichier à la même ligne !
Erreur commune : Ne pas vérifier le statut du dépôt distant avant de faire
un push !
Ce qui se passe :
Vous devez maintenant exécuter git pull pour récupérer les modifications du
serveur et résoudre le conflit.
- Git télécharge la version du serveur
- Git détecte que vous avez modifié le même fichier à la même ligne
- Git marque le fichier comme ayant un conflit de fusion (merge conflict)
- Vous devrez manuellement choisir quelle version garder
Commande à exécuter
git pull
Conflit dans le fichier
Git ajoute des marqueurs de conflit dans le fichier :
<h1>
<<<<<<< HEAD
Bienvenue sur mon site web
=======
Welcome to our awesome website
>>>>>>> origin/main
</h1>
Apperçu de la fenêtre de gestion de conflit Vs Code
Explication :
<<<<<<< HEAD et >>>>>> origin/main sont des
marqueurs
ajoutés par Git pour indiquer les sections en conflit======= est un séparateur qui sépare les deux versions en conflit
Résolution du conflit
Lorsqu'il y a un conflit de fusion, vous devez absolument choisir une des 3 options suivante :
- Option 1 : Garder votre version (Accepter la version actuelle)
- Option 2 : Garder la version du serveur (Accepter la version entrante)
- Option 3 : Fusionner les deux versions manuellement
Option 1 : Garder votre version
Vous acceptez VOTRE version locale du fichier. Ceci fera en sorte de conserver vos modifications et impactera le prochain commit.
Option 2 : Garder la version du serveur
Vous acceptez la version du serveur. Ceci fera en sorte de
remplacer vos modifications locales par celles du serveur et impactera le prochain commit, ainsi que votre version locale.
Option 3 : Fusionner les deux
Vous fusionnez manuellement les deux versions en modifiant le fichier. Ceci fera en sorte de créer une nouvelle version fusionnée qui sera utilisée dans le prochain commit.
Une fusion est possible lorsque les modifications ne se chevauchent pas directement dans le fichier (elles ne sont pas sur les mêmes lignes de code)
Après avoir résolu le conflit, si vous êtes dans Vs Code, cliquez sur "Mark as Resolved" pour indiquer à Git que le conflit a été résolu. Git prépare alors le fichier pour le commit.