|
|
|
L'objectif de ce qui suit est de **prendre en main la plateforme _GitLab_**, permettant l'hébergement de dépôts versionnés avec *git*, et de se familiariser avec les fonctionnalités de base :
|
|
|
|
L'objectif de ce qui suit est de **prendre en main la plateforme _GitLab_**, permettant l'hébergement de dépôts versionnés avec _git_, et de se familiariser avec les fonctionnalités de base :
|
|
|
|
|
|
|
|
- [Création d'un projet GitLab](#cr-ation-d-un-projet-gitlab)
|
|
|
|
* [Connexion à un compte utilisateur sur le serveur *GitLab* interne de l'IUT de Valence](#connexion---un-compte-utilisateur-sur-le-serveur--gitlab--interne-de-l-iut-de-valence)
|
|
|
|
* [Connexion à un compte utilisateur sur le serveur _GitLab_ interne de l'IUT de Valence](#connexion---un-compte-utilisateur-sur-le-serveur--gitlab--interne-de-l-iut-de-valence)
|
|
|
|
* [Création d'un nouveau projet vierge](#cr-ation-d-un-nouveau-projet-vierge)
|
|
|
|
* [Navigation dans un projet](#navigation-dans-un-projet)
|
|
|
|
- [Clonage d'un dépôt distant et synchronisation amont](#clonage-d-un-d-p-t-distant-et-synchronisation-amont)
|
| ... | ... | @@ -11,118 +11,100 @@ L'objectif de ce qui suit est de **prendre en main la plateforme _GitLab_**, per |
|
|
|
+ [Ajout d'un commit local](#ajout-d-un-commit-local)
|
|
|
|
+ [Synchronisation amont du dépôt local](#synchronisation-amont-du-d-p-t-local)
|
|
|
|
|
|
|
|
<small><i><a href='http://ecotrust-canada.github.io/markdown-toc/'>Table of contents generated with markdown-toc</a></i></small>
|
|
|
|
[<small>_Table of contents generated with markdown-toc_</small>](http://ecotrust-canada.github.io/markdown-toc/)
|
|
|
|
|
|
|
|
## Création d'un projet GitLab
|
|
|
|
|
|
|
|
La suite décrit la création d'un projet hébergé sur un serveur GitLab (interne ici).
|
|
|
|
|
|
|
|
### Connexion à un compte utilisateur sur le serveur *GitLab* interne de l'IUT de Valence
|
|
|
|
### 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 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.
|
|
|
|
> :warning: Les services fournis par _GitLab_ sont rendus disponibles de 2 manières
|
|
|
|
>
|
|
|
|
> 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).
|
|
|
|
|
|
|
|
<p align="center">
|
|
|
|
<img src="uploads/7a423826508aa09bbab33871a9d75005/GitlabSignin.png" width="50%" />
|
|
|
|
</p>
|
|
|
|
|
|
|
|
[//]: 
|
|
|
|
> - 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).
|
|
|
|
|
|
|
|
Une fois connecté, l'écran d'accueil affiche le **tableau de bord** de l'utilisateur (*Dashboard*) :
|
|
|
|
|
|
|
|
|
|
|
|
<p align="center">
|
|
|
|
<img src="uploads/d2844e727b4c75f005d71757646445e5/GitlabDashboard.png" width="50%" />
|
|
|
|
</p>
|
|
|
|
Une fois connecté, l'écran d'accueil affiche le **tableau de bord** de l'utilisateur (_Dashboard_) :
|
|
|
|
|
|
|
|
[//]: 
|
|
|
|
|
|
|
|
|
|
|
|
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, ... )
|
|
|
|
> :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, ... )
|
|
|
|
> - d'autres services (pouvant être désactivés si besoin) tels que :
|
|
|
|
> - un wiki (pour documenter le code versionné dans le dépôt par exemple)
|
|
|
|
> - un outil de gestion de tickets (*issues*, pour signaler des bugs ou des souhaits de fonctionnalités supplémentaires, affecter des tâches à des contributeurs, ... )
|
|
|
|
> - un outil d'intégration continue (*CI/CD*, *Continuous Integration / Continuous Delivery*, pour automatiser le test, la mise en pré-production ou production, ..., à chaque nouveau commit)
|
|
|
|
> - un **wiki** (pour documenter le code versionné dans le dépôt par exemple)
|
|
|
|
> - un **outil de gestion de tickets** (_issues_, pour signaler des bugs ou des souhaits de fonctionnalités supplémentaires, affecter des tâches à des contributeurs, ... )
|
|
|
|
> - un **outil d'intégration continue** (_CI/CD_, _Continuous Integration / Continuous Delivery_, pour automatiser le test, la mise en pré-production ou production, ..., à chaque nouveau commit)
|
|
|
|
> - ...
|
|
|
|
|
|
|
|
Ici, il n'y a qu'un seul projet affiché, associé au *groupe* `INFO-BUT-R1-01`.
|
|
|
|
Ici, il n'y a qu'un seul projet affiché, associé au _groupe_ `INFO-BUT-R1-01`.
|
|
|
|
|
|
|
|
> :bulb: Dans *GitLab*, la notion de **groupe** permet de rassembler des projets (ici tous les projets liés aux enseignements dans la ressource *R1.01* du BUT Informatique), et d'y appliquer des éléments de configuration communs.
|
|
|
|
> :bulb: Dans _GitLab_, la notion de **groupe** permet de rassembler des projets (ici tous les projets liés aux enseignements dans la ressource _R1.01_ du BUT Informatique), et d'y appliquer des éléments de configuration communs.
|
|
|
|
|
|
|
|
### Création d'un nouveau projet vierge
|
|
|
|
|
|
|
|
La création d'un nouveau projet est accessible via le menu, l'icone `+` du bandeau supérieur, ou plus simplement à partir du bouton dédié `New Project` sur le tableau de bord.
|
|
|
|
|
|
|
|
Il est possible de créer un nouveau projet :
|
|
|
|
- vierge (*blank*)
|
|
|
|
- à partir d'un modèle prédéfini (*template*)
|
|
|
|
- par migration (*import*) d'un peojet hébergé sur une autre plateforme (*GitHub*, *BitBucket*, ...)
|
|
|
|
|
|
|
|
<p align="center">
|
|
|
|
<img src="uploads/e233ed338f6cc0c04724f1262ae6774b/GitlabNewProjectWizardChoice.png" width="50%" />
|
|
|
|
</p>
|
|
|
|
- vierge (_blank_)
|
|
|
|
- à partir d'un modèle prédéfini (_template_)
|
|
|
|
- par migration (_import_) d'un projet hébergé sur une autre plateforme (_GitHub_, _BitBucket_, ...)
|
|
|
|
|
|
|
|
[//]: 
|
|
|
|
|
|
|
|
|
|
|
|
Ici, pour créer le projet vierge, il suffit :
|
|
|
|
|
|
|
|
- de lui donner un **nom** (`project name`), ici `gitlab-basics`
|
|
|
|
- de renseigner une **description** (`project description`)
|
|
|
|
- de spécifier sa **visibilité** (qui peut voir les fichiers, ce qui ne veut pas forcément dire pouvoir les modifier) :
|
|
|
|
- *private*, accessible uniquement au propriétaire et aux contributeurs autorisés
|
|
|
|
- *internal*, accessible à tous les utilisateur du serveur
|
|
|
|
- *public*, accessible publiquement (sans connexion)
|
|
|
|
- _private_, accessible uniquement au propriétaire et aux contributeurs autorisés
|
|
|
|
- _internal_, accessible à tous les utilisateur du serveur
|
|
|
|
- _public_, accessible publiquement (sans connexion)
|
|
|
|
|
|
|
|
**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:)
|
|
|
|
|
|
|
|
<p align="center">
|
|
|
|
<img src="uploads/5ff8a37dce0296fe4642a086f234e6b9/GitlabNewProjectWizardBlank.png" width="50%" />
|
|
|
|
</p>
|
|
|
|
[//]: 
|
|
|
|
|
|
|
|
|
|
|
|
> :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 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 :
|
|
|
|
|
|
|
|
<p align="center">
|
|
|
|
<img src="uploads/1c33a75bd45141cb8f5660b0a5ce862a/GitlabScenarioNewProject.png" width="50%" />
|
|
|
|
</p>
|
|
|
|
|
|
|
|
[//]: 
|
|
|
|
|
|
|
|
|
|
|
|
### Navigation dans un projet
|
|
|
|
|
|
|
|
Une fois le nouveau projet créé, sa page d'accueil est affichée :
|
|
|
|
|
|
|
|
<p align="center">
|
|
|
|
<img src="uploads/85728ee28bb361c282781053153b0683/GitlabNewProjectHome.png" width="50%" />
|
|
|
|
</p>
|
|
|
|
[//]: 
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
La **fenêtre principale** donne des informations générales sur le projet :
|
|
|
|
|
|
|
|
- visibilité,
|
|
|
|
- visibilité,
|
|
|
|
- nombre de commits, de branches, de tags (_N.B. : un tag est un étiquette permettant de souligner un commit particulier_)
|
|
|
|
- résumé du dernier commit
|
|
|
|
- contenu du répertoire racine du dépôt
|
|
|
|
- contenu du répertoire racine du dépôt
|
|
|
|
- contenu (formatté) du fichier `README.md`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
> :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).
|
|
|
|
> :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*)
|
|
|
|
- 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, ...)
|
|
|
|
|
| ... | ... | @@ -132,23 +114,17 @@ 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_).
|
|
|
|
|
|
|
|
<p align="center">
|
|
|
|
<img src="uploads/7d83d539332343ba88df981a788b4585/GitLabClone.png" width="50%" />
|
|
|
|
</p>
|
|
|
|
[//]:
|
|
|
|
|
|
|
|
|
|
|
|
> :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`.
|
|
|
|
|
|
|
|
<p align="center">
|
|
|
|
<img src="uploads/ba79bfb3c7f327cf4208e4a9e5d9e920/GitLabCloneURL.png" width="25%" />
|
|
|
|
</p>
|
|
|
|
[//]: 
|
|
|
|
|
|
|
|
|
|
|
|
__N.B.__ : _les manipulations suivantes sont effectuées depuis un terminal Linux-compatible, les commandes ont des équivalents sous Windows_
|
|
|
|
**N.B.** : _les manipulations suivantes sont effectuées depuis un terminal Linux-compatible, les commandes ont des équivalents sous Windows_
|
|
|
|
|
|
|
|
Depuis le poste de travail, la commande `git clone` permet le clonage du dépôt (ici via `https`) :
|
|
|
|
|
| ... | ... | @@ -190,11 +166,11 @@ MacBook-Air-749:gitlab-basics sebastienjean$ cat .git/config |
|
|
|
merge = refs/heads/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 `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 évolution distante de cette branche sera fusionnée (*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 à 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,30 +189,26 @@ Author: Sebastien Jean <sebastien.jean@univ-grenoble-alpes.fr> |
|
|
|
Date: Sun Jan 23 10:13:01 2022 +0000
|
|
|
|
|
|
|
|
Initial commit
|
|
|
|
|
|
|
|
```
|
|
|
|
|
|
|
|
Ici, on peut observer les pointeurs suivants :
|
|
|
|
|
|
|
|
- `HEAD`, qui désigne toujours le commit sur lequel est basée 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é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_)
|
|
|
|
- `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.
|
|
|
|
|
|
|
|
Le schéma ci-dessous illustre le résultat du clonage, en montrant les branches :
|
|
|
|
|
|
|
|
<p align="center">
|
|
|
|
<img src="uploads/1fb25710323231fb9ec8d8827a97e38b/GitLabCloneWithBranches.png" width="50%" />
|
|
|
|
</p>
|
|
|
|
[//]: 
|
|
|
|
|
|
|
|
|
|
|
|
### Synchronisation amont d'un dépôt local
|
|
|
|
|
|
|
|
#### Ajout d'un commit local
|
|
|
|
#### Ajout d'un commit local
|
|
|
|
|
|
|
|
On crée un nouveau fichier `unFichier.txt` à la racine du *Working Tree* :
|
|
|
|
On crée un nouveau fichier `unFichier.txt` à la racine du _Working Tree_ :
|
|
|
|
|
|
|
|
```bash
|
|
|
|
MacBook-Air-749:gitlab-basics sebastienjean$ cat > unFichier.txt
|
| ... | ... | @@ -281,13 +253,9 @@ Your branch is ahead of 'origin/main' by 1 commit. |
|
|
|
nothing to commit, working tree clean
|
|
|
|
```
|
|
|
|
|
|
|
|
<p align="center">
|
|
|
|
<img src="uploads/62d131b8cb94717b85b1e8c09e884a98/GitCloneThenCommit.png" width="50%" />
|
|
|
|
</p>
|
|
|
|
[//]: 
|
|
|
|
|
|
|
|
|
|
|
|
> :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**
|
|
|
|
> :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
|
|
|
|
|
| ... | ... | @@ -295,31 +263,22 @@ 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`
|
|
|
|
|
|
|
|
<p align="center">
|
|
|
|
<img src="uploads/6ab0a5bbf04da3c3809dd78ed536970d/GitPush1.png" width="50%" />
|
|
|
|
</p>
|
|
|
|
[//]: 
|
|
|
|
|
|
|
|
|
|
|
|
- il détermine ce qui doit être transmis au serveur distant (ici, le commit `1`)
|
|
|
|
- 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`
|
|
|
|
- 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
|
|
|
|
|
|
|
|
<p align="center">
|
|
|
|
<img src="uploads/34032840fdc58814826132ae4820af9e/GitPush2.png" width="50%" />
|
|
|
|
</p>
|
|
|
|
[//]: 
|
|
|
|
|
|
|
|
|
|
|
|
- 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_
|
|
|
|
|
|
|
|
<p align="center">
|
|
|
|
<img src="uploads/547607e77e2671a12d2dc19f00ab384f/GitPush3.png" width="50%" />
|
|
|
|
</p>
|
|
|
|
[//]: 
|
|
|
|
|
|
|
|
|
|
|
|
> :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 :
|
|
|
|
|
| ... | ... | @@ -352,10 +311,7 @@ Date: Sun Jan 23 10:13:01 2022 +0000 |
|
|
|
Initial commit
|
|
|
|
```
|
|
|
|
|
|
|
|
<p align="center">
|
|
|
|
<img src="uploads/57dcbb31e0cbd6609a0b8af9c85fe030/GitPush4.png" width="50%" />
|
|
|
|
</p>
|
|
|
|
[//]: 
|
|
|
|
|
|
|
|
|
|
|
|
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 :
|
|
|
|
|
| ... | ... | @@ -396,5 +352,4 @@ Author: Sebastien Jean <sebastien.jean@univ-grenoble-alpes.fr> |
|
|
|
Date: Sun Jan 23 10:13:01 2022 +0000
|
|
|
|
|
|
|
|
Initial commit
|
|
|
|
```
|
|
|
|
|
|
|
|
``` |
|
|
\ No newline at end of file |
