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

@@ -220,14 +220,19 @@ MacBook-Air-749:gitlab-basics sebastienjean$ ls
 README.md	unFichier.txt
 ```
 
-On valide une nouvealle version incluant ce fichier :
+On valide une nouvelle version incluant ce fichier :
 
-```bash
+```
 MacBook-Air-749:gitlab-basics sebastienjean$ git add unFichier.txt 
 MacBook-Air-749:gitlab-basics sebastienjean$ git commit  -m "ajout d'un fichier"
 [main deebe14] ajout d'un fichier
  1 file changed, 1 insertion(+)
  create mode 100644 unFichier.txt
+```
+
+La commande `git log` indique que les pointeurs `HEAD` et `main` sont en avance d'un commit par rapport à `origin/main`, ce qui veut signifie que le dépôt local est en avance d'un commit par rapport au dépôt distant.
+
+```bash
 MacBook-Air-749:gitlab-basics sebastienjean$ git log
 commit deebe1462a849bdf6702b5d8064fcee2b479d9d6 (HEAD -> main)
 Author: sebastienjean <baz.jean@gmail.com>
@@ -242,8 +247,6 @@ Date:   Sun Jan 23 10:13:01 2022 +0000
     Initial commit
 ```
 
-On observe que les pointeurs `HEAD` et `main` sont en avance d'un commit par rapport à `origin/main`, ce qui veut signifie que le dépôt local est en avance d'un commit par rapport au dépôt distant.
-
 Ceci est confirmé par la commande `git status` :
 
 ```bash
@@ -255,6 +258,8 @@ Your branch is ahead of 'origin/main' by 1 commit.
 nothing to commit, working tree clean
 ```
 
+Cette situation peut être illustrée de la manière suivante :
+
 ![GitlabCommit](uploads/c0690f40125a56eddde4e0a91d8e7f3e/GitlabCommit.png)
 
 > :bulb: L'opération `commit` est **toujours locale**, comme illustré ci-dessus. L'observation de l'état du dépôt distant via l'URL ne montre pas de nouveau commit. :warning: **Ce commit doit être explicitement transmis au serveur**
@@ -267,20 +272,22 @@ Lors de cette opération :
 
 - le client `git` local compare l'état de la branche locale `main` et de la branche de _remote-tracking_ `origin/main`
 
-![](uploads/6ab0a5bbf04da3c3809dd78ed536970d/GitPush1.png)
+![GitLabPush1](uploads/a5825e0d65e29805b50686dfbd489924/GitLabPush1.png)
 
-- il détermine ce qui doit être transmis au serveur distant (ici, le commit `1`)
+- il détermine ce qui doit être transmis au serveur distant (ici, le commit `1`, accroché à `0`)
 - il dialogue avec le serveur pour échanger le ou les commits manquants
-  - il lui indique ici que le commit `deebe146` soit être raccroché à la suite du commit `fd7357b0`
-- le serveur distant accepte ce changement, met à jour son historique local et en informe le client local
+  - _il lui indique ici que le commit `deebe146` soit être raccroché à la suite du commit `fd7357b0`_
+- le serveur distant accepte ce changement, **met à jour son historique local** et en informe le client local
 
-![](uploads/34032840fdc58814826132ae4820af9e/GitPush2.png)
+![GitLabPush2](uploads/c6f2d3e24c8bbd4b2f6be68c8f83ccbc/GitLabPush2.png)
 
-- le client local prend note de l'acceptation des changements et met à jour la branche de _remote-tracking_
+- le client local prend note de l'acceptation des changements et **met à jour la branche de _remote-tracking_**
 
-![](uploads/547607e77e2671a12d2dc19f00ab384f/GitPush3.png)
+![GitLabPush3](uploads/5d53f1f2e1beb5539210d837f6f61f20/GitLabPush3.png)
 
-> :bulb: Le serveur n'accepte les changements que s'ils consistent à **raccrocher des commits manquants derrière un commit présent sur le serveur** (_fast-forward_). Lorsque plusieurs contributeurs travaillent sur des clones locaux d'un même dépôt distant, l'envoi de commits par un contributeur peut échouer car de nouveaux commits ont pu être déposés par un autre contributeur avant la comparaison locale des historiques (_non fast-forward_). Cette situation est courante, donne lieu à une resynhcronisation aval (`pull`) et éventuellement une résolution locale de conflits de modifications.
+> :bulb: Le serveur n'accepte les changements que s'ils consistent à **raccrocher des commits manquants derrière un commit présent sur le serveur** (_fast-forward_). 
+>
+> Lorsque plusieurs contributeurs travaillent sur des clones locaux d'un même dépôt distant, l'envoi de commits par un contributeur peut échouer car de nouveaux commits ont pu être déposés par un autre contributeur avant la comparaison locale des historiques (_non fast-forward_). Cette situation est courante, donne lieu à une resynhcronisation aval (`pull`) et éventuellement une résolution locale de conflits de modifications.
 
 Ici, cette opération se déroule normalement et conduit à ce que les dépôts locaux et distants soient de nouveau à jour :