ADOPTER L’APPROCHE AGILE

PARTIE 4: METTRE EN ŒUVRE DES OUTILS DE GESTION

DE VERSIONS ET DE MESURE DE LA QUALITÉ DU CODE
CHAPITRE 1: MANIPULER LES OUTILS DE GESTION DE
VERSIONS (GIT/GITLAB)
 CHAPITRE 1: MANIPULER LES OUTILS DE GESTION DE
VERSIONS (GIT/GITLAB) .

I. Gestion de versions
II. Présentation de Git
III. Installation et manipulation de Git.
IV. Présentation des fonctionnalités de Gitlab
V. Manipulation des commandes de base de Git (Git bash)
VI. Notion de branches et gestion des conflits de fusion avec Git
VII.Le fork avec Gitlab

2
1
GESTION DE VERSIONS

3
1. GESTION DE VERSIONS
Qu'est-ce qu’un gestionnaire de versions ?

 Un gestionnaire de versions est un programme qui permet aux

développeurs de conserver un historique des modifications et
des versions de tous leurs fichiers.

 L’action de contrôler les versions est appelée "VERSIONING".

4
1. GESTION DE VERSIONS
Gestion de versions :
 Les logiciels de gestion de version VCS (version control system)
permettent aux équipes de sauvegarder et d'archiver le code
source de leurs projets.

 Ils permettent d'effectuer des révisions et des modifications

dans le dépôt plus facilement ou de restaurer des anciennes
versions si une erreur de conception survient.
5
1. GESTION DE VERSIONS
 Trois grandes Fonctionnalités :

 Revenir à une version précédente de votre code en cas de problème.

 Suivre l’évolution de votre code étape par étape.
 Travailler à plusieurs sans risquer de supprimer les modifications
des autres collaborateurs.

6
1. GESTION DE VERSIONS
 Elle peut s'appliquer à un fichier individuel (exemple : un
document texte) ou à plusieurs fichiers d'un projet;
 Elle peut se faire au niveau individuel ou dans des groupes
 On peut diviser les systèmes de gestion de versions en trois
catégories :
a. Gestion de versions locale,
b. Gestion de versions centralisée,
c. Gestion de versions distribuée ou décentralisée.
7
1. Gestion de versions :
1. Gestion de versions locale:

Dans un système de gestion de versions locale, le

dépôt(code ou code de source) avec les changements
se trouve physiquement sur la même machine qui
stocke les fichiers tracés

8
1. Gestion de versions :
1. Gestion de versions locale:
 Avantage: garder le traçage des changements
à proximité des fichiers de travail, sans qu'il soit
nécessaire de synchroniser avec une autre machine
(un serveur distant).

 Inconvénient : la gestion locale pure est plus limitée

en ce qui concerne la possibilité de collaborer et
intégrer les changements d'autres personnes.

9
1. Gestion de versions :
2. Gestion de versions centralisée:
 le dépôt qui contient les informations sur les
changements se trouve sur une autre machine par
rapport aux fichiers de travail.

 Le cas de figure le plus commun consiste à garder le

dépôt des changements sur un serveur centralisé,
tandis que les différents ordinateurs individuels des
personnes qui participent au projet ne gardent que la
dernière version des fichiers de travail.
10
1. Gestion de versions :
2. Gestion de versions centralisée:
 Avantage: centraliser les changements à un seul endroit, ce qui
permet de libérer de l'espace dans les ordinateurs de travail.

 Inconvénient: ce changement ne se propage en général pas de

manière automatique comme dans les systèmes de synchronisation
de fichiers de type cloud.
 Les autres personnes connectées au dépôt peuvent en général être
avertis de la nouvelle version de manière plus ou moins explicite. Ils
seront au courant des changements en tout cas lorsqu'ils essayeront
de mettre à jour leur projet par rapport au dépôt central.

11
1. Gestion de versions :
3. Gestion de versions distribuée ou
décentralisée:
 La gestion de versions distribuée combine la gestion
de version locale et centralisée en créant deux dépôts
des changements :

1.Le premier se trouve sur la même machine des fichiers

de travail.
2.Le deuxième se trouve dans une autre machine, souvent
un serveur ou une plateforme cloud comme GitHub ou
GitLab, qui s'occupe de centraliser les changements
12
1. Gestion de versions :
3. Gestion de versions distribuée ou
décentralisée:
 La communication/synchronisation des changements se
fait donc en deux passages :

1. Entre les fichiers de travail et le dépôt local.

2. Entre le dépôt local et le dépôt centralisé. Ce passage
ultérieur permet une plus grande flexibilité et ouvre
également des possibilités supplémentaires, surtout d'un
point de vue collaboratif.
13
1. Gestion de versions :

 La personne peut apporter plusieurs changements au dépôt local avant de les envoyer au
dépôt centralisé. Elle peut également décider de synthétiser plusieurs changements dans
un seul changement plus conséquent, et envoyer seulement ce changement plus
conséquent au dépôt centralisé.
 La personne dispose de l'ensemble de l'historique des changements même si elle n'est pas
connectée au dépôt central, ce qui lui permet de travailler avec les versions en autonomie
même en absence d'une connexion directe au dépôt central.
 La personne peut décider de se débrancher du dépôt central et rendre le projet
indépendant, tout en gardant l'historique jusqu'à ce point.
 Le projet peut à ce moment devenir un autre dépôt central et continuer de manière
indépendante du dépôt central originaire.
14
 2
PRÉSENTATION DE GIT
15
2. PRÉSENTATION DE GIT
 Git est un système de contrôle de version open-source spécifique créé par
Linus Torvalds en 2005.

 Concrètement, Git est un système de contrôle de version distribué, ce qui

signifie que l’ensemble de la base du code et de l’historique est disponible sur
l’ordinateur de chaque développeur, ce qui permet des branchements et une
fusion faciles.
 D’après un Sondage auprès des développeurs de Stack Overflow, plus de 87%
des développeurs utilisent Git.
 Git est multi-langages et multi-plateformes. Git est devenu à l'heure actuelle
un quasi-standard 16
2. PRÉSENTATION DE GIT
 Version : contenu du projet à un moment de son cycle de vie.
 Dépôt(repository) : l’historique du projet, contenant toutes ses versions.
 Branche (branch) : variante d’un projet.

 Un dépôt Git correspond physiquement à un ensemble de fichiers rassemblés

dans un répertoire .git.
 Sauf cas particulier, il n'est pas nécessaire d'intervenir manuellement dans ce
répertoire.

17
2. PRÉSENTATION DE GIT
Lorsqu'on travaille avec Git, il est essentiel de faire la
distinction entre trois zones:

 Le répertoire de travail (working directory) :correspond

aux fichiers actuellement sauvegardés localement.

 L'index ou staging : area est un espace de transit.

 HEAD : correspond aux derniers fichiers ajoutés au dépôt.

18
 3
INSTALLATION DE GIT
19
3. INSTALLATION DE GIT

 Installer git via le lien https://git-scm.com/downloads

 Redémarrez votre terminal.

20
3. INSTALLATION DE GIT

 Personnaliser votre environnement Git en exécutant les deux

commandes suivantes :

21
3. INSTALLATION DE GIT
Les états des fichiers
Git gère trois états dans lesquels les fichiers peuvent résider:

 Modifié (“modified”): signifie que vous avez modifié le fichier mais qu’il n’a pas
encore été validé en base.
 Indexé (“staged”): signifie que vous avez marqué un fichier modifié dans sa
version actuelle pour qu’il fasse partie du prochain instantané du projet.
 Validé (“committed”): signifie que les données sont stockées en sécurité dans
votre base de données locale.

22
3. INSTALLATION DE GIT
Les zones de travail
Les états de fichiers sont liés à
des zones de travail dans Git.
En fonction de son état, un
fichier va pouvoir apparaitre
dans telle ou telle zone de
travail.
Tout projet Git est composé de
trois sections : le répertoire de
travail, la zone d’index et le
répertoire Git.
23
3. INSTALLATION DE GIT
Les zones de travail
 Le répertoire de travail (working directory) correspond à une extraction
unique d’une version du projet. Les fichiers sont extraits de la base de
données compressée située dans le répertoire Git et sont placés sur le disque
afin qu’on puisse les utiliser ou les modifier.
 La zone d’index (staging area) correspond à un simple fichier, généralement
situé dans le répertoire Git, qui stocke les informations concernant ce qui fera
partie du prochain instantané ou du prochain “commit”.
 Le répertoire Git (repository) est l’endroit où Git stocke les méta-données et
la base de données des objets de votre projet. C’est la partie principale ou le
coeur de Git.
24
3. INSTALLATION DE GIT
Principales commandes git:

• git init : crée un nouveau dépôt vide à l'emplacement courant.

• git status : affiche les différences entre le répertoire de travail, l'index et HEAD.
• git add : ajoute des fichiers depuis le répertoire de travail vers l'index.
• git commit : ajoute des fichiers depuis l'index vers HEAD.
• git clone : clone un dépôt existant local ou distant.
• git pull : récupère des modifications depuis un dépôt distant vers HEAD.
• git push : publie des modifications depuis HEAD vers un dépôt distant.

25
 4
Présentation de Gitlab
26
3. Présentation de Gitlab

 Gitlab est une plateforme open source et collaborative de

développement basé sur Git.

 Gitlab permet d'héberger des projets web, du code, et de la

documentation.

27
3. Présentation de Gitlab

 Ouvrir l’interface web GitLab sur : https://gitlab.com

 Ajoutez un mot de passe à votre compte GitLab, depuis la page
de paramètres de votre compte GitLab
 Après la connexion avec le compte Gitlab ,créer un projet cliquer
sur create blank project ou newProject/repository

28
3. Présentation de Gitlab

 git add --all .

 git commit -m"First commit"
 git push origin main

29
 5
Gestion des Branches
GIT
30
5. Gestion des Branches GIT

Branches
 Les branches sont utilisées pour développer des fonctionnalités isolées des
autres.
 La branche master est la branche par défaut quand vous créez un dépôt.
 Utilisez les autres branches pour le développement et fusionnez ensuite à la
branche principale quand vous avez fini.

31
5. Gestion des Branches GIT

Gestion branches avec commandes git

créer une nouvelle branche nommée B1 et passer dessus pour l'utiliser
 git checkout -b B1
retourner sur la branche principale
 git checkout master
et supprimer la branche
 git branch -d B1
une branche n'est pas disponible pour les autres tant que vous ne l'aurez pas
envoyée vers votre dépôt distant
 git push origin <branch>
32
5. Gestion des Branches GIT

Gestion branches avec commandes git

pour mettre à jour votre dépôt local vers les dernières validations, exécutez la
commande
 git pull
dans votre espace de travail pour récupérer et fusionner les changements distants.
pour fusionner une autre branche avec la branche active (par exemple master),
utilisez
 git merge <branch>

33
5. Gestion des Branches GIT

Gestion branches avec commandes git

dans les deux cas, GIT tente d'auto-fusionner les changements.
Malheureusement, ça n'est pas toujours possible et résulte par des
conflits. Vous devez alors régler ces conflits manuellement en
éditant les fichiers indiqués par git. Après l'avoir fait, vous devez les
marquer comme fusionnés avec
 git add <nomdufichier>
après avoir fusionné les changements, vous pouvez en avoir un
aperçu en utilisant
34
 git diff <source_branch> <target_branch>
5. Gestion des Branches GIT

Gestion branches avec commandes git

vous pouvez annuler les changements locaux en utilisant cette
commande
 git checkout -- <nomdufichier>
cela remplacera les changements dans votre arbre de travail avec le
dernier contenu du HEAD. Les changements déjà ajoutés à l'index,
aussi bien les nouveaux fichiers, seront gardés.

35
5. Gestion des Branches GIT

Gestion branches avec commandes git

Si à la place vous voulez supprimer tous les changements et
validations locaux, récupérez le dernier historique depuis le serveur
et pointez la branche principale locale dessus :

 git fetch origin

 git reset --hard origin/master

36
 6
Les meilleurs logiciels de
gestion des versions
37
6. Les meilleurs logiciels de gestion des
versions
 BeBackup est tout d’abord un logiciel de sauvegarde Cloud conçu
pour les prestataires IT et les services informatiques
d’entreprises.
 La conviction de BeBackup est de proposer un service sécurisé
tout en vous laissant la liberté sur le choix de l’hébergement de
vos sauvegardes.
• versioning illimité paramétrable,
• solution flexible,
• coûts d’hébergement parmi les plus bas du marché,
• copie locale et restaurations rapides des sauvegardes. 38
6. LES meilleurs logiciels de gestion des versions

 Bitbucket est un système de contrôle de version (VCS) ayant pour

objectif d’optimiser la gestion des projets de développement
informatique.
 Bitbucket va au-delà d’un simple outil de gestion du code
centralisé : les développeurs disposent d’un endroit unique où
planifier des projets, collaborer autour du code, tester et déployer.
• dépôts privés gratuits illimités,
• conçu pour la collaboration,
• s’intègre à de nombreux outils (jira, slack, MS teams, etc.),
• sécurité renforcée grâce au cryptage des données. 39
6. LES meilleurs logiciels de gestion des versions
 GitHub est le système de contrôle de version décentralisé le plus
connu du marché. L’outil racheté par Microsoft en 2018 est
particulièrement apprécié par les développeurs qui travaillent sur
des logiciels open source.

• énorme base d’utilisateurs,

• tableau de bord personnel pour suivre les issues et pull requests,
• création de plusieurs « branches locales » et indépendantes,
• fonctionnalités de collaboration (attribution de tâches, autorisations, rôles,
etc.).
40
6. LES meilleurs logiciels de gestion des versions
 Microsoft Azure Backup, est un système de contrôle de version de
Microsoft. Précédemment connu sous le nom de Team Foundation
Server (TFS), il propose un ensemble d’outils de développement
hébergé sur site.
• permet une intégration continue,
• version gratuite pour les particuliers et les petites équipes,
• administration facile et intégration possible avec d’autres produits
Microsoft,
• possibilité d’être utilisé comme backend pour plusieurs IDE.
41
6. Les meilleurs logiciels de gestion des versions
Mercurial est un outil de gestion de contrôle de source décentralisée
codé en Python. La solution aide vos équipes dans la gestion de leurs
projets et permet de retrouver l’historique complet des modifications
apportées.

• capacités avancées de branchement et de fusion,

• interface simple et intuitive,
• système collaboratif décentralisé,
• haute performance et évolutivité.
42
 7
Le fork avec Gitlab
43
7. Le fork avec Gitlab

 Un fork : est une copie d'un dépôt. Ceci est utile lorsque vous
souhaitez contribuer au projet de quelqu'un d'autre ou démarrer
votre propre projet basé sur le sien.

 fork n'est pas une commande dans Git, mais quelque chose
d'offert dans GitLab

 Une copie complète du référentiel d'origine est disponible mais

nous ne sommes pas autorisés à modifier l'origine.
44
7. Le fork avec Gitlab

 Un fork est une copie d’un dépôt. Forker un dépôt vous permet
d’expérimenter librement des modifications sans toucher au
projet original.

 les forks sont utilisés soit pour proposer des modifications sur
le projet de quelqu’un d’autre ou pour utiliser le projet de
quelqu’un d’autre comme point de départ pour une nouvelle
idée.
45
7. Le fork avec Gitlab

 Proposer des modifications sur le projet de quelqu’un d’autre

 Un exemple génial d’utilisation des forks est de proposer des
modifications pour la correction de bugs. Plutôt que de signaler
un problème que vous trouvez, vous pouvez :
 Forker le repository
 Réparer le bug
 Proposer une pull request au propriétaire du projet.
Si le propriétaire du projet aime votre travail, il pourrait prendre
votre réparation pour la ramener dans le dépôt original ! 46