@@ -20,7 +20,7 @@ La suite décrit la création d'un projet hébergé sur un serveur GitLab (inter
### Connexion à un compte utilisateur sur le serveur *GitLab* interne de l'IUT de Valence
> :warning: Les services fournis par *GitLab* sont rendus disponibles de 2 manières
> - 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 est les fonctionnalités offertes sont conditionné par la création d'un compte utilisateur et la souscription d'une offre (gratuite ou payante)
> - 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 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).
...
...
@@ -40,7 +40,7 @@ Une fois connecté, l'écran d'accueil affiche le **tableau de bord** de l'utili
Le profil de l'utilisateur peut être consulté/modifié via l'icone dédié en haut à droite), le menu permet d'accéder aux diverses actions (un raccourci permet de créer immédiatement un projet), et il est possible de voir les **projets** en cours (ceux auxquels l'utilisateur est associé)
Le **profil** de l'utilisateur peut être consulté/modifié via l'icone dédié en haut à droite), le **menu** permet d'accéder aux diverses actions (un raccourci permet de créer immédiatement un projet), et il est possible de voir les **projets** en cours (ceux auxquels l'utilisateur est associé)
> :bulb: Dans *GitLab*, la notion de **projet** est plus large qu'un dépôt, elle regroupe :
> - un dépôt, et des informations de configuration (contributeurs, droits d'accès, ... )
...
...
@@ -77,14 +77,14 @@ Ici, pour créer le projet vierge, il suffit :
-*internal*, accessible à tous les utilisateur du serveur
L'usage veut que le dépôt de code soit initialisé avec un fichier `README.md` décrivant ce qu'on peut y trouver. Ce fichier est généré à partir de la description et peut être modifié par la suite. Il est rédigé en utilisant la syntaxe [Markdown](https://daringfireball.net/projects/markdown/)(avec laquelle est aussi rédigé ce wiki :wink:)
**N.B.**L'usage veut que le dépôt de code soit initialisé avec un fichier `README.md` décrivant ce qu'on peut y trouver. Ce fichier est généré à partir de la description et peut être modifié par la suite. Il est rédigé en utilisant la syntaxe [Markdown](https://daringfireball.net/projects/markdown/)(avec laquelle est aussi rédigé ce wiki :wink:)
> :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 est 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 :
- observer l'historique (cette action est également accessible via le menu latéral (`Repository->Commits` ou `Repository->Graphs`)
- télécharger une archive contenant l'intégralité de la version courante du code
- cloner le dépôt (cf. plus loin)
- ouvrir l'IDE en ligne (*Web IDE*)
L'ensemble des actions est accessible depuis le menu latéral, notamment la configuration du projet (contribteurs, rôles, ...)
L'ensemble des actions est accessible depuis le **menu latéral**, notamment la configuration du projet (contribteurs, rôles, ...)
## Clonage d'un dépôt distant et synchronisation amont
La suite décrit le clonage d'un dépôt distant (`clone`) et l'envoi de commit locaux à distance (`push`).
La suite décrit le clonage d'un dépôt distant (`clone`) et l'envoi de commits locaux à distance (`push`).
### Clonage d'un dépôt distant
...
...
@@ -134,12 +139,12 @@ L'opération de clonage, comme illustré ci-dessous, permet de créer localement
> :bulb: Les dépôts *internal* ou *private* ne peuvent être clonés qu'après authentification de l'utilisateur réalisant le clonage (les dépôts *public* sont clonables sans authentification). L'authentification et le clonage en lui-même) peuvent s'effectuer via le protocole `git` (nécessitant l'ajout sur le serveur d'une clé SSH associée à l'utilisateur) ou via le protocole `https` (authentification par mot de passe ou token)
> :bulb: Les dépôts *internal* ou *private* ne peuvent être clonés qu'après authentification de l'utilisateur réalisant le clonage (les dépôts *public* sont clonables sans authentification). L'authentification et le clonage en lui-même peuvent s'effectuer via le protocole `git` (nécessitant l'ajout sur le serveur d'une clé SSH associée à l'utilisateur) ou via le protocole `https` (authentification par mot de passe ou token).
L'URL permettant d'effectuer le clonage selon l'une ou l'autre des méthodes d'authentification peut être obtenue via l'action `clone`.
### Visualisation de la configuration du dépôt, de l'état et de l'historique
L'affichage de la configuration du dépôt local (fichier `config` dans le dossier caché `.git`) fait apparaitre des sections liées au clonage (`remote`, `branch`)
L'affichage de la configuration du dépôt local (fichier `config` dans le dossier caché `.git`) fait apparaitre des sections liées au clonage (`remote`, `branch`) :
La section `remote` spécifie que ce dépôt local est lié à un dépôt distant identifié par convention avec le nom symbolique `origin`. la propriété `fetch` indique que chaque branche `b` du dépôt distant sera suivie localement dans une pseudo branche (*remote-tracking branch*) nommée `origin/b`. (ici `main`sera suivie localement en `origin/main`)
La section `remote` spécifie que ce dépôt local est lié à un dépôt distant identifié par convention avec le nom symbolique `origin`. La propriété `fetch` indique que chaque branche `b` du dépôt distant sera suivie localement dans une pseudo branche (*remote-tracking branch*) nommée `origin/b` (ici `main`sera suivie localement en `origin/main`).
La section `branch` spécifie l'association des branches locales avec les branches distantes. Ici la branche `main` est associée à la branche `main` distante (suivie localement dans `origin/main`) et chaque les évolutions distantes de cette branche seront fusionnées (*merge*) dans la branche locale.
La section `branch` spécifie l'association des branches locales avec les branches distantes. Ici la branche `main` est associée à la branche `main` distante (suivie localement dans `origin/main`) et chaque évolution distante de cette branche sera fusionnée (*merge*) dans la branche locale.
L'exécution de la commande `git status` montre aussi, dans le cas d'un clone, en quoi la branche locale est ou non en à jour (*up to date*, ni en avance ni en retard) avec la branche distante :
L'exécution de la commande `git status` montre aussi, dans le cas d'un clone, **en quoi la branche locale est ou non à jour** (*up to date*, ni en avance ni en retard) avec la branche distante :
```bash
MacBook-Air-749:gitlab-basics sebastienjean$ git status
...
...
@@ -213,10 +218,10 @@ Date: Sun Jan 23 10:13:01 2022 +0000
Ici, on peut observer les pointeurs suivants :
-`HEAD`, qui désigne toujours le commit sur lequel est basé la reconstruction du *working tree*
-`HEAD`, qui désigne toujours le commit sur lequel est basée la reconstruction du *working tree*
-`main`, qui désigne toujours dernier commit de la branche locale `main`
-`origin/main`, qui désigne le dernier commit de la branche distante `main`
-`origin/HEAD`, qui désigne le commit sur lequel est basé la reconstruction du *working tree* distant (_N.B. celui-ci n'existe pas, les pointeurs `origin/main` et `origin/HEAD` seront toujours alignés_)
-`origin/HEAD`, qui désigne le commit sur lequel est basée la reconstruction du *working tree* distant (_N.B. celui-ci n'existe pas, les pointeurs `origin/main` et `origin/HEAD` seront toujours alignés_)
On en déduit que l'historique local est absolument à jour avec l'historique distant.
...
...
@@ -231,7 +236,7 @@ Le schéma ci-dessous illustre le résultat du clonage, en montrant les branches
#### Ajout d'un commit local
- création d'un nouveau fichier `unFichier.txt` à la racine du *Working Tree* :
On crée un nouveau fichier `unFichier.txt` à la racine du *Working Tree* :
> :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.
> **ce commit doit être explicitement transmis au serveur**
> :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**
#### Synchronisation amont du dépôt local
...
...
@@ -290,14 +295,14 @@ L'envoi des commits manquants s'effectue via la commande `git push`.
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`
- le client `git` local compare l'état de la branche locale `main` et de la branche de *remote-tracking*`origin/main`
> :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 :
...
...
@@ -351,3 +356,45 @@ Date: Sun Jan 23 10:13:01 2022 +0000
A partir de cette étape, si on supprime complètement le dépôt local et que l'on reclone le dépôt distant, on récupérera bien l'intégralité de l'historique puisque le commit local a été transmis avec succès au serveur :
```bash
MacBook-Air-749:gitlab-basics sebastienjean$ pwd
/Users/sebastienjean/gitlab-basics
MacBook-Air-749:gitlab-basics sebastienjean$ cd ..
