À écrire. Notions de dépôt et éventuellement de branche. Vocabulaire comme commit, push, … Un mot sur l'authentification.

Ça permet de travailler facilement à plusieurs sur des documents et/ou du code.

Plus spécifiquement :

• documents de l'asso (règlement intérieur, etc)
• compte-rendus de réunion
• travail graphique (même si c'est pas super de faire du versioning sur des fichiers binaires)
• développement d'outils pour l'asso (site, SI, etc)

TODO : compléter avec les dépôts restants

Reprendre des infos ci-dessous, reformuler version user-friendly. Ajouter quelques noms de logiciels avec interface graphique.

Voir page backups.

Le service git est accessible via SSH (voir ci-dessous pour les autres méthodes d'accès) :

• faimaison-git@git.faimaison.net (maître)
• faimaison-git@git-slave.faimaison.net (esclave)

Le dépôt git de FAImaison est accessible par les moyens suivants :

• git-daemon (lecture uniquement)
• gitweb (lecture uniquement)
• gitolite via ssh (lecture/écriture avec contrôle d'accès)

Ces méthodes d'accès ne demandant aucune authentification, certains dépôts ne sont pas accessibles par ce biais.

Il est possible de cloner n'importe quel dépôt accessible en lecture :

git clone git://git.faimaison.net/testing

Pour obtenir la liste des dépôts disponibles, il faut passer par gitolite ou gitweb.

Accessible sur http://git.faimaison.net (redirection “temporaire”).

Toute l'authentification passe par SSH, gitolite ne s'occupe que des aspects liés à git.

Autant que possible, on se base sur des clés RSA sur 4096 bits :

  $ umask 077
  $ mkdir -p ~/.ssh/
  $ ssh-keygen -t rsa -b 4096 -f ~/.ssh/faimaison
    # <éventuellement entrer une passphrase>
  $

Chaque utilisateur est responsable de sa clé privée ; placer une passphrase sur sa clé ssh est fortement recommandé. Ceci a pour but d'empêcher un tiers d'utiliser votre clé (il lui faudra connaître votre passphrase).

Pour avoir accès au dépôt git, il faut envoyer la clé publique générée (~/.ssh/faimaison.pub), avec le nom d'utilisateur souhaité, aux administrateurs de gitolite à l'adresse git (chez) faimaison.net.

Les administrateurs doivent pouvoir vérifier votre identité, ce qui se fait principalement par deux biais :

• soit en signant votre mail avec GPG. Çela suppose qu'au moins un des membres de l'association ait signé votre clé GPG (pour qu'on puisse vérifier votre identité).
• soit on vient à une réunion avec sa clé publique SSH sur une clé USB.

Si vous envoyez votre clé publique par mail, faites le avec une pièce jointe. En effet copier/coller une clé est le meilleur moyen de la retrouver en morceaux.

Fonctionnement : tout se fait en ssh en passant par gitolite. Si on essaie de se connecter directement :

ssh -i ~/.ssh/faimaison faimaison-git@git.faimaison.net info

on a la liste des dépôts accessibles en lecture et/ou écriture.

Pour dire à ssh de toujours utiliser cette clé et cet utilisateur (et donc pour simplifier la vie à git), on peut mettre quelque chose du genre dans son fichier ~/.ssh/config :

Host git.faimaison.net
    IdentityFile ~/.ssh/faimaison
    User faimaison-git

Ensuite, il suffit de cloner comme d'habitude :

git clone git.faimaison.net:testing

Noter qu'en l'absence de précision du protocole (e.g. git://git.faimaison.net ou ssh://git.faimaison.net), git utilise ssh.

Pour créer un nouveau dépôt, il faut contacter les administrateurs (voir adresse email ci-dessus).

Une fois que votre nouveau dépôt a été créé, pour y pousser votre travail local, il faut commencer par renseigner son URL :

git remote add origin git.faimaison.net:mon_beau_depot

En d'envoyer le tout :

git push --set-upstream origin master

Par la suite, un simple git push suffit.

Et pour récupérer le travail de vos camarades :

git pull

Dès que des commits sont poussés sur le serveur, un mail de notification est envoyé sur une liste de diffusion dédiée (notifications-git@faimaison.net). Pour recevoir ces notifications, envoyez votre demande aux administrateurs à adminsys@faimaison.net.

Si un message d'erreur du type :

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

apparaît, il y a deux possibilités :

• quelqu'un fait effectivement quelque chose de pas très sympathique entre vous et le serveur (spoofing DNS, man-in-the-middle, etc) → mauvais présage
• la machine qui répond derrière git.faimaison.net a changé (basculement de l'esclave en maître, etc) → innocent

Si il s'agit du second cas (vérifiez ! il y a sûrement eu une annonce sur la liste de diffusion membres), il suffit de supprimer le fingerprint fautif du fichier ~/.ssh/known_hosts :

$ ssh-keygen -R git.faimaison.net

• [en] http://schacon.github.com/git/gittutorial.html (tutoriel officiel) ;
• [en] http://progit.org/ ;
• [fr] http://www-cs-students.stanford.edu/~blynn/gitmagic/intl/fr/ ;
• [en] https://git.wiki.kernel.org/articles/g/i/t/GitSvnCrashCourse_512d.html (pour les gens qui sont habitués à SVN).

On utilise les fonctionnalités de réplication de gitolite. La machine git.faimaison.net représente le serveur maître, git-slave.faimaison.net représente le serveur esclave.

Chaque “push” sur le serveur maître est immédiatement répliqué sur le serveur esclave. Vous pouvez aussi pousser sur le serveur esclave, auquel cas les modifications sont d'abord renvoyées sur le serveur maître.

Si jamais le serveur maître est inaccessible, on peut lire sur le serveur de secours, mais pas pousser de modifications.

Si l'on pense que le master restera inaccessible longtemps, il faut :

• contacter l'administrateur du serveur esclave, afin qu'il passe gitolite en mode “maître”. Ceci suffit pour pouvoir continuer à pousser sur le serveur de secours.
• intervertir les enregistrements DNS de git.faimaison.net et git-slave.faimaison.net.

(Note aux administrateurs des services gitolite)

Si le master est down pour de bon, il faut passer le slave en master :

• modifier le ~/.gitolite/conf/gitolite.conf et échanger master/slave
• faire un gl-compile-conf (peut nécessiter de placer certaines variables d'environnement)
• si la modification est définitive, modifier dans le dépôt gitolite-admin le fichier conf/gitolite.conf et pusher sur le nouveau master.
• quand le nouveau slave est disponible, modifier sa conf de la même façon