Pour collaborer, vos dépôts Git doivent être accessibles à distance, que ce soit sur un serveur que vous gérez ou sur une plateforme hébergée. Cette section couvre les protocoles de transport (SSH, HTTPS, Git protocol), la mise en place d'un serveur Git bare, et le comparatif des plateformes majeures.
L'infrastructure derrière git push
Section intitulée « L'infrastructure derrière git push »Quand vous tapez git push, Git doit communiquer avec un serveur
distant. Plusieurs protocoles sont disponibles, chacun avec ses
avantages :
| Protocole | Authentification | Performance | Usage typique |
|---|---|---|---|
| SSH | Clé publique/privée | Rapide | Entreprise, développeurs |
| HTTPS (smart) | Token / mot de passe | Rapide | Universel, CI/CD |
| Git protocol | Aucune | Le plus rapide | Lecture seule publique |
| Local | Aucune | Très rapide | Même machine / NFS |
Ce que vous allez apprendre : le fil du module
Section intitulée « Ce que vous allez apprendre : le fil du module »Protocoles Git compare SSH, HTTPS, Git protocol et
local (avantages, sécurité, performance) pour choisir selon votre contexte.
Héberger un serveur Git crée un bare
repository, configure l'accès SSH, git daemon et le smart HTTP.
Plateformes Git compare GitHub, GitLab, Gitea,
Forgejo et Bitbucket pour choisir la bonne forge.
À retenir
Section intitulée « À retenir »- SSH est le protocole recommandé pour le développement quotidien (sécurisé, pas de saisie de mot de passe)
- Un bare repository (
git init --bare) est un dépôt sans working directory, conçu pour être un serveur central - GitHub domine l'open source, GitLab excelle en CI/CD intégrée et self-hosting, Gitea/Forgejo sont les options légères auto-hébergées
- HTTPS avec tokens est le choix standard pour les pipelines CI/CD