@@ -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 :
...
...
@@ -742,4 +742,13 @@ Une autre ligne de texte
La situation résultante est illustrée ci-dessous :
### 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**)
