Git
Chapters ▾ 2nd Edition

4.8 Git sur le serveur - GitLab

GitLab

GitWeb reste tout de même simpliste. Si vous cherchez un serveur Git plus moderne et complet, il existe quelques solutions libres pertinentes. Comme GitLab est un des plus populaires, nous allons prendre son installation et son utilisation comme exemple. Cette solution est plus complexe que l’option GitWeb et demandera indubitablement plus de maintenance, mais elle est aussi plus complète.

Installation

GitLab est une application web reposant sur une base de données, ce qui rend son installation un peu plus lourde que certains autres serveurs Git. Celle-ci est heureusement très bien documentée et supportée.

GitLab peut s’installer de différentes manières. Pour obtenir rapidement quelque chose qui tourne, vous pouvez télécharger une image de machine virtuelle ou un installateur rapide depuis https://bitnami.com/stack/gitlab, puis configurer plus finement selon vos besoins. Une touche particulière incluse par Bitnami concerne l’écran d’identification (accessible via alt-→) qui vous indique l’adresse IP, l’utilisateur et le mot de passe par défaut de l’instance GitLab installée.

L'écran d’identification de la machine virtuelle du GitLab de Bitnami.
Figure 50. L’écran d’identification de la machine virtuelle du GitLab de Bitnami.

Pour toute autre méthode, suivez les instructions du readme du GitLab Community Edition, qui est consultable à https://gitlab.com/gitlab-org/gitlab-ce/tree/master. Vous y trouverez une aide pour installer GitLab en utilisant une recette Chef, une machine virtuelle sur Digital Ocean, ou encore via RPM ou DEB (qui, au moment de la rédaction du présent livre sont en bêta). Il existe aussi des guides « non-officiels » pour faire fonctionner GitLab avec des systèmes d’exploitation ou de base données non standards, un script d’installation totalement manuel et d’autres guides couvrant d’autres sujets.

Administration

L’interface d’administration de GitLab passe par le web. Pointez simplement votre navigateur sur le nom d’hôte ou l’adresse IP où GitLab est hébergé et identifiez-vous comme administrateur. L’utilisateur par défaut est admin@local.host et le mot de passe par défaut est 5iveL!fe (qu’il vous sera demandé de changer dès la première connexion). Une fois identifié, cliquez sur l’icône « Admin area » dans le menu en haut à droite.

L’entrée « Admin area » dans le menu GitLab.
Figure 51. L’entrée « Admin area » dans le menu GitLab.

Utilisateurs

Les utilisateurs dans GitLab sont des comptes qui correspondent à des personnes. Les comptes utilisateurs ne sont pas très complexes ; ce sont principalement des collections d’informations personnelles rattachées à chaque information d’identification. Chaque compte utilisateur fournit un espace de nommage, qui est un rassemblement logique des projets appartenant à cet utilisateur. Si l’utilisateur jane a un projet appelé projet, l’URL du projet est http://serveur/jane/projet.

L'écran d'administration des utilisateurs GitLab.
Figure 52. L’écran d’administration des utilisateurs GitLab.

Il existe deux manières de supprimer un utilisateur. Bloquer (Blocking) un utilisateur l’empêche de s’identifier sur l’instance Gitlab, mais toutes les données sous l’espace de nom de cet utilisateur sont préservées, et les commits signés avec l’adresse courriel de cet utilisateur renverront à son profil.

Détruire (Destroying) un utilisateur, par contre, l’efface complètement de la base de données et du système de fichiers. Tous les projets et les données situées dans son espace de nom sont effacés et tous les groupes qui lui appartiennent sont aussi effacés. Il s’agit clairement d’une action plus destructive et permanente, et son usage est assez rare.

Groupes

Un groupe GitLab est un assemblage de projets, accompagné des informations de droits d’accès à ces projets. Chaque groupe a un espace de nom de projet (de la même manière que les utilisateurs), donc si le groupe formation a un projet matériel, son URL sera http://serveur/formation/matériel.

L'écran d'administration des groupes GitLab.
Figure 53. L’écran d’administration des groupes GitLab.

Chaque groupe est associé à des utilisateurs, dont chacun dispose d’un niveau de permissions sur les projets du groupe et sur le groupe lui-même. Ces niveaux s’échelonnent de invité : Guest (tickets et discussions seulement) à propriétaire : Owner (contrôle complet du groupe, ses membres et ses projets). Les types de permissions sont trop nombreux pour être énumérés ici, mais GitLab fournit un lien très utile sur son écran d’administration.

Projets

Un projet GitLab correspond grossièrement à un dépôt Git unique. Tous les projets appartiennent à un espace de nom unique, que ce soit un utilisateur ou un groupe. Si le projet appartient à un utilisateur, le propriétaire du projet contrôle directement les droits d’accès au projet ; si le projet appartient à un groupe, le niveau de permission de l’utilisateur pour le groupe est aussi pris en compte.

Tous les projets ont un niveau de visibilité qui permet de contrôler qui a accès en lecture aux pages et au dépôt de ce projet. Si un projet est privé (Private), l’accès au projet doit être explicitement accordé par le propriétaire du projet à chaque utilisateur. Un projet interne (Internal) est visible par tout utilisateur identifié, et un projet public (Public) est un projet visible par tout le monde. Notez que ces droits contrôlent aussi bien les accès pour git fetch que les accès à l’interface utilisateur web du projet.

Crochets (Hooks)

GitLab inclut le support pour les crochets, tant au niveau projet que système. Pour ces deux niveaux, le serveur GitLab lance des requêtes HTTP POST contenant un JSON de description lorsque certains événements précis arrivent. C’est une excellent moyen de connecter vos dépôts Git et votre instance GitLab avec le reste de vos automatisations de développement, telles que serveurs d’intégration continue, forum de discussion et outils de déploiement.

Usage de base

La première chose à faire avec GitLab est de créer un nouveau projet. Pour cela, il suffit de cliquer sur l’icône + sur la barre d’outils. On vous demande le nom du projet, à quel espace de nom il appartient, et son niveau de visibilité. La plupart des configurations demandées ici ne sont pas permanentes et peuvent être réajustées plus tard grâce à l’interface de paramétrage. Cliquez sur Create Project pour achever la création.

Une fois le projet créé, on peut le connecter à un dépôt Git local. Chaque projet est accessible sur HTTPS ou SSH, qui peuvent donc être utilisés pour un dépôt distant. Les URLs sont visibles en haut de la page du projet. Pour un dépôt local existant, cette commande crée un dépôt distant nommé gitlab pointant vers l’hébergement distant :

$ git remote add gitlab https://serveur/espace_de_nom/projet.git

Si vous n’avez pas de copie locale du dépôt, vous pouvez simplement taper ceci :

$ git clone https://serveur/espace_de_nom/projet.git

L’interface utilisateur web donne accès à différentes vues utiles du dépôt lui-même. La page d’accueil de chaque projet montre l’activité récente et des liens alignés en haut vous mènent aux fichiers du projet et au journal des commits.

Coopérer

Le moyen le plus simple de coopérer sur un projet GitLab consiste à donner à un autre utilisateur un accès direct en écriture sur le dépôt Git. Vous pouvez ajouter un utilisateur à un projet en sélectionnant la section Members des paramètres du projet et en associant le nouvel utilisateur à un niveau d’accès (les différents niveaux d’accès sont abordés dans Groupes). En donnant un niveau d’accès Developer ou plus à un utilisateur, cet utilisateur peut pousser des commits et des branches directement sur le dépôt sans restriction.

Un autre moyen plus découplé de collaborer est d’utiliser des requêtes de tirage (pull request). Cette fonction permet à n’importe quel utilisateur qui peut voir le projet d’y contribuer de manière contrôlée. Les utilisateurs avec un accès direct peuvent simplement créer une branche, pousser des commits dessus et ouvrir une requête de tirage depuis leur branche vers master ou toute autre branche. Les utilisateurs qui n’ont pas la permission de pousser sur un dépôt peuvent en faire un fork (créer leur propre copie), pousser des commits sur cette copie et ouvrir une requête de tirage depuis leur fork vers le projet principal. Ce modèle permet au propriétaire de garder le contrôle total sur ce qui entre dans le dépôt et quand, tout en autorisant les contributions des utilisateurs non fiables.

Les requêtes de fusion (merge requests) et les problèmes (issues) sont les principaux moyens pour mener des discussions au long cours dans GitLab. Chaque requête de fusion permet une discussion ligne par ligne sur les modifications proposées (qui permettent un sorte de revue de code légère), ainsi qu’un fil de discussion général. Requêtes de fusion et problèmes peuvent être assignés à des utilisateurs ou assemblés en jalons (milestones).

Cette section se concentre principalement sur les parties de GitLab dédiées à Git, mais c’est un système assez mature qui fournit beaucoup d’autres fonctions qui peuvent aider votre équipe à coopérer. Parmi celles-ci figurent les wikis, les murs de discussion et des outils de maintenance du système. Un des bénéfices de GitLab est que, une fois le serveur paramétré et en marche, vous n’aurez pas besoin de bricoler un fichier de configuration ou d’accéder au serveur via SSH ; la plupart des tâches générales ou d’administration peuvent se réaliser à travers l’interface web.