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 la méthode la plus courante et qui se 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 la Figure 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 Tableau1 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 suivant http://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 :

Cd cgi-bin

/home

www cgi-bin admin

user (conf)

/home

www cgi-bin admin git

user (conf)

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