CHAPITRE 1 Manipuler les outils de gestion de versions (Git/Gitlab) Gestion de versions centralisée (Centralized VCS)

1. Intérêt de la gestion de version et présentation des outils existants de gestion

de versions

1.1 Définition de la gestion de versions (VCS)

La gestion de versions est un système qui permet de suivre et d’organiser

l’évolution d’un fichier ou d’un projet informatique. Elle facilite aussi le travail en
équipe.

1.2 Avantages de la gestion de versions

Elle permet notamment de :

• garder plusieurs versions d’un même fichier ou projet ; (Versioning)

• visualiser les modifications effectuées au fil du temps ;( Timeline)
Un serveur central appelé dépôt (repository), qui contient toutes les versions des
• revenir à une version antérieure en cas d’erreur ; (Rollback)
fichiers d’un projet. Les développeurs travaillent chacun sur une copie locale et
• collaborer à plusieurs sans écraser le travail des autres (Collaboration) doivent se connecter au serveur pour récupérer les mises à jour ou envoyer leurs
1.3 Types de systèmes de gestion de versions modifications.

Gestion de versions locale (Local VCS) Gestion de versions distribuée (Distributed VCS – ex : Git)

Tout est stocké sur une seule machine. Contient : La gestion de versions décentralisée est un système où chaque contributeur
possède une copie complète du projet, avec son historique. Cela permet de
• le fichier de travail (ex. ton code), travailler indépendamment et hors-ligne, puis de synchroniser les modifications
• l’historique des versions.
avec un dépôt distant (ex. : GitHub, GitLab), favorisant ainsi la collaboration • Fonctionne hors-ligne (local), puis synchronisation possible
souple et distribuée. • Suivi précis des modifications (Si un bug apparaît, tu peux voir quelle ligne
l’a introduit, par qui et quand.)

2.3 Services d’hébergement Git :

• GitHub (projets collaboratifs ou open source)

• GitLab (solution privée ou interne)
• Bitbucket (souvent couplé à Jira/Confluence d’Atlassian) idéal pour les
équipes agiles

3. Installation et Configuration

3.1 Vérifier l’installation de Git

1.4 Gestion de versions hors développement Vérifier dans le terminal que git est bien installé:
La gestion de versions ne se limite pas au développement logiciel. Elle est
présente dans de nombreux outils du quotidien. Par exemple, les wikis comme
Wikipédia ou Moodle permettent des modifications collaboratives avec un
historique des changements. Les outils bureautiques en ligne, tels que Google
Docs ou Microsoft Office 365, offrent également un suivi des versions pour 3.2 Installation sous Windows
revenir à un état antérieur d’un document. En programmation, on distingue les
systèmes centralisés (ex. : SVN) avec un seul dépôt, et les systèmes décentralisés Si ce n’est pas le cas, installez-le : Go to the official site: [Link]
(ex. : Git) où chaque utilisateur dispose d’une copie complète du projet. [Link]/install/windows

2. Présentation de Git

1.1 Qu’est-ce que Git ?

Git est un logiciel libre de gestion de versions. Il permet de suivre, enregistrer et

gérer l’évolution d’un ensemble de fichiers, généralement le code source d’un
projet. Git est multi-langage, multi-plateforme (Windows, macOS, Linux) et
permet le travail collaboratif.

2.2 Pourquoi utiliser Git ?

• Travail collaboratif sans écraser les contributions

• Possibilité de revenir à n’importe quelle version (Chaque version
enregistrée dans Git (appelée un commit) peut être retrouvée et 3.3 Outils disponibles : Run the Installer
restaurée.) 1. Double-click the .exe file you downloaded
 2. The installer will open — click Next through the option and then FINISH • git config --local : S’applique uniquement au dépôt Git courant.’

Pour voir la configuration actuelle de Git : git config –list

4. Premiers pas avec Git (Hafsa)

Un dossier de projet est un répertoire où tu organises les fichiers de ton

application web.

4.1 Créer un dossier de projet

• mkdir monprojet
• cd monprojet

4.2 Initialiser un dépôt Git

Un dépôt Git (Git repository) est un dossier dans lequel Git suit les modifications
apportées aux fichiers.
You can now use:
git init : Cela crée un répertoire .git caché qui contient toutes les informations
• Git Bash (It’s a terminal installed with Git) nécessaires pour suivre l’historique du projet. Par défaut, Git crée une branche
• Or use Git in CMD / PowerShell nommée master.
• le terminal intégré de Visual Studio Code
4.3 Créer des fichier (exemple HTML) dans ton dossier de projet :
3.4 Configuration de base

Git utilise ton nom et ton email pour identifier l’auteur de chaque commit.

• Si tu ne les définis pas, Git te les demandera lors du premier commit.

• Cette configuration est obligatoire pour commencer à utiliser Git
correctement.

Ton nom sera attaché à chacun de tes commits. Configure-le avec : git config --
global [Link] "Your Name"

Ton adresse e-mail sera également associée à tes commits. Configure-la avec : git
4.4 Vérifier l’état du dépô
config --global [Link] "you@[Link]"
git status, Cette commande affiche :
Les niveaux de configuration Git : • Les fichiers non suivis (untracked) : Ce sont des fichiers présents dans le
dossier du projet, mais que Git ne prend pas encore en compte, car ils
• git config –system : S’applique à tous les utilisateurs de la machine. n’ont pas été ajoutés à la zone de staging (git add).
• git config –global : S’applique à l’utilisateur courant (ton compte).
 • Les fichiers suivis (tracked) : Ce sont des fichiers que Git surveille déjà. Ils • git commit -m "message" → Enregistre les fichiers déjà ajoutés
ont été ajoutés au dépôt (via la branche main ou master) et font partie de (staged) avec un message.
l’historique du projet. Toute modification sera détectée par Git et pourra • git commit -a -m "message" → Enregistre tous les fichiers suivis
être incluse dans un prochain commit. modifiés sans passer par git add.
• git log → Affiche l’historique de tous les commits.
Ls : cette commande affiche la liste des fichiers et dossiers présents dans le • git log –stat : → voir quels fichiers ont été modifiés dans chaque
répertoire courant. commit.
3. Pour suivre un fichier avec Git : Il faut l’ajouter à la zone de staging avec :
4.7 Cloner un dépôt
git add nom_du_fichier Une copie (fork) sur GitHub reste sur la plateforme, mais pour pouvoir travailler
localement, il faut en faire un clone.
4.5 Ajouter des fichiers au staging
Cloner signifie créer une copie complète du dépôt sur ton ordinateur, incluant
La staging area est une zone d’attente où tu prépares les modifications que tu
tout l’historique et les versions des fichiers.
veux inclure dans ton prochain commit.

Pour cloner un dépôt, va sur sa page GitHub, clique sur le bouton vert « Code »,
copie l’URL (en HTTPS ou SSH), puis utilise la commande git clone URL_du_dépôt
dans ton terminal.

4.8 Pousser des modification

4.5 Faire un commit Après avoir effectué plusieurs modifications localement (et les avoir commités),
Un commit est comme un point de sauvegarde dans ton projet. Il enregistre on peut les envoyer vers le dépôt distant (par exemple, un fork sur GitHub) avec
un instantané de l’état de tes fichiers à un moment donné, accompagné d’un la commande : git push origin main.
message décrivant les modifications. Cela pousse les changements de la branche main locale vers la branche main du
Commandes utiles pour les commits : dépôt distant nommé origin.
Une fois la commande exécutée, tu peux aller sur GitHub pour vérifier que le 5.1 Définition d’une branche
dépôt a bien reçu un nouveau commit.
Une branche est comme un espace de travail indépendant, où tu peux faire des
4.9 Créer une Pull Request modifications ou tester des idées sans impacter la version principale du projet.

Une fois les changements poussés sur le fork : Lorsqu’un dépôt est créé, une branche par défaut est automatiquement générée,
et son pointeur se déplace vers le dernier commit à chaque nouvelle validation.
• Clique sur « Contribute » puis « Open pull request »
5.2 Branche par défautL

orsqu’on initialise un dépôt avec git init, Git crée par défaut une branche appelée
master, sauf si une branche différente (comme main) a été définie avec : git config
--global [Link] main

5.3 Créer et lister des branches

Quand tu veux ajouter une nouvelle fonctionnalité sans risquer de perturber le

projet principal, tu peux créer une branche dédiée.

git branch hello-friends : Cela crée une nouvelle branche appelée hello-friends. Tu
travailles ainsi en parallèle, dans un espace isolé

• Ajoute un titre clair et une description des modifications (important pour

les mainteneurs).
• Clique sur « Create pull request ».

Après avoir créé une nouvelle branche: git branch, Cette commande affiche la liste
des branches existantes, avec un * indiquant la branche actuellement active.

5.4 Vérifier la branche active

5. Gestion des branches (Nassima) Pour vérifier sur quelle branche tu travailles actuellement, utilise la commande
: git status
5.5 Changer de branche

Quand tu crées une nouvelle branche avec git branch, tu ne changes pas
automatiquement de branche. Tu restes sur la branche active (souvent master),
identifiée par le pointeur spécial HEAD.

Par défaut, HEAD pointe vers la branche active (souvent master). Pour changer de
branche, utilise : git checkout hello-friends ou git switch hello-friends

Ces commandes déplacent HEAD pour qu’il pointe vers la branche hello-friends,
ce qui signifie que tu travailles désormais dans cette branche.

5.6 Travailler sur plusieurs branches

Tant que tu ne fais pas de merge, chaque branche reste indépendante. Tu peux
ainsi développer différentes fonctionnalités en parallèle en toute sécurité.

5.7 Fusionner des branches

La fusion (merge) en Git consiste à intégrer les modifications d’une branche dans
la branche courante, en combinant leurs historiques depuis leur point de
divergence.

Tu peux maintenant faire des modifications sans impacter la branche principale

(master), ce qui te permet de travailler en toute sécurité sur une nouvelle
fonctionnalité ou un correctif.

Vous pouvez modifier des fichiers dans une branche, puis basculer dans une autre
et continuer le travail sans conflit.

git checkout master

vi hello-friends-images
• git merge : fusionne une branche dans la branche courante.
git commit -a -m "made other changes • git merge --no-ff : crée toujours un commit de fusion, même si la fusion
pourrait se faire sans.
Cela ajoute un nouveau commit à la branche master sans affecter la branche
• git merge --squash : combine toutes les modifications de l’autre branche
Testing.
en un seul commit.
 • git merge --abort : annule une fusion en cours lorsqu’il y a des conflits. • Gestion des configurations système et projet

5.8 Supprimer une branche 4. Plateforme collaborative

Supprimer une branche déjà fusionnée : Supprimer une branche déjà fusionnée GitLab est généralement installé sur une machine virtuelle hébergée sur un
serveur web et repose sur une base de données pour stocker les informations du
Supprimer une branche non fusionnée (forcément) : git branch -D nom-de- projet.
branche
5. Interface d’administration
6. Présentation de GitLab (Oumaima)
Permet de gérer l’ensemble du projet via le web :
6.1 GitLab : définition
• Création et suppression de dépôts
• Gestion des utilisateurs et des droits d’accès
• Visualisation graphique : commits, branches, tags, fichiers
• Documentation du projet (README, Wiki)
• Gestion des issues (suivi des tâches et bugs)
• Collaboration via forks et merge requests (comme sur GitHub)
GitLab est une plateforme open source et collaborative basée sur Git, permettant
d’héberger du code, des projets web et de la documentation. 6.3 Étapes pour créer un projet GitLab

6.2 Fonctionnalités principales Avant d’entamer la partie de création de projet, il est nécessaire d’avoir un
compte GitLab. Voici les étapes a suivre :
GitLab possède une interface proche de GitHub, mais offre de nombreuses
fonctionnalités intégrées pour gérer tout le cycle de vie d’un projet. 1. Accéder au site GitLab [Link]
2. Cliquer sur Register / S’inscrire
1. Outils de gestion de projet 3. Choisir la méthode d’inscription
4. Remplir les informations demandées
• Organisation et planification des tâches 5. Vérifier l’adresse email
• Priorisation du travail
• Suivi d’avancement

2. Automatisation

• Tests automatisés
• Déploiement continu
• Monitoring des pipelines

3. Sécurité et configuration

• Analyse de sécurité applicative

 7. Manipulation des dépôts avec GitLab (Abdelilah)

7.1 Création de dépôts GitLab

1. Cloner le dépôt GitLab sur votre machine

Depuis GitLab, vous copiez l’URL HTTPS du projet, puis dans votre terminal :

git clone [Link]

cd nom_projet

➡️ Cela télécharge le projet sur votre ordinateur et vous place dans son dossier.

2. Configurer Git avec votre compte GitLab

Pour créer un projet GitLab :
Vous devez associer votre identité Git à votre compte GitLab :
1. Cliquer sur le bouton "New Project" ou "Create Project".
git config --global [Link] "votre_email@[Link]"

git config --global [Link] "Votre Nom"

➡️ Ces informations apparaîtront dans vos commits et seront visibles sur GitLab.

3. Ajouter ou modifier des fichiers dans le projet

2. Choisir le type de projet :
Exemple : créer un fichier [Link] contenant "Bonjour" :
• Projet vide (Blank project)
• Import depuis un dépôt existant (GitHub, Bitbucket, GitLab…) echo "Bonjour" > [Link]
• Cloner un modèle (Template)
3. Saisir les informations du projet : git status
• Nom du projet
• Description (optionnelle) ➡️ Montre les fichiers créés ou modifiés.
• Visibilité : Public, Internal ou Private 4. Ajouter les fichiers au staging
(Le nom du projet devient celui du dépôt. Sélectionnez l’option “Public” pour Pour dire à Git quels fichiers vous voulez sauvegarder :
permettre la lecture par les autres stagiaires)
git add [Link]
4. Cliquer sur "Create Project" pour valider.
➡️ Le fichier est maintenant prêt à être commit.
Quand tu crées un projet sur GitLab, celui-ci devient accessible via une URL (un
lien) du type : [Link] 5. Enregistrer un commit
Créer une nouvelle version du projet avec un message : 7.3 Git Tag

git commit -m "Ajout du fichier [Link]" Un tag est un marqueur fixe qui pointe vers un commit précis afin d’identifier une
version importante du projet (comme une release). Contrairement aux branches,
➡️ Le commit contient maintenant votre fichier et son historique. il ne change pas et ne possède pas d’historique : il sert uniquement de point de
repère dans l’évolution du code.
6. Envoyer (push) les changements vers GitLab
• Créer un tag :
Pour mettre à jour votre dépôt distant :
git tag <nom>
git push • Créer un tag annoté :
git tag -a <nom> -m "message"
➡️ Le commit sera visible sur GitLab. • Lister les tags :
git tag
7. Vérifier sur GitLab • Envoyer un tag vers le dépôt distant :
git push origin <tagname>
Une fois le push effectué :
Exemple : git push origin v1.4
• Le fichier [Link] apparaît dans votre dépôt GitLab. • Supprimer un tag :
git tag -d <tagname>
• Son contenu ("Bonjour") est visible. Exemple : git tag -d v1.4

• L’historique affiche votre commit. 8. Gestion des conflits de fusion avec Git / GitLab (Salah)

7.2 git fetch 8.1 Définition d’un conflit de fusion

La commande git fetch permet de récupérer les mises à jour qui existent sur le Un conflit de fusion survient lorsque deux branches modifient la même zone d’un
serveur distant sans les fusionner automatiquement dans ta copie locale. Il Ne même fichier.
modifie pas ton code local tant que tu ne fais pas un merge ou un pull. Git ne peut pas choisir quelle version garder, et c’est au développeur de résoudre
manuellement le conflit en choisissant le contenu final.

8.2 Identifier un conflit (statut, marqueurs)

8.3 Exemple pour provoquer un conflit (2 branches)

Exemple Conflits de fusion (momkin dir (salah) l’exemple li bghiti hna, ghir tkon
b7al li kayna f cours) :

• Initialisation du dépôt et premier commit

o git init : initialise un dépôt Git vide.

o echo "ligne A" > [Link] : crée le fichier [Link].
 o git add . puis git commit -m "premier ajout du [Link]" : enregistre
le fichier dans l’historique.

• Création d’une branche de correction

o git checkout -b fixbug : crée et bascule sur la branche fixbug.

o Modification du fichier (ligne B), puis git commit -m "Modification
du [Link]".

• Retour sur la branche principale

o git checkout master : retour sur master.

o Modification du même fichier (ligne C), puis git commit -m
"Modification du [Link] à partir du master". 9. Collaboration et contribution avec GitLab (Oumaima)

• Fusion et apparition du conflit 9.1 Fork GitLab : contribution à un projet

o git merge fixbug depuis master : tentative de fusion de fixbug 1. Pourquoi utiliser un fork ?
dans master.
Lorsque tu veux contribuer à un projet sur lequel tu n’as pas les droits d’écriture,
o Conflit dans [Link] car les deux branches ont modifié les mêmes tu dois d’abord faire un fork. Le fork crée une copie personnelle du projet dans
lignes (Git ajoute les marqueurs <<<<<<<, =======, >>>>>>>). ton propre espace GitLab. Tu peux alors modifier ta copie, puis proposer tes
changements via une Merge Request.; ce n’est pas une commande Git, mais une
• Résolution du conflit fonctionnalité offerte par GitLab (et GitHub).

o Ouverture du projet dans VS Code : code .. 2. Créer un fork sur GitLab

o Choix de la version à garder dans le fichier (Accept Current,
Accept Incoming, Accept Both, …). 1. Aller sur le projet d’origine.

• Validation de la fusion 2. Cliquer sur Fork.

o git commit -a -m "conflit résolu!" : enregistre le résultat après

résolution.
o git log --oneline : affiche l’historique, avec le commit « conflit
résolu » suivi des commits précédents (fixbug, master, etc.).
3. Choisir :
8.4 Résoudre un conflit
• le nom du fork,
• le namespace,
• la visibilité (souvent private ou public).

4. GitLab crée une copie du projet dans ton espace personnel.

➡️ Tu obtiens ton propre dépôt : 4. Optionnel : comparer les changements
[Link]
5. Remplir :
Dans ton dépôt local, tu peux afficher les dépôts distants configurés avec :
• Titre
git remote -v , On obtient généralement : • Description

• origin → le projet original (lecture seule) 6. Cliquer sur Create merge request
• ma_copie → ton fork (lecture + écriture)

Si ton fork n’est pas encore ajouté, tu l’ajoutes avec :

git remote add ma_copie [Link]

• ma_copie : nom que tu choisis pour identifier ton fork.

• URL : l’adresse HTTPS du fork sur GitLab
9.3 Collaborer sur un dépôt GitLab (Salah)
Une fois que tu as fait un commit, tu pousses vers ton fork : git push ma_copie
Par défaut, seul le créateur d’un dépôt peut y ajouter des commits.
Important : tu ne peux pas pousser vers le projet original si tu n’as pas les droits. Pour qu’un autre développeur puisse contribuer, deux solutions existent :

Tu peux renommer un dépôt distant si nécessaire : git remote rename • Forker le dépôt, puis proposer ses modifications via une Merge Request.
ancien_nom nouveau_nom • Obtenir une permission d’écriture pour pousser des commits directement
dans le dépôt.
9.2 Merge Request GitLab
9.4 Ajouter un développeur à un projet GitLab (Salah)
Une Merge Request (MR) est une demande de fusion. Elle peut être créée de
deux façons : via les commandes Git ou directement depuis l’interface GitLab. 1. Ouvrir le dépôt puis aller dans Paramètres (Settings).

Étapes de Création une Merge Request directement sur GitLab 2. Cliquer sur Members.
3. Entrer le nom d’utilisateur ou l’adresse email du développeur.
1. Aller dans le menu gauche : Merge Requests 4. Choisir un rôle (permission) à attribuer pour pousser des commits, le rôle
Maintainer est requis.
2. Cliquer sur New merge request
5. Valider et vérifier que le développeur peut effectivement pousser un
3. Choisir : commit dans la branche de travail (ex : master).
9.5 Ajouter un commit dans le dépôt d’un autre développeur (Salah)
• Source branch = votre branche (ex : my-new-branch) • Cloner le dépôt de l’autre personne avec git clone <url>.
• Target branch = branche de destination (souvent main ou • Vérifier que la copie locale est à jour : git pull.
master) • Créer ou modifier un fichier, puis l’ajouter à l’index :
git add <fichier>.
 • Faire un commit :
git commit -m "message".
• Envoyer les modifications vers le dépôt de l’autre développeur :
git push.
• Aller sur GitLab dans la section Commits pour vérifier l’apparition du
nouveau commit.

10. Comparaison GitHub vs GitLab (Hafsa)

11. Conclusion (Récapitulatif des commandes Git)