Verschil tussen Git en GitHub voor uw VPS

Wat is GitHub?

GitHub is een gehoste dienst die Git-repositories opslaat en er een website omheen bouwt. Git is het versiebeheerprogramma dat op uw eigen computer of uw eigen server draait. GitHub is een product van één bedrijf dat boven op Git is gebouwd en sinds 2018 eigendom is van Microsoft. U kunt dagelijks Git gebruiken zonder ooit GitHub te openen. U kunt GitHub niet gebruiken zonder Git.

Dat onderscheid is van belang zodra u een VPS (virtual private server) beheert. Git legt de geschiedenis van uw configuratiebestanden en deploy-scripts vast. GitHub is de plek waar een kopie van die geschiedenis wordt bewaard wanneer de server dat niet doet, en fungeert bovendien als platform voor het uitvoeren van builds en reviews. Deze handleiding volgt één voorbeeld van een lege map tot een deploy op een server, en definieert elk nieuw begrip op het moment dat u het voor het eerst tegenkomt.

Wat Git zelfstandig doet

Git is een versiebeheersysteem: het legt de status van een map in de loop van de tijd vast, zodat u kunt zien wat er is gewijzigd, wanneer en waarom. Het werd in 2005 geschreven voor werk aan de Linux-kernel. Het is gedistribueerd, wat betekent dat elke kopie van een repository de volledige geschiedenis bevat. Er is in het ontwerp geen centrale server aanwezig. De laptop van een collega is een even volledige kopie als elke server.

Installeer het en stel uw identiteit in. Git weigert een commit vast te leggen zonder naam en e-mailadres, omdat beide in de commit zelf worden geschreven.

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"

Op Ubuntu 24.04 print git --version de waarde git version 2.43.0. Elke release van de afgelopen jaren gedraagt zich voor alles hieronder op dezelfde manier.

Het voorbeeld: een repository voor uw VPS-deploybestanden

Een repository, meestal afgekort tot "repo", is een map die door Git wordt gecontroleerd. Deze wordt een repository zodra u git init uitvoert, wat een verborgen .git-map in de directory aanmaakt. Die map is de repository. Verwijder .git en u houdt een gewone map over zonder enige historie.

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

-b main geeft de eerste branch de naam main. Laat u dit weg, dan toont Git in plaats daarvan een uitgebreide hint over de standaardnaam voor de branch. .gitignore bevat paden die Git nooit mag volgen. Voeg uw bestand met geheimen hier vanaf de eerste dag aan toe; een bestand dat eenmaal is gecommit, blijft in de historie staan, zelfs nadat u het verwijdert. Het correct verwijderen ervan vereist dat elke daaropvolgende commit wordt herschreven.

Commits: de eenheid van geschiedenis

Voeg nu een script toe en leg dit vast.

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 verplaatst een wijziging naar de staging area, de lijst met bestanden die in de volgende commit worden opgenomen. git commit schrijft deze lijst als één item naar de geschiedenis. Een commit bevat een snapshot van elk gevolgd bestand, een bericht, een auteur, een tijdstempel en een verwijzing naar de voorgaande commit. git log --oneline toont één regel per commit, elk beginnend met een korte hash zoals a1b2c3d. Deze hash is de naam van de commit en vrijwel elk Git-commando accepteert deze.

Sla de stap git add over en git commit beantwoordt no changes added to commit (use "git add" and/or "git commit -a"). Er is niets kapot. Git geeft aan dat de staging area leeg is, waardoor er geen snapshot gemaakt kan worden. git status is het commando dat u uitvoert wanneer u het overzicht kwijt bent: het toont de huidige branch, de ge-stage wijzigingen en de bestanden die Git wel ziet maar niet volgt.

Branches: een tweede geschiedenislijn

Een branch is een bewegende aanwijzer naar een commit. main is een branch en is op geen enkele wijze speciaal voor Git. Het aanmaken ervan kost niets, omdat Git een nieuwe aanwijzer schrijft in plaats van uw bestanden te kopiëren.

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

Na git switch main ontbreekt backup.sh in de lijst. Er is niets verwijderd. Het bestand bestaat op de add-backup branch en main heeft het nooit bevat, dus Git heeft het uit uw werkmap verwijderd toen u wisselde. Dit verrast iedereen de eerste keer. git switch add-backup brengt het terug.

Remotes: waar GitHub eindelijk in beeld komt

Alles tot nu toe draaide op één machine zonder enig netwerk. Een remote is een benoemde URL voor een andere kopie van dezelfde repository. GitHub host een van die kopieën voor u. De gebruikelijke naam voor de hoofd-remote is origin.

Maak een lege repository aan via de website van GitHub en maak vervolgens verbinding. Geef hier de voorkeur aan SSH boven HTTPS: een SSH key is een bestand dat u beheert en het verloopt niet zoals een personal access token dat wel doet.

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

Plak de weergegeven publieke sleutel in de pagina voor SSH keys van uw GitHub-account en voer de test daarna opnieuw uit. Een werkende sleutel antwoordt met Hi yourname! You've successfully authenticated, but GitHub does not provide shell access.. GitHub geeft u geen shell, dus die weigering is het teken van succes. git@github.com: Permission denied (publickey). betekent dat uw sleutel nooit is aangeboden of niet werd geaccepteerd; controleer dus of u het .pub-bestand heeft geplakt en niet de private key die ernaast staat.

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

git push verstuurt uw commits naar de remote. -u legt vast dat de lokale main de remote main volgt, zodat later een kale git push volstaat. git clone <url> is het omgekeerde op een nieuwe machine: het kopieert de volledige repository inclusief de geschiedenis en stelt origin voor u in. Een HTTPS-remote werkt ook en verloopt via hetzelfde protocol als elke webpagina, wat helpt op netwerken die uitgaand verkeer op poort 22 blokkeren. Als die zin toelichting behoeft, behandelt waar een HTTP-verzoek feitelijk uit bestaat de werking hiervan.

Pull requests, issues en forks: de onderdelen die bij GitHub horen, niet bij Git

Alles hierboven is Git en werkt met elke server. De drie onderstaande termen zijn functies van GitHub. Andere hosts kopiëren deze functies, maar Git zelf kent ze niet.

Een pull request (PR) is een verzoek om de ene branch samen te voegen met de andere, verpakt in een pagina voor discussie. U pusht add-backup, opent een PR naar main, en de site toont het verschil commit voor commit. Mensen plaatsen opmerkingen bij individuele regels. Geautomatiseerde controles rapporteren of de branch slaagt of faalt. Klik op merge en GitHub voert de samenvoeging uit op zijn eigen kopie en werkt vervolgens main bij. De naam komt voort uit de oorspronkelijke workflow, waarbij u een beheerder vroeg om uw branch in de hunne te pullen.

Een issue is een genummerde thread voor een bug of een taak. Deze bevindt zich in de database van GitHub, niet in uw repository. Dit is belangrijk om te weten voordat u een host kiest: kloon de repo en u heeft elke commit, maar geen enkel issue. Om issues te exporteren, moet u de API aanroepen.

Een fork is uw eigen kopie van de repository van iemand anders, opgeslagen op de server. U heeft schrijfrechten voor deze kopie, u pusht er een branch naar toe en u opent een pull request vanuit uw kopie naar de oorspronkelijke repository. Zo draagt u bij aan een project waarvan de beheerders u niet kennen. Een fork is een kloon die op GitHub leeft en onthoudt waar deze vandaan komt.

Software leest alle drie via dezelfde API die een persoon gebruikt. Een pull request review agent die u op uw eigen server draait controleert op nieuwe PR's, leest de diff en plaatst opmerkingen bij de regels. Conventies zoals een AGENTS.md-bestand in de root van een repository bestaan omdat een repo tegenwoordig zowel door tools als door mensen wordt gelezen.

Wat GitHub daadwerkelijk doet voor een VPS-eigenaar

Begin met opslag buiten de server. Uw deploy-scripts en playbooks horen ergens thuis waar ze niet op de server staan die ze configureren. Bouw de VPS opnieuw op vanaf een schone image, clone, en voer uit. Houd die repository privé en geef de server een deploy key: een SSH-sleutel die is geregistreerd voor één repository in plaats van voor uw gehele account, ingesteld op alleen-lezen. Een gelekte alleen-lezen deploy key stelt één repo bloot. Een gelekte accountsleutel stelt alles bloot waarnaar u kunt pushen.

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

--ff-only weigert een merge commit aan te maken. Op een server die alleen wijzigingen consumeert, is een merge altijd een ongeluk. Deze vlag verandert een verwarrende geschiedenis daarom in de duidelijke foutmelding fatal: Not possible to fast-forward, aborting. Er is iets veranderd op de server dat niet had mogen veranderen. Zoek dit uit voordat u opnieuw een pull uitvoert.

Clone als root en voer Git vervolgens uit als een andere gebruiker, dan krijgt u fatal: detected dubious ownership in repository at '/srv/vps-deploy'. Git weigert een repository te lezen die eigendom is van een andere gebruiker, omdat een vijandige .git/config Git opdrachten kan laten uitvoeren. Herstel het eigenaarschap met chown in plaats van een safe.directory uitzondering toe te voegen, aangezien de uitzondering de controle onderdrukt zonder de oorzaak weg te nemen.

GitHub Actions: build- en deploy-pipelines

Actions is het CI/CD-systeem (continuous integration en continuous delivery) van GitHub. Commit een YAML-bestand in .github/workflows/ en GitHub voert dit uit zodra de door u opgegeven gebeurtenis plaatsvindt.

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

Het bestand is een workflow. Een job draait op één machine. Een step is één commando of een gepubliceerde action. uses: haalt een action uit een andere repository op en @v7 zet de major-versie vast (v7 is de huidige versie voor actions/checkout per augustus 2026). Zet versies altijd vast, omdat een niet-vastgezette action betekent dat code die u niet heeft gecontroleerd, wordt uitgevoerd met toegang tot uw secrets.

runs-on: ubuntu-latest vraagt GitHub om een nieuwe virtuele machine, die wordt verwijderd zodra de job is voltooid. Standaard runners zijn gratis voor publieke repositories en het gratis abonnement bevat 2.000 minuten per maand voor private repositories per augustus 2026. Controleer de actuele prijzenpagina voordat u een budget op basis van dat cijfer opstelt.

Secrets worden opgeslagen in de repository-instellingen en uitgelezen als ${{ secrets.DEPLOY_KEY }}. Een workflow die wordt geactiveerd door een pull request vanuit een fork, krijgt een read-only token en heeft geen toegang tot deze secrets, omdat een vreemde anders een PR zou kunnen openen met als enige doel deze te tonen.

De Actions runner uitvoeren op uw eigen VPS

runs-on: self-hosted stuurt de taak in plaats daarvan naar een machine die u zelf beheert. De instellingenpagina voor runners van de repository verstrekt een downloadregel, het webadres van de repository en een registratietoken dat één uur geldig is. Voer die laatste twee in bij REPO_URL en RUNNER_TOKEN; daarna bestaat de installatie uit drie commando's.

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

svc.sh status hoort de service als actief te rapporteren en recente logregels te tonen. De runner opent een uitgaande HTTPS-verbinding naar GitHub om werk op te vragen, dus u hoeft hiervoor geen inkomende poorten te openen. svc.sh install schrijft de systemd-unit, en dit is de stap die mensen vaak overslaan: zonder deze stap stopt de runner zodra uw SSH-sessie wordt beëindigd en blijft elke volgende taak zonder uitleg in de wachtrij staan. de volledige installatie van een self-hosted runner op een VPS doorloopt de hardening en het opschonen die een runner die langdurig actief is nodig heeft.

Het voordeel is dat een deploy geen inkomende SSH-key meer vereist die vanaf het internet bereikbaar is, omdat de taak al op de machine zelf draait. De build-cache blijft bovendien behouden tussen runs en er worden geen minuten in rekening gebracht.

Eén waarschuwing is niet optioneel. De eigen documentatie van GitHub raadt self-hosted runners alleen aan voor private repositories, omdat forks van een publieke repository gevaarlijke code op uw runner kunnen uitvoeren door een pull request te openen. De runner voert uit wat het workflow-bestand op die branch voorschrijft. Bij een private repository waar u controleert wie kan pushen, is het risico klein. Behandel bij een publieke repository elke self-hosted runner als een machine waarop vreemden code kunnen uitvoeren.

Hebt u GitHub überhaupt nodig?

Nee. Git is de standaard en GitHub is een gemaksproduct. Forgejo en Gitea zijn zelf-gehoste forges; een forge is een Git-host met bijbehorende issues en pull requests. Beide worden geleverd als een enkel Go-binary, beide draaien op een kleine VPS, en Forgejo is een fork van Gitea uit 2022 die nu Codeberg aandrijft. Het verplaatsen van een repository is één commando, omdat het wire-protocol identiek is.

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

Elke commit verhuist mee, omdat elke clone al de volledige geschiedenis bevat. Wat niet meeverhuist, is de laag die GitHub er bovenop heeft gebouwd: de issues en de pull request-threads. CI wordt evenmin overgezet. Forgejo heeft zijn eigen Actions-implementatie die vergelijkbare YAML leest vanuit .forgejo/workflows/, en de documentatie is direct over de beperkingen; er staat dat GitHub Actions en Forgejo Actions niet hetzelfde zijn en dat zaken mogelijk niet direct werken. Het heeft ook een eigen runner nodig. Plan die stap als een port, niet als een kopie.

De eerlijke reden waarom de meeste projecten blijven, is de aanwezigheid van contributors. Publieke code moet staan waar mensen al een account hebben. Uw private deploy-scripts hoeven dat niet. Dat zijn twee afzonderlijke beslissingen en het staat u vrij om deze verschillend te beantwoorden.

Wat gaat er als eerste mis en wat de foutmelding betekent

Een push wordt geweigerd. U ziet het volgende:

 ! [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.

Er is sinds uw laatste pull iets gepusht, vaak een wijziging die u in de web-editor heeft gemaakt. Voer git pull --rebase uit om uw commits bovenop die van hen opnieuw toe te passen en push daarna opnieuw. Vermijd git push --force op een gedeelde branch, omdat dit de andere commits van die branch op de server verwijdert.

fatal: refusing to merge unrelated histories. U heeft lokaal git init uitgevoerd en GitHub de repository laten aanmaken met een README. De twee geschiedenissen delen geen enkele commit, dus Git zal niet gokken. De schone oplossing is om de kopie van GitHub naar een nieuwe map te klonen en uw bestanden daarin te verplaatsen.

error: src refspec main does not match any. De branch die u heeft opgegeven bestaat hier niet. Meestal bevat de repository tot nu toe nul commits, of heet uw branch master. git branch --show-current lost dit op.

Een geheim is in een commit terechtgekomen. Roteer de inloggegevens direct. Behandel deze vanaf het moment van pushen als openbaar, omdat forks, mirrors en gecachte weergaven kopieën bevatten die u op geen enkele manier kunt verwijderen.

FAQ

Is GitHub hetzelfde als Git?

Nee. Git is een versiebeheerprogramma dat u op een machine installeert; het werkt zonder netwerk en zonder account. GitHub is een commerciële hosted dienst die Git-repositories opslaat en daar een webinterface, issues, pull requests en CI aan toevoegt. Git werd uitgebracht in 2005 en GitHub werd in 2008 op basis daarvan gelanceerd. U kunt Git voor altijd gebruiken zonder GitHub. Elke functie van GitHub is afhankelijk van Git als onderliggende techniek.

Heb ik een GitHub-account nodig om Git op mijn VPS te gebruiken?

Nee. git init, git commit en git log werken op een server zonder enige geconfigureerde remote, wat al voldoende is om wijzigingen in /etc-bestanden bij te houden of scripts te deployen. Een account wordt nuttig wanneer u een kopie van de historie wilt die de server overleeft, of een tweede machine die de repository kan clonen. Self-hosted forges zoals Forgejo en Gitea voorzien in dezelfde behoefte op hardware die u zelf bezit, en een eenvoudige SSH-remote die naar een bare repository op een andere machine wijst, werkt zelfs volledig zonder forge-software.

Wat is een pull request?

Een pull request is een verzoek om de ene branch in de andere te mergen, voorzien van een discussiepagina. U pusht een branch, opent de PR tegen main, en de host toont de wijziging commit voor commit zodat reviewers commentaar kunnen geven op individuele regels en geautomatiseerde checks kunnen rapporteren of ze slagen of falen. Het is een functie van GitHub en niet van Git zelf, waardoor Git geen ingebouwd commando hiervoor heeft. Andere hosts implementeren hetzelfde concept en noemen het soms een merge request.

Moet ik een GitHub Actions runner op mijn eigen VPS draaien?

Voor een private repository vaak wel. De taak draait op hardware waar u al voor betaalt, er worden geen minuten in rekening gebracht, de build-cache blijft warm en een deploy vereist geen inkomende SSH-key die aan het internet wordt blootgesteld, omdat de runner uitgaand verbinding maakt met GitHub om werk op te halen. Voor een publieke repository raadt GitHub dit af: iedereen kan uw repo forken en een pull request openen waarvan de workflow code op uw machine uitvoert.

Kan ik mijn repositories later van GitHub verplaatsen?

De code wel, eenvoudig. Elke clone bevat de volledige historie, dus git remote set-url origin <new url> gevolgd door een push verplaatst alles wat een commit bevat. Wat achterblijft is de laag die eigendom is van GitHub: issues, discussies in pull requests en de Actions-historie staan in hun database, niet in uw .git-map. Migratietools kunnen issues via de API kopiëren, en workflow-bestanden moeten meestal worden aangepast voor de CI van de nieuwe host. Dit in gedachten houden is het argument om echte documentatie in de repository zelf te plaatsen in plaats van in issue-threads.