Code Versioning avec

GIT
 Les objectifs de la gestion de sources

• Gérer les activités de lecture, écriture et fusion sur les sources du projet.
• Conserver un historique des modifications apportées aux sources:
• Par qui, quand, quoi ?
• Permettre de revenir en arrière en cas de besoin.
• Permettre de travailler en équipe sur les mêmes sources d'un projet.
• Gérer les accès concurrents.
• Gérer les conflits.
• Permettre de travailler simultanément sur plusieurs versions d’un logiciel.

20
 Les objectifs de la gestion de sources

• Permet de retrouver un fichier source supprimé.

• Fonctionne avec tout type de fichier (.txt, .php, .java, .jpg, .exe, …).
• Garantir la sécurité de la configuration du logiciel:
• Autorisation.
• Confidentialité.
• Intégrité.
• Disponibilité.

21
 Les gestionnaires de sources : Git

• Créé en 2005 par Linus Torvalds pour la gestion des sources du noyau Linux.
• Logiciel libre.
• Multi-plateforme (linux, windows, MacOS, ...).
• Documentations très riches, forums actifs.
• Implémente des protocoles réseaux sécurisés (HTTPS) .
• Interfaces graphiques.
• Intégré dans plusieurs IDE tel que Eclipse.

22
 Gestion de sources avec Git:
Le fonctionnement de base
• Git stocke pour chaque état du projet un instantané de tous les fichiers.
• Un fichier non modifié depuis le dernier état est stocké comme un pointeur vers sa version
précédente.
• La plupart des opération de Git ne nécessitent que des fichiers et des ressources locaux.
Pour la quasi-totalité de ces opérations, aucun appel réseau n’est nécessaire.
• Une somme de contrôle (checksum) vérifie chaque état par une empreinte SHA-1 et
permet ainsi d’assurer l’intégrité des données.
• Toutes les corruptions de fichier ou erreurs de transfert sont détectables.
• Somme de contrôle: 80f2a4d12d5cc8cefeeaf9f0e015f2d11ae43b35
• La réversibilité des opérations est assurée avec Git.

23
 Gestion de sources avec Git:
Définitions
• Repository : ensemble des commits du projet (et les branches, les tags (ou libellés), ...)
• Working copy (ou copie de travail) : contient les modifications en cours (c’est le répertoire
courant)
• Staging area (ou index) : liste des modifications effectuées dans la working copy qu’on
veut inclure dans le prochain commit
• Commit : ensemble cohérent de modifications

24
 Gestion de sources avec Git:
Le fonctionnement de base
• Un projet est composés de 3 fichiers A, B et C.
• Le commit initial permet de checkiner les fichiers A, B et C. Il s’agit de la première version du
projet.
• Les fichiers A et C sont modifiés et les changements sont checkinés. Les versions A1 et C1
sont alors créées. Il s’agit de la deuxième version du projet.
• Git a alors créé un instantané du projet composé des fichiers qui ont été modifiés, A et C. Les
fichiers qui n’ont pas subit de modification ne sont pas stockés, B.

25
 Gestion de sources avec Git : Vocabulaire Git

• Staging - Ajout à l’index: insérer les changements dans l’index Git afin d’indiquer qu’ils
devront être versionnés.
• Commit: consigner les changements dans le dépôt Git local.
• Reset: annuler de manière irréversible des changements effectués.
• Push: envoyer les nouvelles modifications (commits) vers le dépôt distant.
• Pull: récupérer des nouveaux commits depuis le dépôt distant et mettre à jour l’espace de
travail.
• Fetch: récupérer des nouveaux commits depuis le dépôt distant.

26
 Gestion de sources avec Git : Vocabulaire Git

• Merge: créer un nouveau commit ayant pour parents 2 branches fusionnées.

• Rebase: déplacer une suite de commits et la référence associée vers un nouvel
emplacement.
• Cherry pick: récupérer les modifications apportées par un ou plusieurs commits et les
réappliquer à un nouvel emplacement.
• Stash: mettre de coté le travail en cours avant de changer de branche.
• Branche: référence évoluant lors d’un commit.
• Etiquette: référence fixes permettant d’identifier facilement un commit particulier.

27
Git : Installation et
Configuration
Installation et Configuration

• Sous Linux : via le gestionnaire de paquet (ex: apt-get install git)

• Sous OSX : via homebrew (brew install git)
• Sous Windows : via msysgit ([Link]

29
 Installation et Configuration

Configuration:
• La configuration globale de Git est située dans ~/.gitconfig
• La configuration propre à chaque repository Git est située dans <repository>/.git/config
• A minima, il faut configurer son nom d’utilisateur et son adresse email (informations qui
apparaîtront dans chaque commit) :
○ git config --global [Link] "John Doe"
○ git config --global [Link] johndoe@[Link]

30
Les commandes
git init

• La commande git init crée un dépôt Git.

• Elle permet de convertir un projet existant, sans version en un dépôt Git ou d'initialiser
un nouveau dépôt vide.
• La plupart des autres commandes Git ne sont pas disponibles hors d'un dépôt
initialisé.
• Il s'agit donc généralement de la première commande que vous exécuterez dans un
nouveau projet.

32
git init

Repository (dépôt)
• C’est l’endroit où Git va stocker tous ses objets : versions, branches, tags…
• Situé dans le sous-répertoire .git de l’emplacement ou on a initialisé le dépôt
• Organisé comme un filesystem versionné, contenant l’ intégralité des fichiers de
chaque version (ou commit)

33
git init --bare

• Le flag --bare crée un dépôt qui ne dispose pas de répertoire de travail, rendant
impossibles les éditions de fichiers et les commits de changements dans ce répertoire.
• Vous créeriez un dépôt brut depuis lequel exécuter les commandes git push et git
pull, mais dans lequel vous ne pourriez jamais faire de commit.

34
git config

• Le cas d'usage le plus élémentaire pour git config consiste à l'appeler avec un nom de
configuration, qui affichera la valeur définie pour ce nom.
• Les noms de configuration sont des chaînes délimitées par des points et composées
d'une « section » et d'une « clé » en fonction de leur hiérarchie.
• Par exemple : [Link]
• Dans cet exemple, « email » est une propriété enfant du bloc de configuration de
l'utilisateur.
• Cela renvoie l'adresse e-mail configurée, le cas échéant, que Git associera à des commits
créés en local.

35
 git config : Niveaux de configuration

• La commande git config peut accepter des arguments de manière à spécifier le niveau de
configuration sur lequel agir.
• Les niveaux de configuration suivants sont disponibles :
• --local
• --global
• --system

36
 Commit

• Fonctionnellement : Unité d’œuvre

• Doit compiler
• Doit fonctionner
• Doit signifier quelque chose (correction d'anomalie, développement d'une fonctionnalité /
fragment de fonctionnalité)

37
 Commit

• Techniquement : Pointeur vers un snapshot du filesystem dans son ensemble

• Connaît son ou ses parents
• Possède un identifiant unique (hash SHA1) basé sur le contenu et sur le ou les
parents

38
 Commit

• Le repository contient l’ensemble des commits organisés sous forme de graphe acyclique
direct :
• Depuis un commit, on peut accéder à tous ses ancêtres
• Un commit ne peut pas connaître ses descendants
• On peut accéder à un commit via son ID unique
• Des pointeurs vers les commits permettent d’y accéder facilement (branches, tags)

C2 branche1

C0 C1

C3 C4 branche2
39
 Staging area

• C’est la liste des modifications effectuées dans la working copy et qu’on veut inclure dans le
prochain commit.
• On construit cette liste explicitement.
• git status : affiche le statut de la working copy et de la staging area
• git add : ajoute un fichier à la staging area
• git rm --cached : unstage un nouveau fichier
• git checkout -- : retire un fichier de la staging area

40
Commit

• git commit -m “mon commentaire de commit”

→ génère un commit avec les modifications contenues dans la staging area
• git commit -a -m “mon commentaire de commit”
→ ajoute tous les fichiers modifiés (pas les ajouts / suppressions) à la staging area et
commite
• git commit --amend
→ corrige le commit précédent

41
 Gestion de sources avec Git : Workflow

• Le répertoire de travail (working directory) est le répertoire dans

lequel se fait les développements.
• Ce répertoire contient des fichiers suivis par Git ainsi que des
fichiers non-suivis.
• La zone d’index (staging area) contient les fichiers qui feront
partie du prochain commit.
• Le répertoire Git (repository) est l’endroit où Git stocke les
métadonnées et la base de données des objets du projet.
• Ce répertoire contient tous les fichiers suivi et tout l’historique du
projet.

42
 Gestion de sources avec Git : Workflow

• Modification des fichiers dans le répertoire de travail

(working directory).
• Indexation du contenu modifié (git add), en vue du
prochain instantané.
• Validation (commit) basculant les modifications dans le
répertoire Git (repository).

43
Gestion de sources avec Git : Workflow

44
 Historique des versions

• git log [-n][-p][--oneline]: historique

• affiche les ID des commits, les messages, les modifications
• -n : limite à n commits
• -p : affiche le diff avec le commit précédent
• --oneline : affiche uniquement le début de l’ID du commit et le commentaire sur une seule ligne
pour chaque commit
• git show [--stat]: branche, tag, commit-id …
• montre le contenu d’un objet
• git diff :
• git diff id_commit : diff entre working copy et commit
• git diff id_commit1 id_commit2 : diff entre deux commits

45
 Ancêtres et références

• id_commit^ : parent du commit

• id_commit^^ : grand-père du commit…
• id_commit~n : n-ième ancêtre du commit
• id_commit~2 : deuxième parent du commit
• id_commit1..id_commit2 : variations entre le commit 1 et le commit 2
• (ex. git log id_commit1..id_commit2 : tous les commits accessibles depuis commit2 sans
ceux accessibles depuis commit1)

46
 Git diff : utilisation

• git diff
• Différence entre l’index et les working files
• git diff --staged
• Différence entre l’index et le HEAD
• git diff HEAD
• Différence entre le HEAD et les working files
• git diff <commit1> <commit2>

47
Exercices
basic-commits
basic-staging

48
Travailler avec les
branches
Branches: Introduction

• Déviation par rapport à la route principale

• Permet le développement de différentes versions en parallèle
• Version en cours de développement
• Version en production (correction de bugs)
• Version en recette
• ...
• On parle de “merge” lorsque tout ou partie des modifications d'une branche sont rapatriées
dans une autre
• On parle de “feature branch” pour une branche dédiée au développement d'une
fonctionnalité (ex : gestion des contrats...)

50
Branches: Introduction

• branch : pointeur sur le dernier commit (sommet) de la branche

• les branches sont des références
• master : branche principale (trunk)
• HEAD : pointeur sur la position actuelle de la working copy

51
Branches: Création

• git branch <mabranche> (création)

• git checkout <mabranche> (se positionner dessus)

• Ou git checkout -b <mabranche> (création + se positionner dessus)

• git branch → liste des branches (locales)

52
 Branches: Suppression

• git branch –d mabranche (erreur si pas mergé)

• git branch –D mabranche (forcé)
• Supprime la référence, pas les commits (on peut toujours récupérer via reflog en cas
d'erreur)

53