TP1 : Découvrir Git et GitLab
Disclaimer
Le tutoriel est en français, mais de nombreux mots-clés sont en anglais. Il est essentiel de vous familiariser avec le langage informatique ainsi qu’avec les documentations techniques, qui sont majoritairement rédigées en anglais.
Avant de commencer à coder, il est important de se familiariser avec les outils permettant d’organiser votre travail de programmation.
Objectifs¶
Le but de ce TP est de comprendre les points suivants :
git clone <adresse du dépôt distant avec PAT>
(Personal Access Token et Configuration de votre poste de travail)git status
(Dépôt local)git add <nom du fichier>
(Dépôt local)git commit -m "<message de commit>"
(Dépôt local)git push
(Dépôt local)git remote update
(Dépôt distant et Synchronisation du dépôt local avec le dépôt distant)git pull
(Dépôt distant et Synchronisation du dépôt local avec le dépôt distant).gitignore
(Ignorer des fichiers)
Ces points sont essentiels pour la suite donc il faut absolument les maîtriser !
Activation de votre compte GitLab¶
En tant qu’étudiant à l’IUT d’Orsay, vous disposez déjà d’un compte sur le GitLab de l’IUT.

Pour vous connecter, utilisez votre identifiant et votre mot de passe du département.
Personal Access Token¶
Pour établir une connexion sécurisée entre votre machine et le serveur GitLab de l’IUT, nous utiliserons un Personal Access Token (PAT) qui remplace l’ancien système de mot de passe.
Pour créer un PAT :
- Accédez à votre profil en cliquant sur votre avatar (en haut à gauche) puis Edit profile.

- Dans le menu de gauche, cliquez sur Access Tokens.

- Ajouter un nouveau token en cliquant sur Add new token.

- Donnez un nom au token qui reflète le poste de travail utilisé (par exemple
IUTOrsay
si vous travaillez sur un poste à l’IUT).
- Définissez une date d’expiration d’un an (la durée maximale autorisée) à partir de la date d’aujourd’hui.
Date d’expiration
De la même manière qu’il est recommandé de changer régulièrement son mot de passe, la date d’expiration du PAT impose d’en générer un nouveau à intervalles réguliers.
- Sélectionnez tous les scopes.
Scope
L’intérêt de limiter les scopes d’un PAT est qu’en cas d’attaque, le pirate ne pourra effectuer que les actions autorisées par ces scopes, réduisant ainsi les risques de compromission.
- Cliquez sur Create personal access token.
Création d’un dépôt distant¶
- Créez votre premier projet/dépôt (repository) en cliquant sur le bouton
+
en haut à gauche.

- Créez un projet vide avec le nom
qualite-dev-s2-<prenom>-<nom>
(par exemplequalite-dev-s2-hoang-la
).
Pour l’URL du projet, choisissez votre login court Users et l’URL proposé par défaut.
Sélectionnez l’option de visibilité “Privé” pour votre projet et cochez l’option pour initialiser le projet avec un README.
Cliquez sur Create Project.
Si vous voyez les messages suivantes, vous pouvez les ignorer en cliquant sur Don’t show again pour SSH key et
X
pour Auto DevOps.

- Parcourez le README par défaut proposé par GitLab.
macOS
Les commandes Unix sous Linux et macOS sont très similaires, mais il se peut que vous deviez parfois adapter certaines d’entre elles.
Windows
Vous pouvez installer l’émulateur Git for Windows.
Configuration de votre poste de travail¶
Votre projet a été créé sur le serveur de l’IUT. Maintenant, pour travailler sur ce projet depuis votre poste de travail local, vous devez d’abord le configurer.
- Recopiez les lignes de code suivantes dans un terminal.
git config --global user.name "<Prénom> <Nom>"
git config --global user.email "<Email universitaire>"
Par exemple :
git config --global user.name "Hoang La"
Puis :
git config --global user.email "hoang.la@universite-paris-saclay.fr"
Ou :
git config --global user.email "hoang.la-tmp@universite-paris-saclay.fr"
Vous pouvez maintenant cloner votre dépôt distant pour le télécharger sur votre poste local : 2. Cliquez sur le bouton Code situé à droite.

- Copiez l’URL sous l’option Clone with HTTPS.

Placez-vous dans votre répertoire de travail préféré (et ouvrez un terminal).
Saisissez la commande suivante, en collant l’adresse copiée et en rajoutant votre login ainsi que votre PAT aux emplacements appropriés.
git clone https://<votre login court>:<Personal Access Token>@git.iut-orsay.fr/<login du créateur du projet>/<nom du projet>.git
Par exemple :
git clone https://hla:glpat-1234thisIsYourPAT5678@git.iut-orsay.fr/hla/monprojet.git
PAT expiré ou perdu
Si votre PAT est expiré ou perdu, vous pouvez exécuter la même commande sur votre projet déjà cloné en remplaçant clone
par remote set-url origin
, plutôt que de recloner le projet.
Par exemple :
git remote set-url origin https://hla:glpat-1234thisIsYourNewPAT5678@git.iut-orsay.fr/hla/monprojet.git
Dépôt local¶
Un répertoire portant le même nom (dépôt local) a maintenant été téléchargé sur votre machine.
- Exécutez les commandes suivantes.
cd monprojet/
ls
git status
La commande ls
vous permet d’afficher l’ensemble des fichiers dans le répertoire, tandis que git status
montre l’état du dépôt. Pour l’instant, cette dernière commande devrait indiquer qu’il n’y a rien à valider et que votre copie de travail est propre (nothing to commit, working tree clean).
- Que constatez-vous en exécutant les commandes suivantes ?
touch my-first-file.txt
git status
Fichiers et modifications non suivis
Git indique que votre répertoire de travail contient un nouveau fichier ou une modification non suivie (untracked).
Git est un outil de gestion de versions : il vous permet de conserver l’historique des changements des fichiers de votre projet. Cependant, tous les fichiers ou modifications ne sont pas nécessairement importants. Ainsi, par défaut, les fichiers que vous créez ou les modifications que vous effectuez ne sont pas suivis. Seuls les fichiers et modifications explicitement suivis auront leur historique enregistré.
Ajoutez une ligne dans
my-first-file.txt
(par exempleHello World!
).Demandez à Git de suivre la modification à
my-first-file.txt
en exécutant la commande suivante.
git add my-first-file.txt
- Exécutez à nouveau la commande
git status
. Que vous indique-t-elle ?
git restore --staged
git restore --staged
Si vous avez ajouté par erreur une modification ou un fichier, vous pouvez retirer (unstage) la modification suivie en utilisant la commande git restore --staged <nom du fichier>
.
Par exemple, exécutez git restore --staged my-first-file.txt
, puis vérifier l’état du dépôt avec git status
. N’oubliez-pas de resuivre la modification en utilisant git add
.
- Maintenant, pour créer un historique des modifications suivies (ici, le fichier
my-first-file.txt
avec la ligneHello World!
), vous devez valider (commit) ces changements et ajouter un message décrivant ces modifications en exécutant la commandegit commit -m "<message de commit descriptif>"
.
Par exemple :
git commit -m "Premier commit de my-first-file.txt qui dit Hello World!"
- Réexécutez
git status
pour vérifier l’état de votre dépôt. Que vous indique-t-elle ?
Ready to push
La validation a été effectuée. Votre version locale du projet est maintenant en avance par rapport à la version sur le serveur GitLab. Vous pouvez donc diffuser (push) ces changements pour synchroniser les deux versions.
Exécutez
git push
.Retournez sur GitLab et vérifiez que le dépôt distant correspond bien au dépôt local.
Dépôt distant¶
- Cliquez sur
my-first-file.txt
. - Cliquez sur Edit.
- Sélectionnez l’option Open in Web IDE.
- Ajoutez une deuxième ligne à ce fichier (par exemple,
Hi!
).
Vous pouvez voir un 1
sur la barre à gauche, indiquant qu’un changement a été effectué.
Si vous cliquez dessus, vous verrez un changement concernant le fichier my-first-file.txt
et l’option pour sauvegarder et diffuser sur la branche main
(Commit and push to ‘main’).
- Ajoutez un message de commit.
- Cliquez sur le bouton Commit and push to ‘main’.
- Cliquez sur Continue lorsque l’on vous demande si vous souhaitez sauvegarder sur la branche par défaut (main).
Branches
La notion de branches en Git permet de maintenir une version stable d’une application ou d’un projet. Toutes les modifications sont donc effectuées sur des branches autres que ‘main’ (d’autres versions du dépôt), puis fusionnées avec cette branche plus tard.
Par exemple, dans un projet, la partie IHM et la partie logique du code peuvent être séparées en deux branches distinctes, autres que ‘main’. La branche principale (‘main’) contiendra une version stable et fonctionnelle du projet, tandis que les deux autres branches contiendront des versions en développement.
Dans ce cours, nous ne couvrirons pas les branches Git, ainsi que d’autres fonctionnalités avancées de Git. Vous allez travailler seulement sur une seule branche : ‘main’.
Synchronisation du dépôt local avec le dépôt distant¶
Retournez sur votre dépôt local et supposons qu’un collaborateur a effectué des changements, puis les a diffusés sur le dépôt distant sans que vous en soyez informé.
- Exécutez
git status
. Que remarquez-vous d’étrange ?
- Exécutez
git remote update
, puisgit status
. Que voyez-vous maintenant ?
git remote update
git remote update
git remote update
met à jour les informations sur le dépôt distant. Maintenant, git status
est capable de comparer le dépôt local et le dépôt distant.
- Exécutez
git diff origin/main
pour voir les différences entre les deux dépôts.
Commencez par git remote update && git status
!
git remote update && git status
!En pratique, lorsque vous travaillez sur un projet, il est fréquent qu’entre deux sessions de travail, quelqu’un d’autre ait modifié une partie du code. Si vous commencez une session de travail sans vérifier l’état de vos dépôts, vous risquez de rencontrer des conflits à résoudre (par exemple, si vous modifiez les mêmes parties de code de manière différente).
Bien que nous allons parler de la résolution de conflits dans ce cours, il est préférable de les éviter. C’est pourquoi il est essentiel de toujours commencer par git remote update && git status
avant de décider ce qu’il faut faire !
Vous pouvez également exécuter git diff origin/main
pour voir précisément les modifications qui ont été effectuées.
- Pour synchroniser votre dépôt local avec le dépôt distant (qui, cette fois, est en avance), exécutez
git pull
.
Si le dépôt distant contient une version incorrecte du projet...
Dans ce cas, il n’est pas toujours souhaitable d’exécuter git pull
. Nous verrons comment gérer cette situation dans les prochains TPs.
- Pour consulter l’historique des commits, exécutez
git log
. Pour quitter le log, appuyer surq
(pour ‘quit’).
Ignorer des fichiers¶
Créez un fichier
hello-world.cpp
(avectouch hello-world.cpp
par exemple).Ouvrez
hello-world.cpp
dans votre éditeur de code préféré et recopiez le code suivant.
#include <iostream>
using namespace std;
int main() {
cout << "Hello World!" << endl;
return 0;
}
- Compilez le code avec
g++ -o <nom du fichier> <nom du fichier>.cpp
.
Par exemple :
g++ -o hello-world hello-world.cpp
- Exécutez l’exécutable
hello-world
avec la commande./hello-world
.
Les exécutables font partie des fichiers que nous souhaitons ignorer.
- Créez le fichier
.gitignore
.
Pourquoi .gitignore
commence par un .
?
.gitignore
commence par un .
?Les fichiers dont les noms commencent par .
sont des fichiers cachés (qui ne s’affichent pas quand vous utilisez un gestionnaire de fichiers). Ce sont souvent des fichiers de configurations.
Pour afficher les fichiers cachés dans un gestionnaire de fichiers, vous pouvez souvent appuyer sur Ctrl + H (comme ‘Hidden’).
Le répertoire .git
que vous voyez dans votre projet contient les fichiers de configuration internes de Git.
Il est important de ne pas modifier ce dossier, car il gère le suivi et l’historique de votre dépôt.
Par ailleurs, ce dossier est ignoré par Git de manière native.
- Écrivez le nom de l’exécutable
hello-world
dans.gitignore
.
Si votre éditeur a généré d’autres fichiers à ignorer...
Dans ce cas, il faut ajouter les noms de ces fichiers dans .gitignore
.
Exécutez
git add
,git commit -m "<message>"
etgit push
pour envoyer le fichier.gitignore
sur le dépôt distant.Exécutez
git status
. Qu’est-ce qui change par rapport à d’habitude ?
Où sont mes fichiers non suivis ?
Normalement, comme nous n’avons pas ajouté l’exécutable hello-world
avec git add
, git status
nous indique qu’il y a un fichier non suivi, potentiellement important. Cependant, grâce au fichier .gitignore
, Git reconnaît que nous avons choisi d’ignorer hello-world
et ne suivra jamais les modifications apportées à ce fichier.
Pour finir...¶
Terminons ce TP par une petite réorganisation.
- Créez un dossier
TP1/
dans votre projet et bougez tout sauf.git
,.gitignore
etREADME.md
vers ce dossier.
Vous allez maintenir ce projet pendant le reste du cours en créant des dossiers séparés pour chaque TP.
- Revenez à la racine du projet et exécutez
git add .
- Validez les modifications suivies avec
git commit
.
J’ai oublié de mettre un message de commit...
Vous êtes ici parce que vous avez exécuté git commit
sans spécifier de message avec l’option -m
(git commit -m "<message>"
). Git vous oblige donc à écrire un message en ouvrant la fenêtre suivante.

Ici, nous avons oublié d’ajouter un message de commit pour la suppression d’un fichier nommé test.txt
.
- Écrivez votre message de commit sur la première ligne.
Si vous êtes sur l’éditeur Nano (qui ressemble à l’écran au-dessus) :
- Appuyez sur Ctrl + X pour quitter.
- Appuyez sur
y
pour valider les modifications du message de commit. - Appuyez sur
Enter
pour quitter la fenêtre.
Si vous êtes sur l’éditeur Vim (éditeur par défaut de Debian à l’IUT) :
- Appuyez sur
Esc
pour sortir du mode insertion. - Écrivez
:wq
pour enregistrer le message et quitter la fenêtre. - Appuyez sur
Enter
pour exécuter la commande:wq
.
Vu que nous allons ignorer beaucoup d’exécutables dans le futur, pour éviter de modifier .gitignore
à chaque fois, nous allons utiliser des expressions régulières pour ignorer les fichiers sans extensions (les exécutables).
- Remplacez le code du fichier
.gitignore
avec le code suivant.
*
!*.*
!*/
Je dois ignorer d’autres types de fichiers...
Vous avez peut-être utilisé un éditeur qui génère d’autres types de fichiers à ignorer, en plus des fichiers sans extension que nous avons déjà exclus avec le code ci-dessus.
Par exemple, si des fichiers .o
ou .exe
ont été générés et que vous souhaitez les ignorer à l’avenir, ajoutez les lignes suivantes à votre fichier .gitignore
, à la place de celles proposées plus haut :
**/*.exe
**/*.o
**/
signifie que la recherche s’applique à la racine ainsi qu’à tous les dossiers et sous-dossiers.*.exe
et*.o
permettent d’ignorer tous les fichiers portant ces extensions.
Autre exemple : si votre éditeur a généré un dossier build/
, vous pouvez ajouter la ligne suivante :
**/build/
Cela exclura tout le contenu des dossiers nommés build
, quel que soit leur emplacement dans le projet.
Vous pouvez même tout combiner pour ignorer à la fois les fichiers sans extension, les fichiers .o
, les fichiers .exe
et les dossiers build/
(ainsi que leur contenu) avec les expressions suivantes pour votre .gitignore
.
*
!*.*
!*/
**/*.exe
**/*.o
**/build/
Exécutez
add
,commit
etpush
pour synchroniser vos dépôts.Ajoutez votre encadrant à votre projet en suivant les instructions ci-dessous.
- Cliquez sur Manage à gauche, puis sélectionnez Members.

- Cliquez sur Invite members en haut à droite.
- Ajoutez votre encadrant avec le rôle Maintainer, qui lui donne presque autant de droit sur le projet que le rôle Owner.
- Revenez aux objectifs et cochez les points que vous avez maîtrisés. Pratiquez les commandes et les points que vous n’avez pas encore bien compris. Appelez votre encadrant si besoin.
Si des fichiers indésirables traînent dans votre dépôt distant...
Les mêmes fichiers se trouvent normalement dans votre dépôt local (sinon, vous pouvez d’abord synchroniser vos dépôts). Vous pouvez ensuite les supprimer avec git rm
et synchroniser à nouveau les dépôts.
git rm
git rm
Vous pouvez utiliser git rm <nom du fichier>
pour supprimer un fichier qui a déjà été synchronisé sur les deux dépôts. git rm
fonctionne de manière similaire à git add
, mais pour supprimer des fichiers. Ensuite, vous pouvez faire un git commit
suivi d’un git push
, comme d’habitude, pour diffuser ces changements (suppressions).
Un fichier qui se trouve uniquement sur le dépôt local peut être supprimé simplement via un gestionnaire de fichiers ou avec la commande rm
(sans git
). Si vous avez déjà ajouté (git add
) ce fichier aux modifications suivies (staged changes), vous pouvez le retirer grâce à git restore --staged <nom du fichier>
.