Git - Démarrage rapide sous Linux

est un outil de gestion de versions décentralisé.

Je vous propose ici un petit tutoriel de mise en œuvre rapide de Git sous Linux.
Ce tutoriel est destiné aussi bien au développeur solitaire qui désire bénéficier rapidement d'un système de gestion de versions simple et efficace, qu'à une équipe voulant mettre en place rapidement un système de gestion de versions collaboratif.

Si vous voulez en savoir un peu plus sur Git avant de commencer :

• le site officiel : http://git-scm.com/ ;
• le livre ProGit 2^de édition : http://git-scm.com/book/fr/v2 ;
• une traduction en français du Git Community Book : http://www.alexgirard.com/git-book/.

Vous pouvez également télécharger ma Visual cheat-sheet GitVisual cheat-sheet Git.

Le logo de Git présenté ici est celui disponible sur le site officiel de Git et a été réalisé par Jason Long sous licence Creative Commons Attribution 3.0.

Avant de commencer, il est nécessaire d'aborder quelques notions importantes dans Git. Voici l'organisation de base d'un dépôt Git local :

• Le Git repository est le dépôt à proprement parler. Il contient tous les commits, les branches, les tags…

  • Un commit est une sorte de « photo » du répertoire de travail. Il enregistre les fichiers modifiés depuis le commit précédent.
  • Une branche est un pointeur sur un commit.
  • Un tag est une étiquette associée à un commit. Elle peut être annotée par son créateur.
• La Staging area (ou Index) sert d'aide à la création d'un commit. C'est une zone particulière, gérée par Git, dans laquelle nous ajoutons des « photos » de fichiers. Lorsque cette zone est cohérente, en d'autres termes, quand elle contient les photos de tous les fichiers dont nous voulons enregistrer la version, alors il suffit de faire un commit de la staging area.
• La Working copy (ou Copie de travail) est le répertoire de travail contenant les fichiers du projet. Git enregistre sur quelle branche elle pointe (la référence HEAD) afin de placer correctement le prochain commit.

III-A. Installation▲

sudo apt-get install git git-man gitk git-gui

III-B. Configuration▲

git config --global user.name "<user>"
git config --global user.email "<email>"

Nous allons ici créer simplement un dépôt directement dans le répertoire de travail du projet, afin de permettre à Git de gérer les versions des fichiers. Nous aurons donc une arborescence comme ceci :

Pour ce faire, nous initialisons un nouveau dépôt :

git init <workingDir>

Nous allons créer notre commit initial :

cd <workingDir>
echo "Répertoire contenant les sources du projet XXX" > README
git add README
git commit -m "commit initial"

Revenons, plus en détail sur les quatre commandes précédentes :

1. Entrée dans le dossier de la working copy.
2. Création d'un fichier README.
3. Ajout du fichier README à la staging area.
4. Commit de la staging area avec le commentaire « commit initial ». Comme il s'agit du premier commit, ceci a pour effet de créer la branche « master » et d'y ajouter le commit.

Afin de pouvoir commencer rapidement à travailler, je vous propose ici une organisation très simple avec une mise en place rapide. Nous mettons tout le monde au même niveau, pas de gestion de rôles ni de droits sur les dépôts.

Voici, l'organisation proposée :

Nous mettons en place un dépôt « central » de référence. C'est le dépôt « officiel » ou « public » du projet. C'est lui qui va contenir tout le travail d'équipe.

Chaque développeur possède en local une copie liée au dépôt de référence (voir man git remote, livre ProGit). Ces dépôts contiennent (au moins) une branche locale de travail (« local_wip » dans le schéma suivant). Ainsi, chaque développeur travaille sur sa branche locale et rapatrie régulièrement les modifications du dépôt de référence afin de maintenir sa copie à jour.

Il fait l'intégration de son travail (avec des rebase/merge…) sur la branche « publique » concernée (« master » dans le schéma suivant) et pousse les modifications de la branche « publique » sur le dépôt de référence (« origin/master » dans le schéma suivant).

Voici un schéma plus détaillé de l'organisation et du contenu des dépôts :

V-A. Mise en place du dépôt de référence▲

# Installation de git
sudo apt-get install git

sudo adduser --no-create-home --home /var/git --shell /bin/bash git
sudo passwd git

sudo mkdir /var/git
sudo chown git:git /var/git
sudo chmod 2775 /var/git

git init --bare /var/git/<monDepot>.git
# l'option --bare pour ne pas avoir de working copy

# Récupération du dépôt
cd /tmp
git clone ssh://git@127.0.0.1[:portSSH]/~/<monDepot>.git monDepot

# Commit initial
cd /tmp/monDepot
echo "Répertoire contenant le sources du projet XXX" > README
git add README
git commit -m "commit initial"
git push origin master:master

# Nettoyage
cd ..
rm -rf monDepot

V-B. Pour chaque développeur▲

V-B-1. Récupération du dépôt de référence▲

 

Sélectionnez

git clone ssh://git@<IP_Machine_Ref>[:portSSH]/~/<monDepot>.git <cheminRepTravail>
cd <cheminRepTravail>

Création d'une branche locale de travail « local_wip » :

 

Sélectionnez

git checkout -b local_wip

Vous êtes prêt à commencer les développements !

V-B-2. J'ai bien bossé, je veux diffuser mon travail au reste de l'équipe▲

Comme vous pouvez le constater sur le schéma de présentation, chaque développeur possède un dépôt local lié au dépôt de référence. Or la « synchronisation » n'est pas automatique. C'est à chaque développeur de la réaliser manuellement (mais ceci est outillé bien sûr !).

Ainsi, il ne faut pas oublier que chaque commit fait par un développeur n'est pas envoyé automatiquement au dépôt de référence. Il faut garder à l'esprit que c'est le développeur qui envoie, quand il le souhaite, ses modifications après avoir fait l'intégration en local de son travail.

Voici une manière de procéder :

• j'ai réalisé plusieurs commits sur ma branche locale de travail (« local_wip ») ;
• entre-temps, un coéquipier a poussé quelques commits sur la branche « master » du dépôt de référence.

Je rapatrie les modifications depuis le dépôt de référence :

 

Sélectionnez

git fetch

Si vous êtes un peu perdu, lancez gitk depuis le répertoire de travail.

Afin de voir toutes les branches : dans le menu Vue > Nouvelle vue, cochez « Se souvenir de cette vue », les quatre options dans « Références » et « Trier par date » dans « Options diverses ».

Je bascule sur la branche « master » :

 

Sélectionnez

git checkout master

Comme je n'ai rien fait sur « master » depuis le dernier fetch, Git m'indique que je peux faire un fast-forward. En clair, pour que ma branche soit à jour, il n'y a qu'à la faire pointer sur le dernier commit de la branche « origin/master » :

 

Sélectionnez

git merge origin/master

Ensuite, deux solutions :

• soit je fusionne (merge) ma branche « local_wip » dans la branche « master » ;
• soit je la rebase sur « master ».

Je vais faire un rebase afin de garder un historique linéaire sur la branche « master » (on n'aura pas de commit de merge) :

 

Sélectionnez

git checkout local_wip
git rebase master

Ensuite, je vais appliquer tous les commits de ma branche sur la branche « master » :

 

Sélectionnez

git checkout master
git merge local_wip

Comme nous venons de faire un rebase, on a changé l'origine de la branche « local_wip » pour la faire pointer sur le dernier commit de la branche « master ». Ainsi, le merge de « local_wip » dans « master » est un fast-forward et on a donc bien un historique linéaire !

Je n'ai plus qu'à envoyer mes modifications au dépôt de référence :

 

Sélectionnez

git push

Je n'oublie pas de repasser sur « local_wip » pour reprendre le développement :

 

Sélectionnez

git checkout local_wip

Ensuite, au cours du développement, il suffit d'appliquer le même principe afin de faire évoluer le dépôt local. Je vous conseille de vous référer aux liens fournis dans l'introduction et à la Visual cheat-sheet GitVisual cheat-sheet Git, afin d'aborder le travail au quotidien avec Git (création de branches, fusion, retour en arrière…).

Nous allons voir ici qu'il est possible, à tout moment, de créer un dépôt local et de le partager. Ceci se fait en trois étapes :

1. Création du dépôt local.
2. Création d'une copie bare du dépôt local et envoi sur un « serveur ».
3. Référencement du dépôt distant en tant que remote dans le dépôt local.

VI-A. Création du dépôt local▲

cd <workingDir>
git init .

echo "Dépôt du projet XXX" > README
git add README
git commit -m "Initialisation du dépôt"

# Soit via git gui :
git gui
# Soit à la main :
git add <lesFichiersDuProjet>
git commit -m "Initialisation du projet"

VI-B. Création du dépôt distant▲

cd ..
git clone --bare -l <workingDir> <nomDepotDistant>.git
scp -r <nomDepotDistant>.git git@<server>:~/

VI-C. Référencement du dépôt distant▲

cd <workingDir>
git remote add origin <urlDepotDistant>

# On spécifie que la branche master locale suit la branche origin/master
echo "" >> .git/config
echo "[branch \"master\"]" >> .git/config
echo "  remote = origin" >> .git/config
echo "  merge = refs/heads/master" >> .git/config

Ce tutoriel n'est qu'un guide de démarrage rapide. Git est un outil puissant, fiable et efficace. Prenez le temps de l'essayer grandeur nature. N'hésitez pas à approfondir le sujet avec le livre ProGit (2de édition) dont je parlais dans l'avant-propos, il est assez facile d'accès.

Une fois familiarisé avec Git, vous aurez du mal à vous en passer !

Je remercie Vincent Viale, Marc Autran et Alexandre Laurent pour leur relecture technique et leurs conseils sur la rédaction ainsi que Claude Leloup , Jacques Thery et f-leb pour leur relecture orthographique.