Git - Démarrage rapide sous Linux

Loïc Guibert

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.

Ce tutoriel est accompagné d'une Visual cheat-sheet Git.

Pour réagir à ce tutoriel, un espace de dialogue vous est proposé sur le forum : Commentez .

- Titre : Git - Démarrage rapide sous Linux

- Auteur : Loïc Guibert

- Parution : 17 décembre 2015

- Mise à jour : 1 mars 2016

- Public visé :

- Licence : Le contenu de cet article est rédigé par Loïc Guibert et est mis à disposition selon les termes de la Licence Creative Commons Attribution - Pas d'Utilisation Commerciale - Partage dans les Mêmes Conditions 3.0 non transposé. Les logos Developpez.com, en-tête, pied de page, css, et look & feel de l'article sont Copyright ® 2013 Developpez.com.

Sommaire

- I. Avant-propos

- II. Quelques notions

- III. Configuration du poste de développement

- III-A. Installation

- III-B. Configuration

- IV. Pour le développeur solitaire…

- V. Travail en équipe…

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

- V-B. Pour chaque développeur

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

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

- VI. J'ai commencé tout seul, mais maintenant, je veux partager mon travail…

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

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

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

- VII. Conclusion

- VIII. Remerciements

I - Avant-propos

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.

Nous n'aborderons pas ici :

- les problématiques hiérarchiques (gestion des différents rôles/droits des utilisateurs) ;

- les aspects sécurité (mise en place de clé publique/privée pour les accès SSH, gestion des utilisateurs sur le dépôt…) ;

- la mise en place de façades (Serveur HTTP/HTTPS pour l'accès au dépôt, Application web de navigation dans le dépôt…).

Je décris la procédure d'installation pour un système Linux Debian, mais elle peut facilement être adaptée à d'autres distributions.

Git est également disponible sous Windows et Mac : http://git-scm.com/downloads.

Ce tutoriel a été écrit pour la version 1.7 de Git, mais il reste valable pour la version 2.x.

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

- le site officiel : http://git-scm.com/ ;

- le livre ProGit 2de é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 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.

II - Quelques notions

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.

Je vous conseille de vous référer aux liens fournis dans l'introduction, notamment le livre ProGit (2de édition), afin de bien comprendre les notions que nous venons de voir.

III - Configuration du poste de développement

III-A - Installation

Nous allons commencer par installer Git ainsi que deux utilitaires graphiques assez pratiques (ils vont nous faciliter la vie par rapport au terminal pour certaines actions, comme la gestion de la staging area, la consultation de l'historique…) :

- gitk : pour visualiser les branches et les commits ;

- git-gui : pour gérer le dépôt.

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

III-B - Configuration

Nous allons configurer le nom d'utilisateur et le mail sous lesquels vont apparaître nos commits dans l'historique :

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

IV - Pour le développeur solitaire…

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 :

1. cd <workingDir>

2. echo "Répertoire contenant les sources du projet XXX" > README

3. git add README

4. 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.

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, notamment le livre ProGit (2de édition), et à la Visual cheat-sheet Git afin d'aborder le travail au quotidien avec Git (création de branches, fusion, retour en arrière…).

Exécuter la commande git gui depuis le répertoire de travail permet de lancer un utilitaire graphique qui va nous faciliter la vie pour les commits : ajout/retrait de fichiers dans la staging area, commit avec commentaire…

V - Travail en équipe…

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

Afin de mettre en place rapidement le dépôt de référence, nous allons utiliser Git avec le protocole SSH. C'est, en général, la solution la plus simple et rapide à mettre en œuvre. Nous supposons ici que le serveur SSH est installé et opérationnel sur la machine qui va héberger le dépôt.

Intallation de Git :

# Installation de git
sudo apt-get install git

Création d'un utilisateur système dédié à Git, que nous utiliserons pour nous connecter au dépôt via le serveur SSH. Créons, par exemple, l'utilisateur « git ». :

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

Création du répertoire de base des dépôts Git :

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

Suivant votre configuration du serveur SSH, faites le nécessaire afin qu'il soit possible de se connecter avec l'utilisateur « git » en SSH sur cette machine.

Création du dépôt sans working copy :

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

Test et Initialisation du dépôt :

# 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

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

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

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 :

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 » :

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 » :

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) :

git checkout local_wip
git rebase master

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

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 :

git push

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

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 Git, afin d'aborder le travail au quotidien avec Git (création de branches, fusion, retour en arrière…).

VI - J'ai commencé tout seul, mais maintenant, je veux partager mon travail…

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

Si vous n'avez pas encore créé de dépôt local, il faut le faire maintenant.

Si vous avez déjà créé le dépôt local et que vous avez fait tous les commits nécessaires pour qu'il soit à jour, vous pouvez passer directement à la section suivante.

Création du dépôt local :

cd <workingDir>
git init .

Commit initial :

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

Ajout des fichiers existants :

# 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

Pour créer le dépôt distant, nous allons faire un clone « bare » du dépôt local que nous enverrons directement sur le serveur :

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

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

Maintenant que le dépôt distant est publié, il faut le référencer dans le dépôt local afin de pouvoir le mettre à jour :

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

À partir de là, nous nous retrouvons dans la même configuration que dans la section « Travail en équipe… » après avoir fait un git clone

VII - Conclusion

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 !

VIII - Remerciements

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.