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

@@ -24,7 +24,7 @@ La suite décrit la création d'un projet hébergé sur un serveur GitLab (inter
 > - en mode **_Saas_** (_Software as a Service_, autrement dit sous forme d'un logiciel déployé sur la cloud et accessible via le Web), sur [www.gitlab.com](www.gitlab.com). L'accès et les fonctionnalités offertes sont conditionnés par la création d'un compte utilisateur et la souscription d'une offre (gratuite ou payante).
 > - en mode **_self-managed_**, c'est à dire déployé sur un serveur d'un réseau local (éventuellement rendu accessible de manière distante). L'accès est (en général) conditionné par l'existence d'un compte utilisateur, les fonctionnalités sont restreintes (ou non) par l'administrateur du serveur.
 >
-> Dans la suite, les manipulations s'effectuent sur le serveur _GitLab_ interne de l'IUT de Valence, accessible depuis le réseau local ou l'extérieur via [gitlab.iut-valence.fr](gitlab.iut-valence.fr). Toute personne disposant d'un compte utilisateur au sein de l'établissement peut accéder à ce serveur en utilisant ses identifiants de connexion standards (annuaire LDAP). _Les personnes ne disposant pas de compte peuvent uniquer accéder aux dépôts publiques dont il connaissent l'URL._
+> Dans la suite, les manipulations s'effectuent sur le serveur _GitLab_ interne de l'IUT de Valence, accessible depuis le réseau local ou l'extérieur via [gitlab.iut-valence.fr](gitlab.iut-valence.fr). Toute personne disposant d'un compte utilisateur au sein de l'établissement peut accéder à ce serveur en utilisant ses identifiants de connexion standards (annuaire LDAP). _Toute personne extérieure ne peut accéder qu'aux dépôts publics dont elle possède l'URL._
 
 ![](uploads/7a423826508aa09bbab33871a9d75005/GitlabSignin.png)
 
@@ -74,12 +74,12 @@ Ici, pour créer le projet **vierge**, il suffit :
 
 > :bulb: Il est également possible :
 >
-> - de spécifier si le projet doit être rattaché à l'utilisateur (c'est le cas ici), ou à un groupe auquel l'utilisateur est associé.
+> - de spécifier si le projet doit être rattaché à l'utilisateur (c'est le cas ici), ou à un groupe auquel il est associé.
 > - de modifier le suffixe de l'URL (`project slug`) à travers lequel il sera possible d'accéder au projet par la suite
 
 :rewind: La première étape, du point de vue de la gestion de versions, a été de mettre en place un dépôt distant sur le serveur GitLab, tel qu'illustré sur le schéma suivant :
 
-![](uploads/1c33a75bd45141cb8f5660b0a5ce862a/GitlabScenarioNewProject.png)
+![GitlabRepoCreate](uploads/34d4fc27c32f9d8c40cc32fbc19dad8c/GitlabRepoCreate.png)
 
 ### Navigation dans un projet
 
@@ -97,7 +97,7 @@ La **fenêtre principale** donne des informations générales sur le projet :
 
 ![GitlabNewProjectHomeFocus](uploads/1cd7ef084ca4f7f82bd1887e644ca436/GitlabNewProjectHomeFocus.png)
 
-> :bulb: Par convention dans _GitLab_, la branche principale (par défaut) s'appelle `main`. A la création du projet, le fichier `README.md` est inclus dans un premier commit. Le dépôt est dit _bare_ (brut), il ne contient que l'historique et non les fichiers eux-mêmes. GitLab donne l'illusion que les fichiers sont présents en offrant comme service leur visualisation et leur édition (qui se traduisent par des opérations sur l'historique).
+> :bulb: Par convention dans _GitLab_, la branche principale (par défaut) s'appelle `main`. A la création du projet, le fichier `README.md` est inclus dans un premier commit. Le dépôt est dit **_bare_** (brut), il ne contient que l'historique et non les fichiers eux-mêmes. GitLab donne l'illusion que les fichiers sont présents en offrant comme service leur visualisation et leur édition (qui se traduisent par des opérations sur l'historique).
 
 La fenêtre principale permet également quelques actions :
 
@@ -114,7 +114,7 @@ La suite décrit le clonage d'un dépôt distant (`clone`) et l'envoi de commits
 
 ### Clonage d'un dépôt distant
 
-L'opération de clonage, comme illustré ci-dessous, permet de créer localement (sur le poste de travail d'un dévéloppeur) un dépôt contenant une copie intégrale de l'historique du dépôt distant et une reconstruction du _Working Tree_ correspondant au dernier commit (dépôt _non bare_).
+L'opération de **clonage**, comme illustré ci-dessous, permet de créer localement (sur le poste de travail d'un dévéloppeur) un dépôt contenant une copie intégrale de l'historique du dépôt distant et une reconstruction du _Working Tree_ correspondant au dernier commit (dépôt _non bare_).
 
 ![](uploads/7d83d539332343ba88df981a788b4585/GitLabClone.png)