Table des matières
Ceci est une ancienne révision du document !
Dépôts git
Qu'est-ce que « Git » ?
Git est un programme informatique permettant de garder un historique de différentes versions d'un fichier ou d'un dossier.
Avec Git, vous pouvez donc remonter dans le temps et retrouver un document dans un état précédent.
Git est un programme que vous installez sur votre machine. Il est possible de synchroniser votre copie locale de vos fichiers / dossiers avec un serveur distant.
Quand vous versionnez un dossier, celui-ci devient un “dépôt git”. Pour parler d'un dépôt hébergé sur un serveur on parle alors de “dépôt distant”.
Plusieurs utilisateurs peuvent utiliser le même serveur Git. Il est possible de travailler en même temps que quelqu'un d'autre sur un même projet.
Chaque utilisateur d'un dépôt Git dispose d'une copie locale du projet : ainsi, si le serveur tombe, les différents utilisateurs peuvent reconstruire le dépôt distant avec les dernières sauvegardes (“commits”) dont ils disposent.
La communication entre un dépôt Git distant et votre machine peut passer par différents protocoles. Le plus commun est SSH. C'est pour cela qu'il vous faut avoir une paire de clés SSH pour récupérer un dépôt (on parle alors de “cloner” un dépôt), mettre à jour un dépôt (on parle de “push”) ou encore pour récupérer la dernière mise à jour (on parle de “pull”).
L'intérêt de s'en servir
Ç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)
Liste des dépôts
Les dépôts sont gérés par Gitlab.
Voici les principaux dépôts utilisés par l'association :
Nom du dépôt | Description | Conditions d'accès |
---|---|---|
membres | Dépôt dédié aux membres et aux documents sur la vie de l'association : Comptes-rendus de réunion, d'assemblée générale, etc. | Accès réservé aux membres |
graphisme | Dépôt dédié aux documents graphiques : logos, flyer, templates, etc. | Accès libre |
sdtan | Dépôt dédié au projet sur le SDTAN (schémas directeurs territoriaux d'aménagement numérique) | Accès libre |
adminsys | Dépôt dédié au groupe de travail adminsys | Accès réservé |
site-pelican | Dépôt dédié à notre site Internet - Techno : Pelican | Accès libre |
si | Dépôt dédié à notre SI : Coin - Techno : Django | Accès réservé |
Comment accéder aux dépôts de FAImaison ?
Rendez-vous sur la page dédiée à Gitlab
Serveurs git
Voir page backups.
Le service git est accessible via SSH (voir ci-dessous pour les autres méthodes d'accès) :
Machine | Nom | Role | Contact | utilisateur SSH | Soft |
---|---|---|---|---|---|
riboul.faimaison.net | git.faimaison.net | Maître | adminsys@faimaison.net | git | gitlab |
chomsky.autogeree.net | git-slave.faimaison.net | Esclave | jca+fma@wxcvbn.org | faimaison-git | git-daemon |
Méthodes d'accès
Voir Gitlab
Utilisation en lecture/écriture
Authentification
Toute l'authentification passe par SSH, gitolite ne s'occupe que des aspects liés à git.
Générer sa paire de clés SSH
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).
Utilisation
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.
Création d'un nouveau dépôt
Pour créer un nouveau dépôt, vous pouvez-le faire via l'interface Web de Gitlab
Mise à jour du dépôt distant
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
Recevoir les notifications
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
.
Troubleshooting
Erreur de connexion SSH
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
Documentation sur git
- [en] http://schacon.github.com/git/gittutorial.html (tutoriel officiel) ;
- [en] http://progit.org/ ;
- [en] https://git.wiki.kernel.org/articles/g/i/t/GitSvnCrashCourse_512d.html (pour les gens qui sont habitués à SVN).
Configuration de gitolite
Architecture
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
etgit-slave.faimaison.net
.
Remise en route
(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