Le système de versioning git

Préface
Ce manuel constitue un simple guide pour débuter avec le système de gestion de version git. Ce
guide n’est pas une référence complète que vous utilisez en cas de besoin. Ce document vous
guidera dans votre apprentissage et vous donnera les premiers pas pour commencer avec les
systèmes de gestion de version.
La documentation complète du système git est disponible en anglais (http://git-scm.com/book/) et
en français (http://git-scm.com/book/fr). Vous pouvez aussi essayer git en ligne en suivant le lien
http://try.github.com/
-Nassim BAHRI-

Le système de versioning git
Introduction
Lorsque vous travailler sur un projet en équipe, le problème majeur rencontré consiste en la
modification d’un fichier par plusieurs utilisateurs ainsi que la gestion des conflits. Dans ce cas un
système de versioning sera un outil indispensable.
Le système de gestion de version est un logiciel qui enregistre l’évolution d’un ou plusieurs fichiers
au cours du temps, en gardant la trace de toutes les modifications effectuées, de manière à ce qu’on
puisse rappeler une version antérieure d’un fichier à tout moment.
Parmi les fonctionnalités basiques d’un tel système, nous pouvons citer :
 Conserver un historique de toutes les modifications,
 Possibilité de travailler à plusieurs (grâce aux fonctions de verrous et de gestion des conflits),
 Permettre la modification parallèle des fichiers (le système de branches).
Différents modèles
Brièvement, les systèmes de gestion de version proposent trois modèles de travail que vous pouvez
choisir l’un d’entre eux selon vos besoins.Nous commençons à détaillé ces différents modèles.
1. Le modèle local
C’et laméthode la plus courante et quise matérialise dans la copie des fichiers de travail dans un
autre répertoire sur le même ordinateur. Cette méthode est la plus simple et adapté lorsqu’un seul
utilisateur travaille sur le projet. Ce modèle peut être résumé par laFigure 1.
Figure 1 : Les systèmes de gestion de version locaux

2. Le modèle centralisé
Lorsque vous travailler en groupe, vous allez vous retrouver avec un problème courent; les
développeurs ont besoin de collaborer sur des stations différentes. Il est donc impossible d’utiliser le
modèle local. La solution sera donc de centraliser les fichiers sur un ordinateur qui sera accessible par
tous les membres de l’équipe. Et c’est ça le principe d’un tel modèle qui met en place un serveur
central contenant tous les fichiers sous gestion de version, et des clients qui peuvent extraire les
fichiers de ce dépôt. Ce modèle peut être résumé par la Figure 2.
Figure 2 : Les systèmes de gestion de version centralisés
Cependant, ce modèle présente un risque majeur que la panne du serveur centralisé présente. En
effet, si le serveur tombe en panne tous les collaborateurs seront bloqués et ne peuvent pas
enregistrer les modifications issues de leurs travails. Ils risquent aussi de tous perdre si le disque dur
du serveur se corrompt.
3. Le modèle distribué
Suite aux problèmes que présente le modèle centralisé, les systèmes de gestion de version distribués
entent en jeu. L’apport de ce nouveau modèle est que les clients n’extraient pas seulement la
dernière version du fichier mais ils dupliquent tous le dépôt, c'est-à-dire stocker toutes les versions
du fichier dans un dépôt local (présenté dans le paragraphe 1). Ainsi si le serveur tombe en panne, il
peut être restauré en se serviront du dépôt d’un des clients. La Figure 3 résume ce dernier modèle.
Choix du système de versioning
Sur le marché, plusieurs logiciels permettent la gestion de version. Nous présentons dans le Tableau
1 quelques logiciels libres.
Gestion locale GNU RCS (1982)
Gestion centralisée CVS (1990), CVSNT(1992), SVN(2000)

Gestion distribuée SVK(2003), Git(2005), Fossil(2007)
Tableau 1 : Exemples des logiciels de gestion de version
D’après la comparaison entre les différents modèles de gestion de version que nous avons faite dans
les paragraphes précédents, nous pouvons relever que les systèmes de gestion distribuée semblent
être les meilleurs. Parmi les logiciels de gestion distribués, « git » est le mieux adaptés vu les
caractéristiques qu’il présente :
 Vitesse,
 Conception simple,
 Support pour le développement non linéaire (possibilité de travailler à plusieurs),
 Complétement distribué,
 Disponible sur plusieurs plateformes (Windows, Linux, Mac os),
 Plusieurs clients existants (GitHub, Gitbox, sourceTree,...).
Figure 3 : Les systèmes de gestion de version distribués
Bien démarrer avec git : Installation
Avant de commencer à utiliser n’importe quel logiciel, il faut dans un premier temps l’installer. Nous
verrons dans cette section comment installer le système de gestion de version git sous Windows.
Pour les autres plateformes notamment Linux et Mac os vous pouvez suivre les instructions décrite
dans le lien suivanthttp://git-scm.com/book/fr/D%C3%A9marrage-rapide-Installation-de-Git.
Pour installer git, rien de complexe. Rendez-vous sur la page de téléchargement via ce lien http://git-
scm.com/downloads et télécharger la version adéquate avec votre système d’exploitation.

Figure 4 : Télécharger git
Une fois le téléchargement est terminé, lancez le fichier exécutable.
Figure 5 : Lancement de l'installation
Figure 6 : Licence GPL et conditions d’utilisation
Figure 7 : Chemin d'installation
Choisissez par la suite l’emplacement d’installation de git sur votre ordinateur.

Une fois vous avez mentionné l’emplacement de l’installation, il vous est
demandé de choisir les composants à installer avec git. Vous devez donc cocher
les deux cases Git Bach Here et Git GUI Here.
Figure 8 : Choisir les composants à installer
Choisissez le dossier où vous voulez créer les raccourcis et ajouter par la suite git
au PATH de votre ordinateur.
Figure 9 : dossier contenant les raccourcis
Figure 10 : Ajouter git au PATH

Figure 11 : Choisissez le mode de traitement
Figure 12 : git en cours d'installation
Figure 13 : Installation terminée
Passons maintenant aux choses sérieuses : la configuration et l’installation de git.
Par défaut git nous propose deux modes d’utilisation ;un mode graphique et un
mode en utilisant les lignes de commande. Nous intéresserons dans les sections
suivantes à l’utilisation de git avec les lignes de commande puisqu’il est plus
complexe que le mode graphique.
Il est à noter que nous pouvons utiliser plusieurs client git qui nous permet la
simplification de quelque tâches. Parmi les clients gratuits :
 GitHub (http://windows.github.com/) / (http://mac.github.com/)
 Git Extension (https://code.google.com/p/gitextensions/)
 SourceTree (http://www.sourcetreeapp.com/)
 GitEye (http://www.collab.net/giteyeapp)

Bien démarrer avec git : Configuration
Lors de la première utilisation du gestionnaire de version git vous devez configurer certains
paramètres notamment le nom de l’utilisateur et l’adresse email qui seront utiles pour identifier les
utilisateurs qui ont validés des modifications par la suite.
 Modifier le nom de l’utilisateur
Git config --global user.name ‘nom utilisateur’
 Modifier l’adresse email
Git config --global user.email ‘email@exemple.com’
 Afficher la liste des informations de configuration
Git config --list
 Obtenir l’aide
Git help [commande]
Bien démarrer avec git : Les bases de git
Dans cette section nous illustrons les différents fonctionnalités de git avec un exemple réel.
 Créer un projet git
Dans un premier lieu, vous commencer à créer votre projet. Lancer ‘Git bash’ que vous avez installé
avec git et positionner vous dans le répertoire de votre projet.
Cd /c/wamp/www/monProjet
Supposons que nous sommes en train de développer une application web, donc notre projet sera
sous le répertoire www de notre serveur.
Dans une seconde étape il faut initialiser git
Git init
Cette commande crée les fichiers contenant les informations nécessaires pour le contrôle du projet.
 Vérifier l’état des fichiers
On suppose que nous ayons créé le fichier index.php qui affiche le fameux message ‘Hello World’ et
nous voulons vérifier l’état des fichiers de notre projet, il suffit de taper la commande
Git status
Il faut savoir que le cycle de vie des états d’un fichier est le suivant :

 Untracked : le fichier n’est pas sous le contrôle du gestionnaire de version,
 Unmodified : le fichier n’est pas modifié,
 Modified : le fichier a été modifié,
 Staged : mis en scène, en attente de validation (commit).
Le résultat de notre commande
Figure 14 : Résultat de la commande git init
Nous pouvons constater que le fichier index.php est dans un état untracked. Pour ajouter ce fichier
sous le contrôle de git, nous devons tapez la commande
Git add index.php
Git status
Figure 15 : Résultat de la commande git status
Nous pouvons constater que notre fichier a passé vers un état staged.

 Valider les modifications
A ce stade nous pouvons valider nos modifications
Git commit –m ‘un message’
Nous pouvons aussi consulter la liste de nos commit en tapant la commande
Git log [-p] [-2]
-p : permet d’afficher la différence entre chaque validation
-2 : le nombre maximal à afficher
 Différence entre les fichiers
Des fois, nous avons besoins de voir la différence entre les fichiers avant de valider les modifications.
La commande qui nous servi pour cette opération est :
Git diff
Nous pouvons aussi voir la différence du dernier commit
Git diff HEAD
Ou bien voir les modifications mises en scène (en attende d’un commit)
Git diff --staged
 Eliminer la phase d’indexation avant le commit
Avant de valider les modifications, il faut ajouter les fichiers modifiés dans la zone d’index en utilisant
la commande
Git add nom_fichier
Nous pouvons donc éliminer cette étape en passant directement par la commande suivante
Git commit –a –m ‘mon message’
En effet, si nous avons des nouveaux fichiers il faut impérativement passer par la commande
Git add nom_fichier
 Suppression /déplacement d’un fichier
Parfois nous avons besoin de supprimer ou de déplacer un fichier vers un autre répertoire. Dans ce
cas il faut indiquer à git que vous avez fait une modification dans la structure de votre projet. Les
commande qui nous servi dans ce cas sont :
Git rm nom_fichier (pour la suppression d’un fichier)

Git mv fichier_origine cible (pour le déplacement d’un fichier)
 Modifier le dernier commit
Supposons que lors de notre dernière validation nous avons oublié de mettre un fichier sous contrôle
de version, donc il ne sera pas pris en compte lors de ce commit. Au lieu de créer un autre commit,
nous pouvons modifier le dernier commit en ajoutant ce fichier. La commande qui permet de
modifier une commit est la suivante :
Git commit –amend
Exemple :
Touch liste.php
Git commit –m ‘mon dernier commit’ # Dans ce cas le fichier
liste.php n’est pas pris en compte
Git add liste.php
Git commit --amend
La dernière ligne permet de modifier le commit en ajoutant le fichier liste.php
 Désindexer un fichier
Parfois nous avons besoin de garder un ou plusieurs fichiers en privé
Figure 16 : Arborescente du projet
Nous avons créé les deux répertoires css et images ainsi que les fichiers script.js et private.txt. Nous
voulons mettre tous les fichiers de ce projet sous contrôle de version sauf le fichier private.php. Nous
pouvons donc faire :
Git add *
Git reset HEAD private.php
 Réinitialiser un fichier
Le but de l’utilisation d’un gestionnaire de version est de récupérer une version antérieure d’un
fichier modifié. La commande qui nous permet d’effectuer cette opération est :
Git checkout --nom_fichier

 Afficher les étiquettes (tags)
L’étiquetage est une technique utilisé pour marquer un état de publication. Par exemple marquer le
dernier commit comme étant la version 1.0 de ce projet. Nous pouvons afficher la liste des tags en se
serviront de la commande :
Git tag
 Créer une étiquette
Pour la création d’une étiquette rien de complexe :
Git tag –a 1.0 –m ‘un message’
1.0 : c’est le nom de l’étiquette
Figure 17 : Créer une étiquette
 Afficher les informations d’une étiquette
Pour afficher les informations d’une étiquette, la commande est :
Git show nom_etiquette
Figure 18 : Afficher les étiquettes

 Créer une branche
Les branches est l’un des éléments les plus importants lors de l’utilisation d’un gestionnaire de
version. Pour être simple, nous pouvons définir une branche comme un espace de travail séparé et
indépendant. Donc nous pouvons créer des branches pour chaque membre de l’équipe si on travaille
en groupe ou bien une branche pour le développement et une autre pour la production…
La commande qui permet la création d’une branche est :
Git branch nom_branche
 Basculer vers une autre branche
Pour passer d’une branche à une autre nous pouvons utiliser la commande
Git checkout nom_branche
Our bien la commande
Git checkout –b nom_branche
Cette commande permet de créer une branche et basculer automatiquement vers cette dernière.
 Fusionner deux branches
Une fois nous avons terminé notre travail et nous voulons fusionner nos deux branches, nous
utilisons la commande :
Git merge nom_branche
Dans ce cas le contenu de la branche nom_branche sera fusionné avec le contenu de la branche
actuelle (dans ce cas master).
Exemple d’utilisation :
Nous allons créer dans un premier lieu la branche « dev » qui sera consacré pour notre travail de
développement
Git branch dev
Par la suite nous basculons vers cette branche
Git checkout dev
Figure 19 : Basculer vers la branche dev

Créons maintenant le fichier produit.php
Touch produit.php
Git add produit.php
Figure 20 : Créer le fichier produit.php
Maintenant, il nous reste qu’à valider les modifications
Git commit –m ‘commit avec le fichier produit.php’
Figure 21 : Valider les modifications
Pour afficher les différentes branches, on utilise la commande
Git branch
Figure 22 : Lister les branches
La branche avec un Astérix est celle en cours. Nous revenons maintenant vers la branche master
Git checkout master

Figure 23 : Retour vers la branche master
Affichons le journal de modification
Git log
Figure 24 : Afficher le journal de modification
Nous pouvons constater que le dernier commit de la branche « dev » n’est pas pris en compte dans
cette branche et si on affiche la liste des fichiers de ce projet avec la commande « ls » nous pouvons
voir que le fichier produit.php n’a pas été ajouter.
Ls
Figure 25 : Lister le contenu du répertoire de travail
Maintenant nous pouvons fusionner le contenu des deux branches « dev » et « master » dans
« master »
Git merge dev

Figure 26 : Fusion des branches
Faisons un
Git log
Figure 27 : Afficher l'historique des modifications
 Supprimer une branche
Pour la suppression d’une branche, la commande est :
Git branche –d nom_branche
Il est à noter que si une branche contient des modifications validées et qui n’ont pas été fusionné
avec d’autres branches, il est impossible de supprimer cette dernière. Nous aurons le message :
Figure 28 : Supprimer une branche

 Afficher les dernières validations de chaque branche
Pour afficher le dernier commit de chaque branche, nous utilisons la commande
Git branch –v
 Les branches fusionnées
Pour afficher les branches fusionnées avec celle en cours, nous utilisons
Git branche --merge
Dans le cas contraire, nous utilisons
Git branch --no-merge
Notions avancées : travailler sur un dépôt distant
Dans la première partie de ce document, nous avons invoqué le besoin des développeurs à
collaborer sur des stations différentes. Et nous avons présenté le modèle répondant à ce type de
problème. Tout au long de cette partie nous supposons que notre serveur est configuré pour la prise
en compte du système git. Nous verrons dans la prochaine partie l’installation et la configuration de
git sur un serveur.
 Afficher les serveurs distants
Lorsque nous travaillons avec des dépôts distants, nous avons toujours un ensemble de serveur (url
des serveurs) enregistrés pour notre répertoire de travail. La commande qui nous permet d’afficher
la liste des serveurs enregistrés est :
Git remote
Cette commande permet d’afficher le nom court su serveur (en d’autre terme un alias du serveur)
Pour afficher les informations complètes sur le serveur notamment son nom et son url nous utilisons
Git remote –v
 Cloner un dépôt distant
La commande qui nous permet de cloner un dépôt distant sur notre machine est la suivante
Git clone url_serveur/nom_repertoire.git
Cette commande permet d’ajouter un nouveau serveur à notre projet avec l’adresse url_serveur et
l’alias origin.

 Ajouter un nouveau dépôt distant
La première étape à faire lorsque nous souhaitons travailler avec un dépôt distant consiste à ajouter
l’adresse de ce dernier à notre projet. Bien sûr cette étape est négligée si nous avons fait un clone.
Git remote add alias URL
Exemple:
Git add origin https://github.com/NassimBahri/Filgrane.git
 Récupérer depuis des dépôts distants
Pour obtenir les données des dépôts distants, il suffit de lancer la commande
Git fetch alias
Exemple :
Git fetch origin
Cette commande s'adresse au dépôt distant et récupère toutes les données de ce projet que vous ne
possédez pas déjà.
 Pousser le travail vers un dépôt distant
Une fois vous êtes satisfait avec votre copie locale, il est temps de la pousser vers le dépôt distant
afin de la partager avec les autres membres de l’équipe. La commande qui nous permet de pousser
notre travail est la suivante :
Git push alias branche
Nous pouvons aussi lancer cette commande en ajoutant un autre paramètre
Git push –u alias branche
-u permet de se souvenir de l’alias du serveur ainsi que la branche. La prochaine fois que nous
voulons pousser notre travail, il suffit de taper
Git push
 Inspecter un dépôt distant
La commande permettant d’afficher les informations sur un dépôt distant est
Git remote show alias
 Renommer / supprimer un dépôt distant
Pour changer l’alias d’un dépôt distant rien de complexe, il suffit de lancer la commande
Git remote rename old_alias new_alias

De même pour la suppression d’un dépôt distant
Git remote rm alias
 Fusionner le travail
Pour fusionner le contenu de la branche distante avec la mienne, nous lançons la commande
Git pull alias branche_distante
Exemple
Git pull origin master
Cette commande permet de fusionner le contenu de la branche distante master avec le contenu de
la branche actuelle du dépôt local.
Notions avancés : Installation de git sur un serveur
L’installation de git sur un serveur se diffère d’un hébergeur à un autre. Nous verrons dans cette
partie comment installer git sur les serveurs d’un hébergeur Français ; alwaysdata
(https://www.alwaysdata.com/).
1. Créer un compte et activer le ssh
Accédons à la page d’inscription et créons notre compte d’hébergement. Une fois notre compte a
bien été créé, nous accédons à notre espace d’administration via cette
url :https://admin.alwaysdata.com/.
Figure 29 : Formulaire de connexion
Introduisons notre adresse email et notre mot de passe pour accéder à notre panel d’administration.
Par la suite, nous devons activer notre compte ssh.

Figure 30 : Menu d'administration
Figure 31 : Liste des comptes ssh
Figure 32 : Activer le compte ssh
Maintenant il est temps de configurer notre serveur pour la prise en compte du système de
versioning git.
2. Se connecter à notre compte
Dans un premier lieu connectons-nous à notre serveur en mode ssh. Ouvrons alors ‘git bash’ et
tapons la commande suivante
Ssh conf@ssh.alwaysdata.com
Expliquons cette commande :
ssh : indique le mode de connexion

Conf : le login de notre compte d’hébergement
ssh.alwaysdata.com : l’adresse de notre serveur
Figure 33 : Connexion en mode ssh
L’arborescence de notre répertoire est la suivante :
3. Configuration de gitweb
La seconde étape de notre processus consiste à configurer gitweb. Tout au long de notre travail nous
considérons que nos dépôts git serons stockés dans le répertoire /home/conf/git
Dans le dossier /home/conf/cgi-bin créons un lien sur le CGI de gitweb à l’aide de la commande :
/home
www cgi-bin admin
user (conf)
/home
www cgi-bin admin git
user (conf)

Cd cgi-bin
ln -s /usr/lib/cgi-bin/gitweb.cgi
Créons ensuite le dossier contenant les fichiers nécessaire pout gitweb
cd ../www
mkdir gitweb
mkdir ../git
cd gitweb
cp /usr/share/gitweb/*.
Créons par la suite le fichier ‘.htaccess’ dans le dossier /home/conf/www, contenant ceci
DirectoryIndex /cgi-bin/gitweb.cgi
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME}!-d
RewriteRule ^.* /cgi-bin/gitweb.cgi/$0 [L,PT]
Passons maintenant à la dernière étape, la configuration de gitweb. Dans le dossier /home/conf/cgi-
bin, créons un fichier ‘gitweb_config.perl’ contenant le code suivant :
# Path to git projects (<project>.git)
#le chemin que nous avons choisi pour nos dépôts git
$projectroot = "/home/conf/git";
# Directory to use for temp files
$git_temp = "/tmp";
# Target of the home link on top of all pages
#$home_link = $my_uri || "/";
# Html text to include at home page
$home_text = "indextext.html";
# file with project list; by default, simply scan the projectroot
dir.
$projects_list = $projectroot;

# Stylesheet to use
$stylesheet = "/gitweb/gitweb.css";
# Logo to use
$logo = "/gitweb/git-logo.png";
# The 'favicon'
$favicon = "/gitweb/git-favicon.png";
A ce stade la configuration de notre serveur est terminée. Accédons à gitweb en ligne en tapant
http://conf.alwaysdata.net/gitweb/
Figure 34 : Gitweb
4. Créer un dépôt nu
Cette étape consiste à exporter un dépôt existant dans un nouveau dépôt nu c’est-à-dire un dépôt
qui ne contient pas de copie de répertoire de travail. Essayons avec un petit exemple :
 Créons un dossier test en local
Figure 35 : Dossier test en local
 Accédons à ce dossier et lançons la commande git init

Figure 36 : Initialisation de git
 Créons une copie vide du dossier test
Cd ..
Pour revenir vers le dossier parent
Git clone --bare test test.git
Ou bien
Cp –Rf test/.git test.git
Figure 37 : Création du dépôt nu
5. Copier le dépôt nu sur le serveur
Avant de continuer, il faut rappeler que nos dépôts distant seront stockés dans le répertoire
/home/conf/git.
La copie du dossier nu sur le serveur est très simple, il suffit de lancer la commande
Scp –r repertoire.git user@serveur:chemin

Continuos avec notre exemple et tapons la commande
Scp –r test.git conf@ssh.alwaysdata.com:/home/conf/git
Figure 38 : Copie du dépôt nu sur le serveur
Nous pouvons maintenant accéder à gitweb pour voir la liste de nos dépôts.
Figure 39 : Liste des dépôts
À partir de maintenant, tous les autres utilisateurs disposant d'un accès SSH au serveur git peuvent
cloner votre dépôt en lançant la commande :
Git clone user@serveur:/chemin/repertoire.git
Utilisation de GUI
Finalement, nous devons rappeler que nous pouvons utiliser l’assistant graphique (GUI – Git User
Interface) pour la gestion de nos dépôts git.

Il suffit de vous déplacer dans le répertoire de votre projet git et de faire un clic droit et choisir par la
suite Git GUI Here
Figure 40 : Accéder à Git GUI
Vous tombez sur cette interface
Figure 41 : Git GUI
Conclusion
Tout au long de ce guide nous avons présenté les différents modèles de travail proposés par les
systèmes de gestion de version. Nous avons travaillé avec les lignes de commande git pour gérer nos
dépôts locales et distants. Par la suite nous avons expérimenté l’installation de git sur un serveur en
prenant comme exemple l’hébergeur alwaysdata.
A la fin de ce guide nous devons rappeler que ce document constitue un résumé des fonctionnalités
présenté sur la documentation de git.

Néographies
http://wiki.alwaysdata.com/wiki/Se_connecter_en_SSH
http://wiki.alwaysdata.com/wiki/Configurer_Gitweb
http://git-scm.com/book/fr

Le système de versioning git

Contenu connexe

Tendances

En vedette

Similaire à Le système de versioning git

Le système de versioning git