-
1. Démarrage rapide
-
2. Les bases de Git
-
3. Les branches avec Git
-
4. Git sur le serveur
- 4.1 Protocoles
- 4.2 Installation de Git sur un serveur
- 4.3 Génération des clés publiques SSH
- 4.4 Mise en place du serveur
- 4.5 Démon (Daemon) Git
- 4.6 HTTP intelligent
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Git hébergé
- 4.10 Résumé
-
5. Git distribué
-
6. GitHub
-
7. Utilitaires Git
- 7.1 Sélection des versions
- 7.2 Indexation interactive
- 7.3 Remisage et nettoyage
- 7.4 Signer votre travail
- 7.5 Recherche
- 7.6 Réécrire l’historique
- 7.7 Reset démystifié
- 7.8 Fusion avancée
- 7.9 Rerere
- 7.10 Déboguer avec Git
- 7.11 Sous-modules
- 7.12 Empaquetage (bundling)
- 7.13 Replace
- 7.14 Stockage des identifiants
- 7.15 Résumé
-
8. Personnalisation de Git
- 8.1 Configuration de Git
- 8.2 Attributs Git
- 8.3 Crochets Git
- 8.4 Exemple de politique gérée par Git
- 8.5 Résumé
-
9. Git et les autres systèmes
- 9.1 Git comme client
- 9.2 Migration vers Git
- 9.3 Résumé
-
10. Les tripes de Git
- 10.1 Plomberie et porcelaine
- 10.2 Les objets de Git
- 10.3 Références Git
- 10.4 Fichiers groupés
- 10.5 La refspec
- 10.6 Les protocoles de transfert
- 10.7 Maintenance et récupération de données
- 10.8 Les variables d’environnement
- 10.9 Résumé
-
A1. Annexe A: Git dans d’autres environnements
- A1.1 Interfaces graphiques
- A1.2 Git dans Visual Studio
- A1.3 Git dans Visual Studio Code
- A1.4 Git dans IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine
- A1.5 Git dans Sublime Text
- A1.6 Git dans Bash
- A1.7 Git dans Zsh
- A1.8 Git dans PowerShell
- A1.9 Résumé
-
A2. Annexe B: Embarquer Git dans vos applications
- A2.1 Git en ligne de commande
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
- A2.5 Dulwich
-
A3. Commandes Git
- A3.1 Installation et configuration
- A3.2 Obtention et création des projets
- A3.3 Capture d’instantané basique
- A3.4 Création de branches et fusion
- A3.5 Partage et mise à jour de projets
- A3.6 Inspection et comparaison
- A3.7 Débogage
- A3.8 Patchs
- A3.9 Courriel
- A3.10 Systèmes externes
- A3.11 Administration
- A3.12 Commandes de plomberie
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 recommande fortement d’installer GitLab sur votre serveur via le paquet officiel Omnibus GitLab.
Les autres options d’installation de GitLab sont :
-
GitLab Helm chart, pour une utilisation avec Kubernetes,
-
des paquets GitLab dockerisés pour une utilisation dans Docker,
-
depuis les fichiers source,
-
Avec un fournisseur Cloud tel que AWS, Google Cloud Platform, Azure, OpenShift et Digital Ocean.
Pour de plus amples informations, référez-vous au readme de GitLab Community Edition (CE).
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.
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 https://serveur/jane/projet
.
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 https://serveur/formation/matériel
.
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 une 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.