Git ou GitHub : quelle différence pour votre VPS ?

Qu’est-ce que GitHub ?

GitHub est un service hébergé qui stocke des dépôts Git et construit un site web autour d’eux. Git est le logiciel de contrôle de version qui s’exécute sur votre propre ordinateur ou votre propre serveur. GitHub est le produit d’une entreprise basé sur Git, détenu par Microsoft depuis 2018. Vous pouvez utiliser Git tous les jours sans jamais ouvrir GitHub. Vous ne pouvez pas utiliser GitHub sans Git.

Cette distinction devient importante dès que vous possédez un VPS (serveur privé virtuel). Git enregistre l’historique de vos fichiers de configuration et de vos scripts de déploiement. GitHub conserve une copie de cet historique lorsque le serveur ne l’a pas, et fournit également un environnement pour exécuter des builds et effectuer des revues. Ce guide suit un exemple, depuis un dossier vide jusqu’au déploiement sur un serveur, et définit chaque nouveau terme lors de sa première apparition.

Ce que Git fait de lui-même

Git est un système de gestion de versions. Il enregistre l’état d’un répertoire au fil du temps, afin que vous puissiez voir ce qui a changé, quand et pourquoi. Il a été écrit en 2005 pour le développement du noyau Linux. Il est distribué : chaque copie d’un dépôt contient tout son historique. Sa conception ne repose pas sur un serveur central. L’ordinateur portable d’un collègue contient une copie aussi complète que celle d’un serveur.

Installez-le et définissez votre identité. Git refuse d’enregistrer un commit sans nom ni adresse e-mail, car ces deux informations sont écrites dans le commit lui-même.

sudo apt update && sudo apt install -y git
git --version
git config --global user.name "Your Name"
git config --global user.email "you@example.com"

Sur Ubuntu 24.04, git --version affiche git version 2.43.0. Toute version publiée ces dernières années se comporte de la même manière pour tout ce qui suit.

Exemple : un dépôt pour les fichiers de déploiement de votre VPS

Un dépôt, généralement abrégé en « repo », est un répertoire surveillé par Git. Il le devient lorsque vous exécutez git init, qui crée un dossier masqué .git à l’intérieur. Ce dossier est le dépôt. Supprimez .git et il ne reste qu’un répertoire ordinaire, sans historique.

mkdir vps-deploy && cd vps-deploy
git init -b main
printf '.env\n*.key\n' > .gitignore

-b main nomme la première branche main. Si vous omettez cette option, Git affiche un long message indiquant le nom de la branche par défaut. .gitignore répertorie les chemins que Git ne doit jamais suivre. Ajoutez-y votre fichier de secrets dès le premier jour, car un fichier qui a été validé une fois reste dans l’historique même après sa suppression. Pour le supprimer correctement, il faut réécrire chaque commit créé ensuite.

Commits : l’unité de l’historique

Ajoutez maintenant un script et enregistrez-le.

printf '#!/bin/sh\nsudo systemctl restart caddy\n' > restart.sh
git add restart.sh .gitignore
git commit -m "Add restart script and gitignore"
git log --oneline

git add place une modification dans la zone de staging, c’est-à-dire la liste de ce qui sera inclus dans le prochain commit. git commit enregistre cette liste dans l’historique sous la forme d’une entrée. Un commit contient un instantané de chaque fichier suivi, un message, un auteur, un horodatage et un pointeur vers le commit précédent. git log --oneline affiche une ligne par commit, chacune commençant par un hash court tel que a1b2c3d. Ce hash est le nom du commit et presque toutes les commandes Git l’acceptent.

Ignorez l’étape git add et git commit répond no changes added to commit (use "git add" and/or "git commit -a"). Rien n’est cassé. Git vous indique que la zone de staging est vide : il n’y a donc rien à inclure dans l’instantané. git status est la commande à exécuter chaque fois que vous ne savez plus où vous en êtes : elle indique la branche courante, les modifications placées dans la zone de staging et les fichiers que Git peut voir mais qu’il ne suit pas.

Branches : une deuxième ligne dans l’historique

Une branche est un pointeur mobile vers un commit. main est une branche, et elle n’a rien de spécial dans Git. Sa création ne coûte rien, car Git écrit un nouveau pointeur au lieu de copier vos fichiers.

git switch -c add-backup
printf '#!/bin/sh\nrestic backup /srv\n' > backup.sh
git add backup.sh
git commit -m "Add nightly backup"
git switch main
ls

Après git switch main, backup.sh n’apparaît plus dans la liste. Rien n’a été supprimé. Le fichier existe sur la branche add-backup, et main ne l’a jamais contenu. Git l’a donc retiré de votre répertoire de travail lorsque vous avez changé de branche. Cela surprend tout le monde une fois. git switch add-backup le restaure.

Remotes : où GitHub apparaît enfin

Jusqu’ici, tout s’est déroulé sur une seule machine, sans aucun réseau. Un remote est une URL nommée qui désigne une autre copie du même dépôt. GitHub héberge l’une de ces copies pour vous. Le nom conventionnel du remote principal est origin.

Créez un dépôt vide depuis le site web GitHub, puis connectez-le. Préférez SSH à HTTPS ici : une clé SSH est un fichier que vous contrôlez et elle n’expire pas comme un personal access token.

ssh-keygen -t ed25519 -C "vps-deploy"
cat ~/.ssh/id_ed25519.pub
ssh -T git@github.com

Collez la clé publique affichée dans la page des clés SSH de votre compte GitHub, puis relancez le test. Une clé fonctionnelle répond Hi yourname! You've successfully authenticated, but GitHub does not provide shell access.. GitHub ne vous fournit aucun shell : ce refus indique donc que le test a réussi. git@github.com: Permission denied (publickey). signifie que votre clé n’a jamais été proposée ou qu’elle n’a pas été acceptée. Vérifiez que vous avez collé le fichier .pub et non la clé privée située à côté.

git remote add origin git@github.com:yourname/vps-deploy.git
git push -u origin main

git push envoie vos commits vers le remote. -u enregistre que le main local suit le main distant. Un simple git push suffit ensuite. git clone <url> effectue l’opération inverse sur une nouvelle machine : il copie tout le dépôt avec son historique et configure origin pour vous. Un remote HTTPS fonctionne également. Il utilise le même protocole qu’une page web, ce qui est utile sur les réseaux qui bloquent le port sortant 22. Si cette phrase nécessite quelques explications, la composition réelle d’une requête HTTP décrit les mécanismes.

Pull requests, issues et forks : les éléments propres à GitHub, pas à Git

Tout ce qui précède concerne Git et fonctionne avec n’importe quel serveur. Les trois termes ci-dessous désignent des fonctionnalités de GitHub. Les autres plateformes les reproduisent, mais Git lui-même n’en sait rien.

Une pull request (PR) est une demande de fusion d’une branche dans une autre, présentée sur une page qui permet d’en discuter. Vous poussez add-backup, ouvrez une PR vers main, puis le site affiche les différences commit par commit. Les utilisateurs commentent des lignes précises. Les vérifications automatisées indiquent si elles réussissent ou échouent pour la branche. Cliquez sur Merge : GitHub effectue la fusion sur sa propre copie, puis met à jour main. Ce nom vient du workflow d’origine : vous demandiez à un mainteneur de pull votre branche dans la sienne.

Une issue est un fil numéroté consacré à un bug ou à une tâche. Elle est stockée dans la base de données de GitHub, pas dans votre repository. Il est important de le savoir avant de choisir une plateforme : vous avez tous les commits après avoir cloné le repository, mais aucune issue. Pour récupérer les issues, il faut appeler l’API.

Un fork est une copie côté serveur du repository d’une autre personne. Vous disposez des droits d’écriture sur cette copie, vous y poussez une branche, puis vous ouvrez une pull request depuis votre copie vers le repository d’origine. C’est ainsi que vous contribuez à un projet dont les mainteneurs n’ont jamais entendu parler de vous. Un fork est un clone hébergé sur GitHub qui conserve l’origine dont il provient.

Les logiciels accèdent aux trois éléments via la même API que celle utilisée par les utilisateurs. Un agent de revue des pull requests exécuté sur votre propre serveur surveille les nouvelles PR, lit le diff et publie des commentaires sur les lignes concernées. Des conventions comme un fichier AGENTS.md à la racine d’un repository existent parce que les outils lisent désormais un repository au même titre que les utilisateurs.

Ce que GitHub fait réellement pour le propriétaire d’un VPS

Commencez par un stockage hors serveur. Vos scripts de déploiement et vos playbooks doivent être stockés ailleurs que sur le serveur qu’ils configurent. Vous pouvez reconstruire le VPS à partir d’une image vierge, cloner le dépôt, puis exécuter les scripts. Gardez ce dépôt privé et attribuez au serveur une deploy key : une clé SSH associée à un seul dépôt, et non à l’ensemble de votre compte, configurée en lecture seule. Une deploy key en lecture seule divulguée ne donne accès qu’à un dépôt. Une clé de compte divulguée donne accès à tout ce que vous pouvez pousser.

sudo git clone git@github.com:yourname/vps-deploy.git /srv/vps-deploy
cd /srv/vps-deploy
git pull --ff-only

--ff-only refuse de créer un commit de fusion. Sur un serveur qui ne fait que récupérer les changements, une fusion est toujours accidentelle. Ce flag transforme donc un historique déroutant en l’erreur explicite fatal: Not possible to fast-forward, aborting.. Quelque chose a été modifié sur le serveur alors que cela n’aurait pas dû arriver. Identifiez la cause avant de lancer à nouveau un pull.

Clonez le dépôt en tant que root, puis exécutez Git avec un autre utilisateur, et vous obtenez fatal: detected dubious ownership in repository at '/srv/vps-deploy'. Git refuse de lire un dépôt appartenant à un autre utilisateur, car un .git/config malveillant peut faire exécuter des commandes à Git. Corrigez le propriétaire avec chown au lieu d’ajouter une exception safe.directory, car cette exception désactive le contrôle sans supprimer la cause du problème.

GitHub Actions : pipelines de build et de déploiement

Actions est le système CI/CD de GitHub (intégration continue et livraison continue). Ajoutez un fichier YAML sous .github/workflows/, et GitHub l’exécute lorsque l’événement indiqué se produit.

name: check
on:
  push:
    branches: [main]
jobs:
  shellcheck:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - run: sudo apt-get update && sudo apt-get install -y shellcheck
      - run: shellcheck *.sh

Le fichier est un workflow. Un job s’exécute sur une machine. Une step correspond à une commande ou à une action publiée. uses: importe une action depuis un autre dépôt, et @v7 verrouille sa version majeure (v7 est la version actuelle de actions/checkout en août 2026). Verrouillez toujours une version, car une action sans version verrouillée exécute du code que vous n’avez pas lu et qui peut accéder à vos secrets.

runs-on: ubuntu-latest demande à GitHub une machine virtuelle temporaire, supprimée à la fin du job. Les runners standard sont gratuits pour les dépôts publics, et le forfait gratuit inclut 2,000 minutes par mois pour les dépôts privés en août 2026. Consultez la page tarifaire actuelle avant d’établir un budget sur cette base.

Les secrets sont stockés dans les paramètres du dépôt et lus avec ${{ secrets.DEPLOY_KEY }}. Un workflow déclenché par une pull request provenant d’un fork reçoit un token en lecture seule et n’a pas accès à ces secrets. Sinon, un utilisateur externe pourrait ouvrir une PR dont le seul objectif serait de les afficher.

Exécuter le runner Actions sur votre propre VPS

runs-on: self-hosted envoie le job vers une machine qui vous appartient. La page des paramètres du runner du dépôt fournit une ligne de téléchargement, l’adresse web du dépôt et un registration token valide pendant une heure. Placez les deux derniers éléments dans REPO_URL et RUNNER_TOKEN, puis la configuration se résume à trois commandes.

./config.sh --url "$REPO_URL" --token "$RUNNER_TOKEN"
sudo ./svc.sh install
sudo ./svc.sh start
./svc.sh status

svc.sh status doit indiquer que le service est actif et afficher les dernières lignes du journal. Le runner ouvre une connexion HTTPS sortante vers GitHub et demande du travail. Vous n’avez donc aucun port entrant à ouvrir pour lui. svc.sh install écrit l’unité systemd. C’est l’étape que l’on omet souvent : sans elle, le runner s’arrête avec votre session SSH et chaque job suivant reste en file d’attente sans explication. la procédure complète de configuration d’un runner auto-hébergé sur un VPS explique le durcissement et le nettoyage nécessaires à un runner utilisé sur le long terme.

L’avantage est qu’un déploiement n’a plus besoin d’une clé SSH entrante accessible depuis Internet, puisque le job s’exécute déjà sur la machine. Le build cache reste également disponible entre les exécutions, et aucun compteur de minutes ne décompte la durée d’utilisation.

Un avertissement est indispensable. La documentation de GitHub recommande d’utiliser les self-hosted runners uniquement pour les dépôts privés, car les forks d’un dépôt public peuvent exécuter du code dangereux sur votre runner en ouvrant une pull request. Le runner exécute ce qu’indique le fichier de workflow présent sur cette branche. Pour un dépôt privé dont vous contrôlez les personnes autorisées à push, le risque est faible. Pour un dépôt public, considérez tout self-hosted runner comme une machine sur laquelle des personnes inconnues peuvent exécuter du code.

GitHub est-il vraiment nécessaire ?

Non. Git est le standard, et GitHub est un service pratique. Forgejo et Gitea sont des forges auto-hébergées. Une forge est un hébergeur Git auquel sont rattachés des issues et des pull requests. Les deux sont distribués sous la forme d’un binaire Go unique et fonctionnent sur un petit VPS. Forgejo est un fork de Gitea datant de 2022 qui alimente désormais Codeberg. La migration d’un dépôt se fait avec une seule commande, car le protocole réseau est identique.

git remote -v
git remote set-url origin git@git.example.com:you/vps-deploy.git
git push origin main

Chaque commit est transféré, car chaque clone contient déjà l’historique complet. En revanche, la couche ajoutée par GitHub ne suit pas : les issues et les discussions des pull requests. La CI n’est pas transférée non plus. Forgejo possède sa propre implémentation d’Actions, qui lit un fichier YAML similaire depuis .forgejo/workflows/. Sa documentation indique clairement les limites : GitHub Actions et Forgejo Actions ne sont pas identiques et certains éléments peuvent ne pas fonctionner immédiatement. Forgejo a également besoin de son propre runner. Planifiez cette étape comme une migration, pas comme une copie.

La raison principale pour laquelle la plupart des projets restent sur GitHub concerne les contributeurs. Le code public doit être hébergé là où les utilisateurs ont déjà un compte. Vos scripts de déploiement privés n’y sont pas obligés. Ce sont deux décisions distinctes, et vous pouvez y répondre différemment.

Ce qui casse en premier et ce que signifie l’erreur

Le push est refusé. Vous voyez ceci :

 ! [rejected]        main -> main (fetch first)
error: failed to push some refs to 'github.com:yourname/vps-deploy.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally.

Un push a été effectué depuis votre dernier pull, souvent après une modification réalisée dans l’éditeur web. Exécutez git pull --rebase pour rejouer vos commits au-dessus des leurs, puis effectuez à nouveau le push. Évitez git push --force sur une branche partagée, car cette commande supprime les autres commits de cette branche sur le serveur.

fatal: refusing to merge unrelated histories. Vous avez exécuté git init en local et laissé GitHub créer le repository avec un README. Les deux historiques ne partagent aucun commit, et Git ne peut donc pas déterminer automatiquement quoi faire. La solution propre consiste à cloner la copie GitHub dans un nouveau dossier, puis à y déplacer vos fichiers.

error: src refspec main does not match any. La branche indiquée n’existe pas ici. En général, le repository ne contient encore aucun commit ou votre branche s’appelle master. git branch --show-current permet de vérifier la situation.

Un secret a été inclus dans un commit. Faites immédiatement tourner l’identifiant. Considérez-le comme public dès qu’il a été poussé, car les forks, les miroirs et les vues mises en cache en conservent des copies que vous ne pouvez pas supprimer.

FAQ

GitHub est-il la même chose que Git ?

Non. Git est un logiciel de gestion de versions que vous installez sur une machine. Il fonctionne sans réseau et sans compte. GitHub est un service commercial hébergé qui stocke des dépôts Git et leur ajoute une interface web, des issues, des pull requests et de la CI. Git est sorti en 2005 et GitHub a été lancé en 2008 sur cette base. Vous pouvez utiliser Git indéfiniment sans GitHub. Toutes les fonctionnalités de GitHub reposent sur Git.

Ai-je besoin d’un compte GitHub pour utiliser Git sur mon VPS ?

Non. git init, git commit et git log fonctionnent sur un serveur sans remote configuré, ce qui suffit déjà pour suivre les modifications de fichiers /etc ou de scripts de déploiement. Un compte devient utile lorsque vous voulez conserver une copie de l’historique en dehors du serveur ou cloner le dépôt depuis une seconde machine. Les forges auto-hébergées comme Forgejo et Gitea répondent au même besoin sur du matériel que vous possédez. Un remote SSH classique pointant vers un dépôt bare sur une autre machine fonctionne également sans aucun logiciel de forge.

Qu’est-ce qu’une pull request ?

Une pull request est une demande de fusion d’une branche dans une autre, avec une page de discussion associée. Vous poussez une branche, ouvrez la PR vers main, puis l’hébergeur affiche les modifications commit par commit. Les reviewers peuvent commenter des lignes précises et les vérifications automatisées peuvent indiquer leur réussite ou leur échec. Il s’agit d’une fonctionnalité de GitHub, et non de Git. Git ne possède donc aucune commande pour cela. D’autres hébergeurs proposent le même mécanisme, parfois sous le nom de merge request.

Dois-je exécuter un runner GitHub Actions sur mon propre VPS ?

Pour un dépôt privé, c’est souvent une bonne solution. Le job s’exécute sur du matériel que vous payez déjà, les minutes ne sont pas décomptées, le cache de build reste disponible et un déploiement n’a plus besoin d’exposer une clé SSH entrante sur Internet. Le runner se connecte en sortie à GitHub et demande du travail. Pour un dépôt public, GitHub le déconseille : n’importe qui peut forker votre dépôt et ouvrir une pull request dont le workflow exécutera du code sur votre machine.

Puis-je migrer mes dépôts hors de GitHub plus tard ?

Le code, oui, facilement. Chaque clone contient l’historique complet. Ainsi, git remote set-url origin <new url> suivi d’un push déplace tout ce qu’un commit contient. En revanche, la couche gérée par GitHub reste sur la plateforme : les issues, les discussions des pull requests et l’historique d’Actions sont stockés dans sa base de données, pas dans votre dossier .git. Des outils de migration peuvent copier les issues via l’API. Les fichiers de workflow doivent généralement être adaptés à la CI du nouvel hébergeur. Il faut en tenir compte et placer la documentation importante dans le dépôt plutôt que dans des discussions d’issues.