> :bulb: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: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 ici auto-généré 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 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 :
- 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_)
-**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, ...)
...
...
@@ -129,15 +128,22 @@ L'URL permettant d'effectuer le clonage selon l'une ou l'autre des méthodes d'a
Depuis le poste de travail, la commande `git clone` permet le clonage du dépôt (ici via `https`) :
> :bulb: Contrairement à `git init` qui devait être exécutée depuis un dossier servant de racine du dépôt et devant être préalablement créé, la commande `git clone` crée automatiquement le dossier racine avec le nom du dépôt à cloner.
On observe alors que le dépôt lest bien présent localement (répertoire `.git`) et que le working tree a bien été reconstruit (présence du fichier `README.MD`) :
```
MacBook-Air-749:~ sebastienjean$ cd gitlab-bases/
MacBook-Air-749:gitlab-bases sebastienjean$ ls -al
total 8
drwxr-xr-x 4 sebastienjean staff 128 Jan 23 17:57 .
drwxr-xr-x@ 160 sebastienjean staff 5120 Jan 23 17:57 ..
-rw-r--r-- 1 sebastienjean staff 54 Jan 23 17:57 README.md
```
> :bulb: Contrairement à `git init` qui devait être exécutée depuis un dossier servant de racine du dépôt et devant être préalablement créé, la commande `git clone` crée automatiquement le dossier racine avec le nom du dépôt à cloner.
### 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`) :
@@ -175,7 +179,7 @@ La section `branch` spécifie l'association des branches locales avec les branch
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
MacBook-Air-749:gitlab-bases sebastienjean$ git status
On branch main
Your branch is up to date with 'origin/main'.
...
...
@@ -184,11 +188,11 @@ nothing to commit, working tree clean
La commande `git log` permet de voir l'historique de façon exhaustive et d'y retrouver les pointeurs :
> :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_).
> :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.
