Git » Historique » Version 64
Version 63 (Matthieu Herrb, 08/06/2014 22:41) → Version 64/69 (Matthieu Herrb, 08/06/2014 22:42)
h1. Installation et utilisation d’un serveur Git
{{>toc}}
"Git":http://git-scm.com/ est un gestionnaire de versions décentralisé, libre et développé en C. À noter la traduction française du "Git community book":http://www.alexgirard.com/git-book/index.html.
La configuration se fera essentiellement au travers de "Gitolite":https://github.com/sitaramc/gitolite, qui permet de créer des dépôts, gérer les accès push/pull pour des accès en SSH, déléguer des droits, etc. @git-daemon@ permet de donner un accès au travers du protocole @git@, et "@cgit@":http://hjemli.net/git/cgit/ sera utilisé pour l’interface web et le pull en HTTP (ou HTTPS).
Les explications qui suivent ont été mises en pratique sur le serveur "@git.tetaneutral.net@":http://git.tetaneutral.net/ de Tetaneutral.net, donc avec une Debian Squeeze.
Lire aussi http://homepages.laas.fr/matthieu/cours/git.pdf
h2. "Gitolite":https://github.com/sitaramc/gitolite
h3. Installation de gitolite
Installation est très simple, sur la VM @git.tetaneutral.net@ :
* On créé l’utilisateur @git@ dédié
* On clone l’application Gitolite avec @git(1)@
* On installe Gitolite dans le répertoire personnel de l’utilisateur @git@
* On ajoute la clé SSH d’un des administrateurs
<pre>
useradd -m git
su - git
git clone git://github.com/sitaramc/gitolite.git
gitolite/src/gl-system-install
gl-setup -q sileht.pub
</pre>
Ensuite récupération sur mon ordi du dépôt @gitolite-admin@ :
<pre>
git clone git@git.tetaneutral.net:gitolite-admin
cd gitolite-admin
</pre>
h3. Configuration
Gitolite est *très* polyvalent, pour des usages poussés, se reporter à la "documentation en ligne":http://sitaramc.github.com/gitolite/.
Une fois Gitolite installé, la configuration des dépôts et des utilisateurs se fait *uniquement* au travers du dépôt @gitolite-admin.git@. Ce dépôt contient deux dossiers:
* @conf@ qui va contenir les fichiers de configuration (le plus souvent un seul, @gitolite.conf@) ;
* @keydir@, qui va stocker les clés publiques SSH des utilisateurs.
Example de configuration :
<pre>
repo testing
RW+ = @all
</pre>
Dans cet example, tous les utilisateurs ayant une clé dans le dépôt @gitolite-admin@ ont tous les droits sur le dépôt @testing@.
Pour mettre à jour cette configuration, il suffit de la commiter et de la pusher, Gitolite appliquera les changements instantanément.
h4. Ajouter un utilisateur
Il suffit d’ajouter sa clé publique dans le dossier @keydir@, en la nommant soit @user.pub@, soit @user@machine.pub@, ce qui permet d’avoir plusieurs clés pour un même utilisateur. On peut avoir des sous-dossier dans @keydir@, c’est sans incidence sur le nommage.
<pre>
git add keydir/user.pub
</pre>
To check and commit push
<pre>
git diff master
git commit -a -m "add user"
git push
</pre>
Dans la configuration de Gitolite, l’utilisateur est désigné par @user@, et on peut faire des groupes :
<pre>
@mongroupe = user1 user2
</pre>
Et ensuite on peut donner des droits au groupe :
<pre>
repo testing
R = @mongroupe user3
</pre>
Le droit de lecture s’applique donc à @user1@, @user2@ et @user3@.
h4. Créer un dépôt
Il suffit de créer la ligne
<pre>
repo monrepo
</pre>
et de préférence d’y ajouter des utilisateurs :)
h4. Checkout Utilisateur
<pre>
git config user.name "Mon Nom"
git config user.email "mon.nom@example.org"
</pre>
h2. git-daemon
h3. Installation
Rien à faire, @git-daemon(1)@ vient avec @git(1)@.
h3. Configuration
La configuration de @git-daemon@ se fait sous Debian dans @/etc/default/git-daemon@.
@git-daemon(1)@ peut être lancé avec l’option @--export-all@, mais c’est peu recommandé si on ne veut pas donner un accès en lecture à tous. On préférera créer dans chaque dépôt à exporter le fichier @git-daemon-export-ok@.
h2. "cgit":http://hjemli.net/git/cgit/
h3. Installation
Comme il n’y a pas de paquet Debian, il faut le compiler à la main.
<pre>
wget http://git.zx2c4.com/cgit/snapshot/cgit-0.9.2.tar.xz
tar xf cgit-0.9.2.tar.xz
cd cgit-0.9.2
make get-git
</pre>
On peut modifier le @Makefile@ en mettant
<pre>CGIT_SCRIPT_PATH = /var/www/htdocs/cgit</pre>
et
<pre>prefix = /var/www/cgit</pre>
Ensuite :
<pre>
make
make install
</pre>
h3. Configuration de cgit
interface web http://git.tetaneutral.net/
cgit récupère la liste des projets dans @~git/projects.list@. Cette liste est générée automatiquement par Gitolite pour les dépôts dont @gitweb@ a les droits en lecture (c’est une dénomination spécifique à gitolite, qui n’est pas incluse dans @@all@). Dans @gitolite.conf@ :
<pre>
repo testing
RW+ = pipo
R = gitweb
</pre>
Pour spécifier le propriétaire et la description d’un dépôt, voir le "manuel de gitolite":http://sitaramc.github.com/gitolite/confother_.html, section « specifying gitweb and daemon access ».
La configuration de @cgit@ se trouve dans @cgitrc(5)@ :
<pre>
virtual-root=/
project-list=/home/git/projects.list
scan-path=~git/repositories/
snapshots=tar.gz tar.bz2
enable-commit-graph=1
enable-tree-linenumbers=1
enable-index-links=1
enable-log-filecount=1
enable-log-linecount=1
max-stats=quarter
clone-prefix=http://git.tetaneutral.net git://git.tetaneutral.net
</pre>
h3. Configuration d’Apache
Pour que le serveur web ait les droits de lecture sur les dépôts, il faut ajouter l’utilisateur @www-data@ (ou l’utilisateur sous lequel tourne Apache) au groupe @git@ :
<pre>
usermod -aG git www-data
</pre>
Dans @~git/.gitolite.rc@, changer
<pre>
$REPO_UMASK = 0077;
</pre>
en
<pre>
$REPO_UMASK = 0027;
</pre>
Ce réglage n’étant valable que pour les nouveaux dépôts, il faut effectuer un @chmod -R g+rX@ sur les dépôts existants (*pas gitolite-admin.git* en général).
À mettre dans un _virtual host_ d’Apache :
<pre>
DocumentRoot /var/www/cgit
<Directory /var/www/cgit>
AddHandler cgi-script .cgi
DirectoryIndex cgit.cgi
Options +FollowSymLinks +ExecCGI
AllowOverride None
Order allow,deny
allow from all
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule (.*) cgit.cgi/$1
RewriteRule ^cgit.cgi$ cgit.cgi/
</Directory>
</pre>
h2. Gestion de dépôts git sous redmine
Ici on considère que redmine et le plugin git_hosting sont installés. L'accès se fait en écriture via une clé SSH, sur le principe de gitolite (c'est d'ailleurs gitolite qui est utilisé par le plugin de redmine). L'exemple est celui du serveur redmine de tetaneutral.net.
h3. Dépot d'une clé publique ssh
# Se connecter à redmine: https://chiliproject.tetaneutral.net/
# Dans « my account » coller une clé publique (fichier id_rsa.pub ou id_*.pub) et sauver la clé.
# Si ce n'est pas la clé par défaut configurer l'accès ssh à git.tetaneutral.net dans ${HOME}/.ssh/config:
<pre>
host git.tetaneutral.net
IdentityFile ~/.ssh/id_ttnn
ForwardAgent no
</pre>
h3. Création d'un dépot
Par convention tous les dépots sont sous le projet 'git.tetaneutral.net', mais ce n'est pas nécessaire.
# Sélectionner Projects->git.tetaneutral.net->Settings
# Sélectionnler l'onglet Repositories
# En bas de la page 'New Repository'
# Donner un nom au nouveau dépôt (identifiant lettres, chiffres ou tirets)
# Cliquer sur 'Create'
h3. Garnir le Accès au dépot
Une fois le dépot créé on peut y pousser du contenu
Si on a un dépot git existant il suffit de définir le dépot 'origin' et de pousser ainsi
<pre>
git remote add origin ssh://git@git.tetaneutral.net/foo.git
git push -u origin master
</pre>
{{>toc}}
"Git":http://git-scm.com/ est un gestionnaire de versions décentralisé, libre et développé en C. À noter la traduction française du "Git community book":http://www.alexgirard.com/git-book/index.html.
La configuration se fera essentiellement au travers de "Gitolite":https://github.com/sitaramc/gitolite, qui permet de créer des dépôts, gérer les accès push/pull pour des accès en SSH, déléguer des droits, etc. @git-daemon@ permet de donner un accès au travers du protocole @git@, et "@cgit@":http://hjemli.net/git/cgit/ sera utilisé pour l’interface web et le pull en HTTP (ou HTTPS).
Les explications qui suivent ont été mises en pratique sur le serveur "@git.tetaneutral.net@":http://git.tetaneutral.net/ de Tetaneutral.net, donc avec une Debian Squeeze.
Lire aussi http://homepages.laas.fr/matthieu/cours/git.pdf
h2. "Gitolite":https://github.com/sitaramc/gitolite
h3. Installation de gitolite
Installation est très simple, sur la VM @git.tetaneutral.net@ :
* On créé l’utilisateur @git@ dédié
* On clone l’application Gitolite avec @git(1)@
* On installe Gitolite dans le répertoire personnel de l’utilisateur @git@
* On ajoute la clé SSH d’un des administrateurs
<pre>
useradd -m git
su - git
git clone git://github.com/sitaramc/gitolite.git
gitolite/src/gl-system-install
gl-setup -q sileht.pub
</pre>
Ensuite récupération sur mon ordi du dépôt @gitolite-admin@ :
<pre>
git clone git@git.tetaneutral.net:gitolite-admin
cd gitolite-admin
</pre>
h3. Configuration
Gitolite est *très* polyvalent, pour des usages poussés, se reporter à la "documentation en ligne":http://sitaramc.github.com/gitolite/.
Une fois Gitolite installé, la configuration des dépôts et des utilisateurs se fait *uniquement* au travers du dépôt @gitolite-admin.git@. Ce dépôt contient deux dossiers:
* @conf@ qui va contenir les fichiers de configuration (le plus souvent un seul, @gitolite.conf@) ;
* @keydir@, qui va stocker les clés publiques SSH des utilisateurs.
Example de configuration :
<pre>
repo testing
RW+ = @all
</pre>
Dans cet example, tous les utilisateurs ayant une clé dans le dépôt @gitolite-admin@ ont tous les droits sur le dépôt @testing@.
Pour mettre à jour cette configuration, il suffit de la commiter et de la pusher, Gitolite appliquera les changements instantanément.
h4. Ajouter un utilisateur
Il suffit d’ajouter sa clé publique dans le dossier @keydir@, en la nommant soit @user.pub@, soit @user@machine.pub@, ce qui permet d’avoir plusieurs clés pour un même utilisateur. On peut avoir des sous-dossier dans @keydir@, c’est sans incidence sur le nommage.
<pre>
git add keydir/user.pub
</pre>
To check and commit push
<pre>
git diff master
git commit -a -m "add user"
git push
</pre>
Dans la configuration de Gitolite, l’utilisateur est désigné par @user@, et on peut faire des groupes :
<pre>
@mongroupe = user1 user2
</pre>
Et ensuite on peut donner des droits au groupe :
<pre>
repo testing
R = @mongroupe user3
</pre>
Le droit de lecture s’applique donc à @user1@, @user2@ et @user3@.
h4. Créer un dépôt
Il suffit de créer la ligne
<pre>
repo monrepo
</pre>
et de préférence d’y ajouter des utilisateurs :)
h4. Checkout Utilisateur
<pre>
git config user.name "Mon Nom"
git config user.email "mon.nom@example.org"
</pre>
h2. git-daemon
h3. Installation
Rien à faire, @git-daemon(1)@ vient avec @git(1)@.
h3. Configuration
La configuration de @git-daemon@ se fait sous Debian dans @/etc/default/git-daemon@.
@git-daemon(1)@ peut être lancé avec l’option @--export-all@, mais c’est peu recommandé si on ne veut pas donner un accès en lecture à tous. On préférera créer dans chaque dépôt à exporter le fichier @git-daemon-export-ok@.
h2. "cgit":http://hjemli.net/git/cgit/
h3. Installation
Comme il n’y a pas de paquet Debian, il faut le compiler à la main.
<pre>
wget http://git.zx2c4.com/cgit/snapshot/cgit-0.9.2.tar.xz
tar xf cgit-0.9.2.tar.xz
cd cgit-0.9.2
make get-git
</pre>
On peut modifier le @Makefile@ en mettant
<pre>CGIT_SCRIPT_PATH = /var/www/htdocs/cgit</pre>
et
<pre>prefix = /var/www/cgit</pre>
Ensuite :
<pre>
make
make install
</pre>
h3. Configuration de cgit
interface web http://git.tetaneutral.net/
cgit récupère la liste des projets dans @~git/projects.list@. Cette liste est générée automatiquement par Gitolite pour les dépôts dont @gitweb@ a les droits en lecture (c’est une dénomination spécifique à gitolite, qui n’est pas incluse dans @@all@). Dans @gitolite.conf@ :
<pre>
repo testing
RW+ = pipo
R = gitweb
</pre>
Pour spécifier le propriétaire et la description d’un dépôt, voir le "manuel de gitolite":http://sitaramc.github.com/gitolite/confother_.html, section « specifying gitweb and daemon access ».
La configuration de @cgit@ se trouve dans @cgitrc(5)@ :
<pre>
virtual-root=/
project-list=/home/git/projects.list
scan-path=~git/repositories/
snapshots=tar.gz tar.bz2
enable-commit-graph=1
enable-tree-linenumbers=1
enable-index-links=1
enable-log-filecount=1
enable-log-linecount=1
max-stats=quarter
clone-prefix=http://git.tetaneutral.net git://git.tetaneutral.net
</pre>
h3. Configuration d’Apache
Pour que le serveur web ait les droits de lecture sur les dépôts, il faut ajouter l’utilisateur @www-data@ (ou l’utilisateur sous lequel tourne Apache) au groupe @git@ :
<pre>
usermod -aG git www-data
</pre>
Dans @~git/.gitolite.rc@, changer
<pre>
$REPO_UMASK = 0077;
</pre>
en
<pre>
$REPO_UMASK = 0027;
</pre>
Ce réglage n’étant valable que pour les nouveaux dépôts, il faut effectuer un @chmod -R g+rX@ sur les dépôts existants (*pas gitolite-admin.git* en général).
À mettre dans un _virtual host_ d’Apache :
<pre>
DocumentRoot /var/www/cgit
<Directory /var/www/cgit>
AddHandler cgi-script .cgi
DirectoryIndex cgit.cgi
Options +FollowSymLinks +ExecCGI
AllowOverride None
Order allow,deny
allow from all
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule (.*) cgit.cgi/$1
RewriteRule ^cgit.cgi$ cgit.cgi/
</Directory>
</pre>
h2. Gestion de dépôts git sous redmine
Ici on considère que redmine et le plugin git_hosting sont installés. L'accès se fait en écriture via une clé SSH, sur le principe de gitolite (c'est d'ailleurs gitolite qui est utilisé par le plugin de redmine). L'exemple est celui du serveur redmine de tetaneutral.net.
h3. Dépot d'une clé publique ssh
# Se connecter à redmine: https://chiliproject.tetaneutral.net/
# Dans « my account » coller une clé publique (fichier id_rsa.pub ou id_*.pub) et sauver la clé.
# Si ce n'est pas la clé par défaut configurer l'accès ssh à git.tetaneutral.net dans ${HOME}/.ssh/config:
<pre>
host git.tetaneutral.net
IdentityFile ~/.ssh/id_ttnn
ForwardAgent no
</pre>
h3. Création d'un dépot
Par convention tous les dépots sont sous le projet 'git.tetaneutral.net', mais ce n'est pas nécessaire.
# Sélectionner Projects->git.tetaneutral.net->Settings
# Sélectionnler l'onglet Repositories
# En bas de la page 'New Repository'
# Donner un nom au nouveau dépôt (identifiant lettres, chiffres ou tirets)
# Cliquer sur 'Create'
h3. Garnir le Accès au dépot
Une fois le dépot créé on peut y pousser du contenu
Si on a un dépot git existant il suffit de définir le dépot 'origin' et de pousser ainsi
<pre>
git remote add origin ssh://git@git.tetaneutral.net/foo.git
git push -u origin master
</pre>