Ingénierie Logicielle – Gestion de

versions
2ACI - ISITD – 2023/2024

Pr. Meriem HNIDA

mhnida@esi.ac.ma
Objectifs

▪ Comprendre l’intérêt de la gestion de version dans un projet de développement de

logiciel

▪ Apprendre le vocabulaire associé au SGV (SCM).

▪ Comprendre le principe de numérotation de version d’un logiciel

▪ Maîtriser la différence entre système de gestion de versions local, centralisé et distribué.

▪ Maitriser et comprendre les commandes utilisées.

2
 Gestion de configuration/ gestion de versions

La gestion de versions est une compétence nécessaire pour le développement de logiciel. Elle sépare nettement les
rôles des acteurs impliqués dans le projet

Permettre à plusieurs Pouvoir travailler à plusieurs Maintenir plusieurs

membres d'une équipe de simultanément et à distance environnements (Dev, Test,
collaborer et de gérer sur le même projet Prod) en utilisant des
l'évolution d'un logiciel. branches parallèles

La gestion de versions - Consultant(e)s DEVOPS

apparait dans le profil - Chef de projet
- Ingénieur DevOps
- Ingénieur Etude et Développement.

3
Pourquoi un système de gestion de versions?

▪ Pour permettre aux membres d’une équipe travaillant

sur un projet de développement logiciel de collaborer.
Collaboration

▪ Pour être capable de gérer les différentes versions Versionning

d’un logiciel au cours du temps.

▪ Pour être capable de revenir à une version antérieure

du projet.
Rollback

▪ Pour garder un historique des modification (date, nom

du développeur, zone de codes modifiés Timeline

4
Gestion de configuration/ gestion de versions

QUI:
▪ Qui est responsable de cette anomalie (bug)?
▪ Qui a développé cette fonctionnalité ?
▪ Qui a modifié ce fichier ?

QUOI:
▪ Quelle est la dernière version de l’application ?
▪ Quelle version a-t-on distribuée à ce client ?

QUAND:

▪ Quand est-ce que la distribution a été créée ?

▪ Quand est-ce qu’il y a eu cette modification ?

5
Types de systèmes de gestion de versions

▪ Les systèmes de gestion de versions locaux.

▪ Les systèmes de gestion de versions centralisés.

▪ Les systèmes de gestion de versions distribués.

Source: https://www.openhub.net/repositories/compare
- Novembre 2020
La gestion de versions - Le modèle local

Question: quel est le problème illustré dans le graphique et qu’on

cherche à résoudre en utilisant un système de gestion de versions
local ?

7
La gestion de versions - Le modèle local

Avantages:

▪ Utilise une base de données simple pour conserver

les modifications d’un fichier. (Rapport, projet
personnel, etc…)
▪ Fonctionne dans un système de gestion de fichiers
local.
▪ Fonctionnement offline.

Inconvénients:

▪ Très sensible aux pannes

▪ Un historique de projet linéaire
▪ Ne permet pas la collaboration

8
La gestion de versions - Le modèle centralisé

Centralized Version Control Systems (CVCS)

▪ Un serveur central (dépôt/repository) qui contient tous
les fichiers sous gestion de versions

▪ Chaque utilisateur travaille sur une copie locale (Working

copy) et envoie ses modification sur le dépôt.

▪ L’enregistrement d’une modification d’un élément de

la copie locale provoque une incrémentation de
numéro de révision.

▪ Chaque développeur a un SNAPSHOT instantané.

▪ L’accès au dépôt se fait via un client en mode

commande ou en mode graphique.
9
La gestion de versions - Le modèle centralisé

▪ Le dépôt, référentiel ou 'repository' contient l'ensemble

des fichiers de votre projets et informations associées y
compris l'historique.

▪ Fonctionne en mode connecté.

▪ Envoi des commits hors connexion est impossible!

▪ Parfois, le modèle impose une politique stricte

d'accès (rythme de développement très lent !)

▪ Single Point Of Failure: en cas de panne

sur le serveur, comment récupérer les 10
versions antérieures de son projet ou code
source? http://igm.univ-mlv.fr/~dr/XPOSE2010/gestiondeversiondecentralisee/dvcs-svn.html
La gestion de versions - Le modèle centralisé

▪ Question: entre ces deux situations, que choisirez vous ?

Commettre un état pas stable de son travail : ça ne

compile peut être pas, tous les tests ne sont pas OK, Ne pas effectuer de commit avant d'avoir un
il y a peut être un problème de dépendances dans état stable de son travail ?
les librairies du projet... ?

Vous perturbez le travail des autres membres de Vous prenez le risque de ne pas versionner
l'équipe de développement votre travail pendant des jours voir des
semaines.

Ce dilemme intervient car versionner et partager sont traités comme étant la même opération.
11
La gestion de versions - Le modèle décentralisé

Deux niveaux de dépôt:

1. Dépôt local: utilisé pour la plupart des opérations courantes

(historique d’un projet, différence sur un fichier, commit, etc.)

Rapidité de réponse puisqu’on ne passe pas par un serveur

distant.
Utilisation de Git possible même sans connectivité à Internet.

2. Dépôt distant (Remote): utilisé pour le travail collaboratif et le

partage des modifications en:

▪ Poussant (push)
▪ Intégrant/ tirant (pull)

12
La gestion de versions - Le modèle centralisé

▪ Considère l’information comme une liste de

fichiers et les modifications effectuées sur chaque
fichier dans le temps.

▪ Enregistre les fichiers (File A, File B, File C).

▪ Enregistre les modifications effectuées au cours du

temps.

▪ Rollback qui prend du temps. Le système de gestion de versions enregistre

uniquement les différences (Delta storage)

13
La gestion de versions - Le modèle décentralisé

▪ Des instantanés, pas des différences.

▪ Enregistre les versions de fichiers qui ont été

modifiés à des moments précis au cours du
temps.

▪ Enregistre juste une référence vers le fichier

original qui n’a pas été modifié.
Un mini Système de Gestion de Fichiers

14
GIT ou SVN ? Centralisé ou Distribué ?

Enregistre des Enregistre uniquement la

Snapshots(instantané) différence: ce qui a été
entiers sur chaque version modifié
qu’il contrôle

15
Principe de numérotation des versions

▪ Format: m.n.p

▪ m: numéro de révision majeure

Incrémentation lors d’ajout de fonctionnalités incompatibles avec la version en cours.

▪ n: numéro de révision mineurs

Incrémentation lors d’ajout des fonctionnalité compatibles avec la version courante

(maintenance évolutive)

La parité peut être utilisée pour indiquer la stabilité:

• Pair: version stable.

• Impair: version de développement.

▪ p: numéro de patch
Incrémentation lors de la correction de bugs (maintenance
corrective) 16
HISTOIRE DE GIT

La communauté de linux (Torvalds) développe leur propre outil en se basant sur les leçons apprises
lors de l’utilisation de Bitkeeper.

▪ Vitesse: pas besoin de travailler avec la connexion.

▪ Conception simple.

▪ Support pour les développement non linéaires(Milliers de branches parallèles)

▪ Complètement distribué

▪ Capacité à gérer efficacement des projets d’envergure tels que le noyau Linux

▪ En mode commande / en mode graphique/ Plugin dans les IDE

17
SVN ou GIT

▪ 33 commandes dans SVN 1.6.

▪ plus de 100 commandes de GIT 1.7.
▪ Des concepts très différents.
▪ Une façon de développer très différente.
▪ Ne pas développer avec GIT comme on l'aurait fait avec SVN.
▪ Créer une branche locale est trivial, il faut en abuser.
▪ Sauver des commits pour y revenir plus tard

18
Création et initialisation d’un dépôt GIT

Etape 1 Etape 2

Création d’un dépôt sur Github

• Créer un dépôt local
• Synchroniser le dépôt local

19
Création et initialisation d’un dépôt GIT

Récupération d’un dépôt existant : git clone

Et si le dépôt existe déjà et contient le

code source du projet de mon équipe?

20
 Etats des fichiers dans GIT

Copie de travail correspondant à la

Ficher non suivi en version, non Unmodified
Untracked version dans le dépôt: inchangé et
géré par l’outil GIT
courant

Modified Copie de travail ne

Staged (indexé) Copie de travail marquée pour correspondant pas à la version
être incluse dans le prochain dans le dépôt
commit

21
 Gestion des branches dans GIT

Une branche est une arborescence secondaire, zone de travail, utilisée pour des développements ou des
corrections en parallèle à l’arborescence principale. Ils représentent des révisions officieuses de moindre
importance (e.g. 1.0 et 1.1)

▪ Introduire un nouvelle fonctionnalité, potentiellement longue à développer, sans perturber

le développement principal.

▪ Tester une version sans bloquer les développeurs.

▪ Corriger un problème sur une ancienne version.

▪ Développer plusieurs idées en parallèle.

▪ Gérer sa propre version d’un logiciel.

22
Gestion des branches dans GIT

▪ Une branche est un pointeur/étiquette sur un commit.

▪ Chaque commit pointe vers son prédécesseur.

▪ Ou vers plusieurs commits en cas de merge

▪ Le pointeur avance si on committe dans la branche courante

Exemple de projet avec 3 branches:
Le pointeur (HEAD) sur le dernier commit de la branche
▪ git branch nomDeBranche courante
# création là où est HEAD

• git branch -d nomDeBranche

# pour effacer la branche

23
Distribution et ou tag

▪ Distribution (ou tag) : révisions officielles du projet auquel on associe un symbole (nom
e.g. ”stable, testing, unstable” ou numéro e.g.” 1.0, 2.0, 3.0”)

▪ Communication interne : pour se repérer dans le développement des différentes versions

d’une application

▪ Communication externe : pour informer les utilisateurs/clients des modifications

apportées, pour faciliter le support.

24
Quelques commandes de bases

Il existe une large variété de commandes git disponibles dans le mode bac à sable.

Ajouter ou supprimer un fichier du dépôt

▪ git add monfichier
▪ git rm monfichier

Renommer un fichier
▪ git mv ancienfichier nouveau fichier

Annuler le dernier commit sans perdre les modifications

▪ git reset HEAD^

Annuler le dernier commit et les modifications des fichiers

▪ git reset --hard HEAD^ 25
gestion de versions en
réalité

27
Une panoplie de commandes utiles

PULL RESET REFRENCE CONFLICT COMMIT

REPOSITORY CHERY-PICK STASH BRANCH STAGE

MERGE DIFF HOOK PUSH REMOTE

HASH CHEK OUT LOG FETCH

28