Outils pour utilisateurs

Outils du site


serveurs:git

Git

Git est un système de gestion de versions distribué conçu pour être rapide, efficace et utilisable pour de grands projets tels que le noyau Linux.

Usage

L'utilisation traditionnelle de Git pour un projet collaboratif tire parti de ses fonctionnalités de gestion distribuée :

  • chaque collaborateur maintient son propre dépôt Git ;
  • le responsable principal du projet récupère — « tire », en langage Git — les modifications des dépôts des autres collaborateurs pour les intégrer dans le dépôt principal.

Avec une telle méthode de travail, il n'est pas nécessaire de donner aux collaborateurs des droits d'envoyer leurs modifications dans le dépôt principal puisque celles-ci sont récupérées par le responsable, tirées plutôt que poussées.

Protocoles

Git est utilisable selon deux modes principaux :

  • pour pousser des modifications, donc en lecture–écriture : en local ou par SSH ;
  • pour tirer des modifications, donc en lecture seule : par le protocole Git natif, ou par HTTP — il est bien sûr possible de tirer ces modifications en local ou par SSH.

Dans l'utilisation traditionnelle distribuée de Git, le mode en lecture–écriture est principalement utilisé par chaque collaborateur pour pousser ses modifications sur le serveur qui héberge son dépôt personnel s'il travaille sur une machine différente.

Installation et paramétrage

Sous Debian, il suffit d'installer le paquet git-core.

# aptitude install git-core

Création d'un projet

Pour créer un projet avec Git, il suffit de se servir de la commande git-init. Cela peut être utilisé de la façon suivante :

$ cd mon_projet/
$ git init

Après la création d'un nouveau dépôt, la première chose à faire est de renseigner sa description dans le fichier adéquat.

$ echo "Description du projet." > .git/description

Création d'un projet depuis un dépôt SVN

Pour mémoire, voici comment il est possible de passer de SVN à Git via le programme git-svn.

# aptitude install git-svn
$ git svn clone http://example.org/svn/projet -s --authors-file=~/fichier_auteurs

Nota Bene :

  • l'option -s permet de récupérer branches et tags depuis les noms conventionnels (trunk, branches et tags).
  • l'option –authors-file permet de faire référence à un fichier qui fait le lien entre un nom de contributeur au format SVN et un autre au format Git.
~/fichier_auteurs
user = user <username@example.org>

Cette commande a donc pour objectif de passer en revue chaque commit sur SVN pour le reporter sur un nouveau projet Git. Créer un projet de cette façon aura la fâcheuse tendance de ne pas le construire de la même manière que s'il avait été initié sous Git. J'entends par là que les branches SVN existantes au moment de la migration seront reprises en tant que branches distantes et qu'il est difficile de savoir vers quoi elle sont reliées. D'autre part, le fichier .git/config comporte des sections obscures, etc. J'ai pris le pli de retirer ces sections et de créer des branches locales depuis les branches distantes avant de supprimer ces dernières.

Service en lecture seule

Le démon Git permet de fournir un accès en lecture seule à des dépôts par le protocole natif Git. Cela permet à des contributeurs de récupérer une copie de ce dépôt — de « tirer », en langage Git. Puisqu'il fournit un service en lecture seule, ce démon a uniquement besoin de pouvoir lire les fichiers des dépôts.

Les dépôts Git peuvent être stockés dans un répertoire /srv/git appartenant à root. Contrairement aux dépôts locaux, on crée ici un dépôt nu (bare), qui n'a pas de répertoire de travail :

# mkdir /srv/git
# git init --bare /srv/git/projet.git
# echo "Description du projet." > /srv/git/projet.git/description

Le démon Git peut être lancé à la demande par le super-serveur inetd, qui prendra à sa charge l'écoute sur le port Git (9418) : cela évite de laisser tourner un démon Git qui ne sera utilisé que momentanément. Il faut donc créer une règle inetd particulière dans le fichier de configuration /etc/inetd.conf après avoir installé le paquet openbsd-inetd si ce n'est pas déjà fait :

/etc/inetd.conf
git stream  tcp4    nowait  nobody /usr/bin/git git daemon --inetd --base-path=/srv/git /srv/git
git stream  tcp6    nowait  nobody /usr/bin/git git daemon --inetd --base-path=/srv/git /srv/git

Si aucun service inetd n'était défini, le serveur inetd était probablement à l'arrêt et il faut alors le lancer :

# service openbsd-inetd start

À ce stade, le daemon tourne est délivre son service. Il est donc possible d'accéder en lecture aux dépôts du répertoire /srv/git à condition que ces derniers soient marqués comme exportables, c'est-à-dire qu'ils comportent un fichier git-daemon-export-ok (ce qui ne devra pas être le cas pour les projets personnels).

# touch /srv/git/projet.git/git-daemon-export-ok

L'accès se fera de cette façon (ici, dans le cas d'une demande de clone) :

$ git clone git://git.example.org/projet.git

Service en lecture–écriture

Git permet nativement de pousser des modifications par SSH : l'accès aux projets est alors régi par les droits d'accès Unix usuels sur les fichiers des dépôts :

  • pour un service personnel, il suffit de donner les dépôts Git à votre utilisateur ;
  • pour un service de groupe, il faut créer un groupe par projet, y mettre les utilisateurs correspondant aux collaborateurs et donner le dépôt du projet à ce groupe, autoriser l'écriture par le groupe — il faut également configurer le dépôt pour indiquer à Git que les nouveaux fichiers créés doivent également être inscriptibles par le groupe : git config core.sharedRepository true.
# chown -R tintin:tintin /srv/git/projet.git

Il est dès lors possible de pousser des modifications de cette façon :

$ git clone ssh://tintin@git.example.org/srv/git/projet.git
$ [modifications et commits]
$ git push

Visualisation des projets Git via Gitweb

Gitweb

Gitweb est un projet permettant de donner un accès en visualisation aux dépôts Git du serveur. Il est disponible dans les paquets de Debian :

# aptitude install gitweb

Il faut ensuite configurer Gitweb (pour lui enseigner que les dépôts sont dans /srv/git) :

# cp /etc/gitweb.conf /etc/gitweb.conf.dist
# vi /etc/gitweb.conf
/etc/gitweb.conf
# path to git projects (<project>.git)
$projectroot = "/srv/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.css";

# javascript code for gitweb
$javascript = "gitweb.js";

# logo to use
$logo = "git-logo.png";

# the 'favicon'
$favicon = "git-favicon.png";

hooks

Il est aussi nécessaire d'accrocher une exécution de “post-update” afin de mettre à jour les informations du dépôt (chose faîte à la volée pour les accès via protocole git mais pas pour http).

La commande à exécuter est simplement un “git update-server-info”, cela se configure dans le fichier “projet.git/hooks/post-update”.

projet.git/hooks/post-update
#!/bin/sh
exec git update-server-info

Apache

Si vos projets ne sont pas à rendre publics, il faudra restreindre l'accès à Gitweb, il faut donc gérer un mécanisme d'authentification. Ce service est rendu par la configuration Apache ci-après. Si cela vous est inutile, vous pouvez retirer ce qui a un lien avec l'identification (« Auth* » et « Require valid-user ») et ne pas créer le fichier git.passwd.

Il faut donc créer une configuration Apache, l'activer et recharger Apache :

# vim /etc/apache2/sites-available/git
/etc/apache2/sites-available/git
<VirtualHost *:80>
    ServerAdmin username@example.org
    ServerName git.example.org
    DocumentRoot /srv/git

    Alias /gitweb.css /usr/share/gitweb/gitweb.css
    Alias /git-favicon.png /usr/share/gitweb/git-favicon.png
    Alias /git-logo.png /usr/share/gitweb/git-logo.png
    Alias /git /srv/git

    ScriptAlias /gitweb.cgi /usr/lib/cgi-bin/gitweb.cgi
    DirectoryIndex gitweb.cgi
    <Directory "/srv/git/">
        Order allow,deny
        Allow from all
        AuthType Basic
        AuthName "Gitweb"
        AuthUserFile /srv/git/git.passwd
        Require valid-user
    </Directory>

    ErrorLog /var/log/apache2/git-error.log
    LogLevel warn
    CustomLog /var/log/apache2/git-access.log combined
</VirtualHost>
# a2ensite git
# /etc/init.d/apache2 reload

Il ne reste ensuite qu'à alimenter un fichier contenant les autorisations :

# htpasswd -cm /srv/git/git.passwd user

Pour simplement ajouter un utilisateur, on retire l'option -c qui servait à créer le fichier la première fois.

Divers

Sauvegarde des dépôts Git

Il existe plusieurs solutions pour sauvegarder ses dépôts Git. Chaque clone d'un dépôt constitue une sauvegarde basique.

rsync

Une simple sauvegarde des fichiers du dépôt permet de le conserver et de le restaurer à l'identique au besoin, l'utilisation de rsync est idéale dans ce cas :

# crontab -e
crontab
50 5 * * * rsync -a --delete /srv/git /srv/sauvegardes/

git

git permet aussi de gérer la copie de sauvegarde d'un dépôt.

Dans un premier temps il faut créer un clone du dépôt à sauvegarder, l'option –mirror permet de sauvegarder plus d'informations (cf. man 1 git-remote).

# cd /var/backup/git/
# git clone --mirror git://repo repo.backup

Puis une tâche dans la cron pour effectuer régulièrement une synchronisation via git.

crontab
50 5 * * * cd /var/backup/git/repo.backup && git remote update

Extraction d'une révision précise

Locale

Il est possible d'exporter une révision particulière du code source, ou une partie de l'arborescence du dépôt.

git archive -o latest_documentation.tar.gz HEAD:doc         # extraction du répertoire doc/ dans sa dernier révision
git archive --prefix=dev-1.4.0/ -o dev-1.4.0.tar.gz v1.4.0  # extraction du tag v1.4.0

Distante

Il est aussi possible de faire ça à travers le réseau de la même façon qu'avec svn export, cependant la configuration par défaut du daemon git ne permet pas le service (cf. man 1 git-daemon).

Afin d'autoriser l'export du code à travers le protocole git, il faut activer le service “upload-archive” dans le fichier de configuration du dépôt :

projet.git/config
[daemon]
    uploadarch = true

Il est alors possible d'effectuer les même commandes que précédemment en spécifiant l'adresse du dépôt :

git archive --remote=git://git.example.org/myproject.git -o latest_documentation.tar.gz HEAD:doc         # extraction du répertoire doc/ dans sa dernier révision
git archive --remote=git://git.example.org/myproject.git --prefix=dev-1.4.0/ -o dev-1.4.0.tar.gz v1.4.0  # extraction du tag v1.4.0

Installation et configuration de Git sur un poste client

Sur un poste client, l'installation de git-core est suffisante pour pouvoir cloner des projets et pour travailler dessus.

# aptitude install git-core

Il peut également être agréable d'avoir une vue graphique de l'historique des projets auquel cas l'application gitg peut être intéressante. Son installation se fait également depuis les dépôts sous Debian. Il existe également gitk qui est cependant un peu moins agréable à utiliser.

# aptitude install gitg

Un point primordial pour travailler avec Git est de configurer son identité qui sera reprise dans chaque commit. Il faut donc procéder ainsi :

$ git config --global user.name "Tintin"
$ git config --global user.email "tintin@example.org"

Il est plus aisé de travailler avec Git s'il on a configuré quelques alias. Les alias permettent de remplacer le nom d'une commande par quelque chose de généralement plus court. Il est possible d'opérer globalement (pour tous les projets gérés par l'utilisateur) en retenant ces alias dans un fichier de paramétrage propre à l'utilisateur.

$ git config --global alias.br branch
$ git config --global alias.ci commit
$ git config --global alias.co checkout
$ git config --global alias.st status

Enfin, il est plus agréable de demander une coloration du retour des commandes Git dans le shell.

$ git config --global color.ui auto

Pour voir le résultat, il faudra afficher le fichier ~/.gitconfig :

$ cat ~/.gitconfig
~/.gitconfig
[user]
    name = Tintin
    email = tintin@example.org
[alias]
    br = branch
    ci = commit
    co = checkout
    st = status
[color]
    ui = auto

Nota bene : Au besoin, on peut refaire ces commandes de paramétrage sans l'option –global (à l'intérieur d'un projet git) pour que cela prime sur la valeur générale.

Enfin, il est possible de faciliter la saisie de commandes Git via l'autocomplètement tel qu'il est offert par le script /etc/bash_completion.d/git en ajoutant un appel à ce dernier dans sa configuration Bash.

$ vim ~/.bashrc
~/.bashrc
# Autocomplètement Git
source /etc/bash_completion.d/git

Voir aussi

  • Pro Git, de Scott Chacon (CC BY-NC-SA 3.0).
serveurs/git.txt · Dernière modification: Sun Mar 17 19:15:11 2013 par kaliko