Gestion-de-versions-avec-hébergement-du-dépôt-sur-un-serveur-GitLab,-les-bases.md

@@ -502,7 +502,7 @@ La situation résultante est illustrée ci-dessous :
 
 ### Synchronisation descendante, cas d'un retard simple
 
-> :bulb:Ici, on traite le cas d'un développeur auquel il ne manquerait localement que des commits produits et envoyés sur le serveur par d'autres développeurs.
+> 💡Ici, on traite le cas d'un développeur auquel il ne manquerait localement que des commits produits et envoyés sur le serveur par d'autres développeurs.
 
 #### Validation d'une modification sur le `clone 1` et synchronisation montante avec le serveur
 
@@ -695,7 +695,7 @@ La situation résultante est illustrée ci-dessous :
 
 #### Synchronisation descendante depuis le `clone 2`
 
-> 💡 La commande `git pull` permet au client git local de se **resynchroniser dans le sens descendant** avec le serveur, afin d'**obtenir (et d'intégrer à son historique local) les commits qui pourraient lui manquer**
+> :bulb: La commande `git pull` permet au client git local de se **resynchroniser dans le sens descendant** avec le serveur, afin d'**obtenir (et d'intégrer à son historique local) les commits qui pourraient lui manquer**
 
 On se synchronise dans le sens descendant avec le serveur :
 
@@ -743,3 +743,12 @@ Une autre ligne de texte
 La situation résultante est illustrée ci-dessous :
 
 ![12-multi-pull](uploads/688947d35375c9b2ab20170a6d66b834/12-multi-pull.png)
+
+### Synchronisation descendante, cas d'avance/retard sans conflit
+
+> 💡Ici, on traite le cas d'un développeur qui aurait à la fois :
+>
+> * **pris de l'avance** en produisant plusieurs commits locaux pas encore synhcronisés avec le serveur
+> * **pris du retard** en n'intégrant pas des commits produits et envoyés sur le serveur par d'autres développeurs
+>
+> Cependant, ici, on fait l'hypothèse que les modifications de ces différents commits **ne rentrent pas en conflit entre eux** (c'est à dire qu'ils n'ont **aucun fichier modifié en commun**)
\ No newline at end of file