GitLab : héberger et partager un projet
Temps de lecture10 minEn bref
Résumé de l’article
GitLab est le serveur sur lequel vivront vos dépôts partagés. Cet article montre comment y créer un projet, récupérer l’URL à cloner, et donner accès à vos coéquipier(ère)s en choisissant leur rôle.
La seconde partie traite de l’authentification par clés SSH : comment en générer une paire, quoi déposer sur GitLab, et pourquoi la clé privée ne quitte jamais votre machine. Une fois cela en place, clone, push et pull fonctionnent sans vous redemander de mot de passe.
Points clés à retenir
- GitLab n’est qu’un dépôt Git de plus, hébergé sur un serveur, avec une interface web par-dessus. Tout ce que vous y faites reste du Git.
- Deux instances de l’école sont utilisées selon les cours : gitlab.imt-atlantique.fr et gitlab-df.imt-atlantique.fr.
- Le rôle donné à un membre détermine ce qu’il peut faire. Pour un travail de groupe où tout le monde pousse du code, Developer suffit ; Maintainer ajoute la gestion du projet.
- La clé privée ne se partage jamais, sous aucun prétexte. Seule la clé publique, avec l’extension
.pub, est déposée sur GitLab. - N’ajoutez pas de README à la création si vous comptez y envoyer un dépôt local déjà existant : vous vous éviterez un conflit dès le premier
push.
Contenu de l’article
Aperçu de l’interface
Voici la page d’accueil de GitLab après votre première connexion. À gauche, le menu donne accès à toutes les fonctionnalités.
Créer un projet
Depuis le menu de gauche :
Sans besoin particulier, choisissez Blank Project :
Configurez votre nouveau projet, puis cliquez sur Create project :
Deux réglages méritent votre attention :
- La visibilité – Private, Internal ou Public. Elle est modifiable plus tard.
- L’ajout d’un fichier README – Cela dépend de votre point de départ. Si vous commencez le projet sur GitLab, ajoutez-en un. Si vous avez déjà un dépôt local que vous voulez envoyer vers ce projet, n’en ajoutez pas : le dépôt distant contiendrait un commit que votre dépôt local n’a pas, et votre premier
pushserait refusé.
Récupérer l’URL de clonage
Si vous avez configuré vos clés SSH, utilisez l’URL Clone with SSH ; sinon, l’URL Clone with HTTPS.
Ajouter des membres à un projet
Depuis le menu de gauche :
Puis choisissez le rôle du nouveau membre :
| Rôle | Ce qu’il permet |
|---|---|
| Guest | Voir le projet, commenter les issues et merge requests. Ne peut pas pousser de code. |
| Reporter | Voir et cloner le dépôt, voir les pipelines, créer et fermer des issues. Lecture seule sur le code. |
| Developer | Pousser du code, créer et gérer des merge requests, déclencher les pipelines, gérer les tags. Le rôle du contributeur(rice) courant(e). |
| Maintainer | Tout ce qui précède, plus la gestion du projet : branches protégées, approbation des merge requests, ajout et retrait de membres. |
| Owner | Contrôle total, y compris la suppression du projet et la gestion des autres Owners. |
La liste complète des permissions est décrite dans la documentation GitLab.
S’authentifier par clés SSH
GitLab utilise le protocole SSH pour communiquer de manière sécurisée avec Git. Lorsque vous utilisez les clés SSH pour vous authentifier sur le serveur distant GitLab, vous n’avez pas besoin de fournir votre nom d’utilisateur et votre mot de passe à chaque fois.
(source : docs.gitlab.com)
Le principe est celui du chiffrement asymétrique : vous générez deux clés qui vont ensemble. La clé privée reste sur votre machine et n’en sort jamais ; la clé publique est déposée sur GitLab, qui s’en sert pour vérifier que c’est bien vous.
Générer une paire de clés
Plusieurs algorithmes existent ; le plus moderne accepté par GitLab est ed25519 :
-tdéfinit le type de clé – ne le changez pas sans raison.-fdéfinit le chemin et le nom du fichier de clé privée. La clé publique porte le même nom, suivi de.pub.-Cintègre un commentaire dans la clé publique ; GitLab s’en servira comme titre.
La commande vous demande une phrase de passe. Elle est optionnelle ici, mais c’est ce qui protège votre clé privée si votre machine est compromise.
Déposer la clé publique sur GitLab
Allez dans Edit profile :
Puis dans SSH keys, et cliquez sur Add new key :
Affichez le contenu de votre clé publique pour le copier :
Collez ce contenu dans le champ Key, puis cliquez sur Add key :
Le champ Title est prérempli avec le commentaire fourni par l’option -C. Vous pouvez aussi fixer une date d’expiration. À partir de là, clone, push, pull et fetch fonctionnent sans mot de passe.
Attention
La clé privée est conservée par le client et doit être gardée absolument secrète. Tout compromis de la clé privée permettra à un attaquant de se connecter aux serveurs configurés avec la clé publique associée, sans autre authentification. C’est pourquoi la clé peut être chiffrée sur le disque au moyen d’une phrase de passe.
La clé publique associée peut être partagée librement, sans aucune conséquence négative : c’est précisément son rôle.
Concrètement : ne collez jamais le contenu d’un fichier sans extension .pub dans une interface web, un message ou un dépôt Git.
Pour aller plus loin
Vérifier que la connexion SSH fonctionne
Avant de vous demander pourquoi un push échoue, testez l’authentification seule :
Un message de bienvenue mentionnant votre identifiant signifie que tout est en place. Un Permission denied (publickey) signifie que la clé n’est pas trouvée ou pas déclarée sur le serveur.
Les issues et les merge requests
GitLab n’est pas qu’un espace de stockage : il propose un suivi de tâches (issues) et un mécanisme de relecture de code avant intégration (merge requests). Vous les utiliserez dans le projet du semestre, où ils servent à répartir le travail et à garder une trace des décisions. La documentation officielle en donne un aperçu.