Git
Chapters ▾ 2nd Edition

4.2 Git sur le serveur - Installation de Git sur un serveur

Installation de Git sur un serveur

Nous allons à présent traiter de la configuration d’un service Git gérant ces protocoles sur votre propre serveur.

Note

Les commandes et étapes décrites ci-après s’appliquent à des installations simplifiées sur un serveur à base de Linux, bien qu’il soit aussi possible de faire fonctionner ces services sur des serveurs macOS ou Windows. La mise en place effective d’un serveur en production au sein d’une infrastructure englobera vraisemblablement des différences dans les mesures de sécurité et les outils système, mais ceci devrait permettre de se faire une idée générale des besoins.

Pour réaliser l’installation initiale d’un serveur Git, il faut exporter un dépôt existant dans un nouveau dépôt nu — un dépôt qui ne contient pas de copie de répertoire de travail. C’est généralement simple à faire. Pour cloner votre dépôt en créant un nouveau dépôt nu, lancez la commande clone avec l’option --bare. Par convention, les répertoires de dépôt nu finissent en .git, de cette manière :

$ git clone --bare mon_project mon_projet.git
Clonage dans le dépôt nu 'mon_projet.git'...
fait.

Vous devriez maintenant avoir une copie des données de Git dans votre répertoire mon_project.git.

C’est grossièrement équivalent à :

$ cp -Rf mon_projet/.git mon_projet.git

Il y a quelques légères différences dans le fichier de configuration mais pour l’utilisation envisagée, c’est très proche. La commande extrait le répertoire Git sans répertoire de travail et crée un répertoire spécifique pour l’accueillir.

Copie du dépôt nu sur un serveur

À présent que vous avez une copie nue de votre dépôt, il ne reste plus qu’à la placer sur un serveur et à régler les protocoles. Supposons que vous avez mis en place un serveur nommé git.exemple.com auquel vous avez accès par SSH et que vous souhaitez stocker vos dépôts Git dans le répertoire /srv/git. En supposant que /srv/git existe, vous pouvez mettre en place votre dépôt en copiant le dépôt nu :

$ scp -r mon_projet.git utilisateur@git.exemple.com:/srv/git

À partir de maintenant, tous les autres utilisateurs disposant d’un accès SSH au serveur et ayant un accès en lecture seule au répertoire /srv/git peuvent cloner votre dépôt en lançant la commande :

$ git clone utilisateur@git.exemple.com:/srv/git/mon_projet.git

Si un utilisateur se connecte via SSH au serveur et a accès en écriture au répertoire /srv/git/mon_projet.git, il aura automatiquement accès pour pousser.

Git ajoutera automatiquement les droits de groupe en écriture à un dépôt si vous lancez la commande git init avec l’option --shared. Notez qu’en lançant cette commande, vous ne détruirez pas les commits, références, etc. en cours de route.

$ ssh utilisateur@git.exemple.com
$ cd /srv/git/mon_projet.git
$ git init --bare --shared

Vous voyez comme il est simple de prendre un dépôt Git, créer une version nue et la placer sur un serveur auquel vous et vos collaborateurs avez accès en SSH. Vous voilà prêts à collaborer sur le même projet.

Il faut noter que c’est littéralement tout ce dont vous avez besoin pour démarrer un serveur Git utile auquel plusieurs personnes ont accès : ajoutez simplement des comptes SSH sur un serveur, et collez un dépôt nu quelque part où tous les utilisateurs ont accès en lecture et écriture. Vous êtes prêts à travailler, vous n’avez besoin de rien d’autre.

Dans les chapitres à venir, nous traiterons de mises en place plus sophistiquées. Ces sujets incluront l’élimination du besoin de créer un compte système pour chaque utilisateur, l’accès public aux dépôts, la mise en place d’interfaces utilisateur web, etc. Néanmoins, gardez à l’esprit que pour collaborer avec quelques personnes sur un projet privé, tout ce qu’il faut, c’est un serveur SSH et un dépôt nu.

Petites installations

Si vous travaillez dans un petit groupe ou si vous n’êtes qu’en phase d’essai de Git au sein de votre société avec peu de développeurs, les choses peuvent rester simples. Un des aspects les plus compliqués de la mise en place d’un serveur Git est la gestion des utilisateurs. Si vous souhaitez que certains dépôts ne soient accessibles à certains utilisateurs qu’en lecture seule et en lecture/écriture pour d’autres, la gestion des accès et des permissions peut devenir difficile à régler.

Accès SSH

Si vous disposez déjà d’un serveur auquel tous vos développeurs ont un accès SSH, il est généralement plus facile d’y mettre en place votre premier dépôt car vous n’aurez quasiment aucun réglage supplémentaire à faire (comme nous l’avons expliqué dans le chapitre précédent). Si vous souhaitez des permissions d’accès plus complexes, vous pouvez les mettre en place par le jeu des permissions standards sur le système de fichiers du système d’exploitation de votre serveur.

Si vous souhaitez placer vos dépôts sur un serveur qui ne dispose pas déjà de comptes pour chacun des membres de votre équipe qui aurait accès en écriture, alors vous devrez mettre en place un accès SSH pour eux. En supposant que pour vos dépôts, vous disposiez déjà d’un serveur SSH installé et auquel vous avez accès.

Il y a quelques moyens de donner un accès à tout le monde dans l’équipe. Le premier est de créer des comptes pour tout le monde, ce qui est logique mais peut s’avérer lourd. Vous ne souhaiteriez sûrement pas lancer adduser et entrer un mot de passe temporaire pour chaque utilisateur.

Une seconde méthode consiste à créer un seul utilisateur Git sur la machine, demander à chaque développeur nécessitant un accès en écriture de vous envoyer une clé publique SSH et d’ajouter la-dite clé au fichier ~/.ssh/authorized_keys de votre utilisateur Git. À partir de là, tout le monde sera capable d’accéder à la machine via l’utilisateur Git. Cela n’affecte en rien les données de commit — les informations de l’utilisateur SSH par lequel on se connecte n’affectent pas les données de commit enregistrées.

Une dernière méthode consiste à faire une authentification SSH auprès d’un serveur LDAP ou tout autre système d’authentification centralisé que vous utiliseriez déjà. Tant que chaque utilisateur peut accéder à un shell sur la machine, n’importe quel schéma d’authentification SSH devrait fonctionner.

scroll-to-top