Pushen — wat is het, hoe werkt git push en wanneer is het nodig

Wat is push in Git

Git push is een opdracht die commits van de lokale repository naar de externe repository overdraagt. In tegenstelling tot commit, dat wijzigingen alleen op de lokale machine van de ontwikkelaar opslaat, publiceert push deze wijzigingen voor het hele team. Push is een verplichte stap voordat je een Pull Request aanmaakt en implementeert.

De architectuur van Git gaat ervan uit dat elke ontwikkelaar in zijn eigen lokale repository werkt. Commits worden lokaal gemaakt en stapelen zich op totdat de ontwikkelaar besluit ze te pushen. Dit geeft vrijheid: je kunt veel lokale commits maken, experimenteren en de geschiedenis herschrijven zonder collega's te beïnvloeden.

# Push naar origin remote, main-tak
git push origin main

# Huidige tak naar remote pushen met upstream
git push -u origin feature/new-dashboard

# Alle takken met overeenkomende namen pushen
git push --all origin

# Force push met lease (veilige force push)
git push --force-with-lease

Na de push werkt de externe repository refs (verwijzingen naar takken) bij zodat ze naar nieuwe commits verwijzen. Andere ontwikkelaars kunnen deze wijzigingen ophalen via git pull of git fetch. Het is precies deze uitwisseling van commits die de basis vormt van collaboratieve ontwikkeling.

Hoe werkt git push

De opdracht git push vergelijkt lokale en externe takken en stuurt alleen de ontbrekende commits. Git stuurt niet alle bestanden opnieuw — het stuurt alleen de delta, waardoor pushen snel is, zelfs bij grote repositories. Git Protocol gebruikt smart transfer, dat de hoeveelheid verzonden gegevens minimaliseert.

Als de externe tak commits bevat die niet lokaal bestaan, wordt de push geweigerd. Dit is een beschermingsmechanisme dat verlies van wijzigingen voorkomt. In zo'n situatie moet de ontwikkelaar eerst git pull uitvoeren, de wijzigingen samenvoegen en pas daarna opnieuw pushen. Het alternatief is force push, dat de externe tak overschrijft, maar dit moet voorzichtig worden gebruikt.

Het begrijpen van externe repositories is de sleutel tot correct pushen. Meestal wordt origin gebruikt — de standaardnaam van de externe repository. De opdracht git remote -v toont de lijst van externe repositories en hun URL's. Je kunt meerdere remote's toevoegen (bijvoorbeeld origin voor de hoofdrepository en upstream voor een fork).

Wanneer moet je wijzigingen pushen

De hoofdregel: pushen moet na elke logisch afgeronde werkfase. Als een ontwikkelaar een taak of een deel ervan heeft voltooid — is het tijd om te pushen. Het pushen van onvoltooid werk dat de build breekt, wordt echter niet aanbevolen. Een werkende build is de minimale vereiste om naar elke tak te pushen.

In teamontwikkeling wordt het volgende ritme aangehouden: 's ochtends — git pull om wijzigingen van collega's op te halen, overdag — een paar commits en een of twee pushes, 's avonds — de uiteindelijke push van alle voltooide taken. Hoe vaker een ontwikkelaar pusht, hoe kleiner het risico op conflicten bij het samenvoegen van takken en hoe transparanter de voortgang.

• Na voltooiing van een taak — commit en push de uiteindelijke oplossing naar een feature-tak
• Voor vertrek — push onvoltooid werk naar een feature-tak (niet naar main!)
• Voor het maken van een PR — zorg dat alle commits zijn gepusht en beschikbaar zijn voor review
• Na rebase — push met --force-with-lease naar je eigen feature-tak

Regels voor veilig pushen

Veilig pushen is een set regels die gegevensverlies en conflicten in het team voorkomen. De eerste en belangrijkste regel: push nooit direct naar de main- of master-tak, tenzij er directe implementatie is geconfigureerd in het project. In moderne teams wordt de bescherming van de main-tak geconfigureerd op het niveau van GitHub branch protection.

Tweede regel: synchroniseer voor het pushen met de externe tak. Voer git pull --rebase uit om een merge-commit bij het samenvoegen te voorkomen. Dit vereenvoudigt de geschiedenis en maakt deze lineair. Als de push wordt geweigerd — gebruik dan geen kale force push, maar onderzoek eerst welke commits in de externe tak zijn verschenen.

Derde regel: configureer pre-push hooks die automatisch tests en linters uitvoeren voor het verzenden. Als tests falen — wordt de push geblokkeerd. Dergelijke hooks worden geconfigureerd via Husky of Git hooks (pre-push bestand in .git/hooks).

Vierde regel: push geen grote binaire bestanden. Git is niet ontworpen voor het opslaan van binaire artefacten — ze blazen de repository op en vertragen bewerkingen. Voor grote bestanden wordt Git LFS (Large File Storage) gebruikt. Als een binair bestand al is gepusht en in de geschiedenis is terechtgekomen, moet het worden verwijderd via git filter-branch.

Wat te doen als de push mislukt

De meest voorkomende oorzaak van een mislukte push — de externe tak bevat commits die niet lokaal bestaan. Dit gebeurt wanneer een andere ontwikkelaar zijn wijzigingen naar dezelfde tak heeft gepusht. Oplossing: voer git pull uit, los eventuele conflicten op en herhaal de push.

# Push geweigerd — eerst fetch en rebase
git fetch origin
git rebase origin/main
# Conflicten oplossen, dan:
git push --force-with-lease

# Of gewoon externe wijzigingen samenvoegen
git pull origin main
git push

Tweede oorzaak — gebrek aan schrijfrechten voor de tak. Als de main-tak wordt beschermd door een branch protection-regel, zijn directe pushes verboden. Oplossing: push naar een feature-tak en maak een Pull Request. De beveiligingsinstellingen worden meestal beheerd via GitHub settings of GitLab protected branches.

Derde oorzaak — authenticatieproblemen. Verouderde inloggegevens, overstap naar SSH of wijziging van personal access token. Oplossing: controleer de remote URL (git remote -v) en werk de inloggegevens bij. Sinds 2021 heeft GitHub authenticatie met wachtwoord voor HTTPS afgeschaft — er wordt een persoonlijke token of SSH-sleutel gebruikt.