2779
Commentaire: quelques corrections...
|
3292
s/group/user/
|
Texte supprimé. | Texte ajouté. |
Ligne 2: | Ligne 2: |
||<bgcolor="#FFFF00"> Note : dans toute cette page, il faut remplacer '''PROJET''' par le nom de votre projet (par exemple `auf-postclient`).|| |
|
Ligne 15: | Ligne 18: |
$ git clone http://git.auf.org/git/projet | $ git clone http://git.auf.org/git/PROJET |
Ligne 20: | Ligne 23: |
$ cd projet | $ cd PROJET |
Ligne 29: | Ligne 32: |
$ git push ssh://git.auf/~user/projet | $ git push ssh://git.auf/~user/PROJET |
Ligne 38: | Ligne 41: |
$ git clone --bare ~/projet projet.export $ rsync -a projet.export user@git.auf:projet $ rm -rf projet.export |
$ git clone --bare ~/PROJET PROJET.export $ rsync -a PROJET.export user@git.auf:PROJET $ rm -rf PROJET.export |
Ligne 45: | Ligne 48: |
$ cd ~user/projet/ | $ cd ~user/PROJET/ |
Ligne 55: | Ligne 58: |
$ sudo ln -s ~user/projet . | $ sudo ln -s ~user/PROJET . |
Ligne 62: | Ligne 65: |
== Eviter un accès shell complet via ssh == | Pour que l'accès ''ssh'' soit restreint aux commandes git nécessaires, on met le shell de connexion de l'utilisateur à `/usr/bin/git-shell`<<FootNote(Ni `rssh` ni `scponly` ne fonctionnent, notamment par rapport à la notion de hooks)>>. |
Ligne 64: | Ligne 67: |
Pour que l'accès ''ssh'' soit restreint aux commandes git nécessaires, on met le shell de connexion de l'utilisateur à `/usr/bin/git-shell`<<FootNote(Ni `rssh` ni `scponly` ne fonctionnent, notamment par rapport à la notion de hooks)>>. | Exemple de création du compte (à faire '''avant''' le transfert du projet) : {{{ $ sudo adduser --shell /usr/bin/git-shell --gecos "Projet PROJET" --disabled-password git-PROJET $ sudo adduser git-PROJET ssh $ sudo mv ~user/PROJET ~git-PROJET/ $ sudo chown -R git-PROJET:git-PROJET ~git-PROJET/ }}} Ne pas oublier de copier les clés nécessaires dans le fichier `~git-PROJET/.ssh/authorized_keys` ! |
Note : dans toute cette page, il faut remplacer PROJET par le nom de votre projet (par exemple auf-postclient). |
Un dépôt git est disponible à l'AUF. Il permet :
- à quiconque de suivre les développements AUF ;
- à tout technicien AUF d'y présenter ses développements.
Les projets publics de ce dépôt sont visibles ici : http://git.auf.org/
Ci-dessous un résumé (pense-bête) des commandes à utiliser pour exploiter ce service. Si vous voulez vraiment savoir utiliser git, consultez d'abord la documentation officielle.
Télécharger et suivre d'un projet
Premier téléchargement :
$ git clone http://git.auf.org/git/PROJET
Télécharger les mises à jour :
$ cd PROJET $ git pull
Participer à un projet (droits en écriture)
Nécessite un accès RPV + ssh.
$ git push ssh://git.auf/~user/PROJET
Création d'un projet
Nécessite un accès RPV + ssh.
Sur la machine où le projet est présent :
$ git clone --bare ~/PROJET PROJET.export $ rsync -a PROJET.export user@git.auf:PROJET $ rm -rf PROJET.export
Sur le serveur :
$ cd ~user/PROJET/ $ echo "Description du projet en 35 caractères (ou plus)." > description $ touch git-daemon-export-ok $ git --bare update-server-info $ chmod a+x hooks/post-update
Publication via http et vue sur gitweb (optionnelles) :
$ cd /srv/git/ $ sudo ln -s ~user/PROJET .
Partage en écriture
Si plusieurs personnes doivent intervenir sur le projet, on peut créer un compte "virtuel" accessible par ssh à un ensemble de clés bien défini. L'adresse publique ne changera pas.
Pour que l'accès ssh soit restreint aux commandes git nécessaires, on met le shell de connexion de l'utilisateur à /usr/bin/git-shell1.
Exemple de création du compte (à faire avant le transfert du projet) :
$ sudo adduser --shell /usr/bin/git-shell --gecos "Projet PROJET" --disabled-password git-PROJET $ sudo adduser git-PROJET ssh $ sudo mv ~user/PROJET ~git-PROJET/ $ sudo chown -R git-PROJET:git-PROJET ~git-PROJET/
Ne pas oublier de copier les clés nécessaires dans le fichier ~git-PROJET/.ssh/authorized_keys !
Ce qui reste à faire : rien...
http://eagain.net/blog/2007/03/22/howto-host-git.html : hébergement de gits, à étudier (lu en diagonale)
- rsync public pour accès rsync
webdav ? Mmh, les droits d'écriture à "www-data" ne me plaisent pas. Ceci dit, pour un accès public, c'est-à-dire écriture depuis en dehors du RPV... Entre ça et des comptes avec git-shell sur un port autre que 22, mon coeur balance.
- git-daemon pour accès git:// plus optimisé : pas vraiment nécessaire
- dissocier gitweb de la publication via http (c'est-à-dire ne pas rendre tous les projets publics visibles via gitweb) : possible mais plutôt inutile
Notes de bas de page :
Ni rssh ni scponly ne fonctionnent, notamment par rapport à la notion de hooks (1)