Git push force: hoe het werkt en hoe je het veilig gebruikt

Waarschijnlijk heb je dit als developer wel eens meegemaakt: je beseft net dat er een probleem in je laatste commit zat. Om die fout ongedaan te maken, voer je wat commando’s uit en herschrijf je je lokale geschiedenis. Wanneer je git push --force draait om alles op te schonen, laten je teamgenoten weten dat er commits missen of dat je pipeline kapotte builds heeft.

In dit artikel leg ik uit wat git push --force precies doet, wanneer je het gebruikt en hoe je fouten voorkomt. Als je net begint met Git, raad ik je aan om onze Introductie tot Git-cursus te volgen om versiebeheer te leren. Ook vind ik de Git Cheat Sheet, die je kunt downloaden, een handige referentie omdat die de meest voorkomende Git-termen en -commando’s bevat.

Wanneer je denkt dat je git push --force nodig hebt

Stel, je bent je lokale commitgeschiedenis aan het opruimen voordat je je werk pusht. Om je commitgeschiedenis netjes te maken vóór het mergen, draai je git rebase -i main. Alles ziet er lokaal perfect uit, dus je probeert je remote branch bij te werken met een simpele git push. Maar in plaats van het gebruikelijke succesbericht toont Git een foutmelding.

Het kan ook gebeuren dat je per ongeluk gevoelige gegevens commit—bijvoorbeeld een API-sleutel of wachtwoord—en die naar de remote pusht. Nadat je lokaal de geschiedenis hebt herschreven om de problematische commit te verwijderen, merk je dat een normale push de remote repository niet bijwerkt en de gevoelige data blijft staan. In plaats daarvan krijg je een foutmelding.

! [rejected]        main -> main (non-fast-forward)
error: failed to push some refs to 'origin'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.,
hint: 'git pull ...') before pushing again.Mogelijk gemaakt door

Deze “non-fast-forward”-fout is de veiligheid van Git: een waarschuwing dat er iets in je geschiedenis niet overeenkomt met wat er op de server staat. Het is dan verleidelijk om git push --force te draaien om de fout te omzeilen.

Dat kan prima werken als jij de enige bent die aan de branch werkt. In gedeelde projecten leidt het echter al snel tot verwarring of het verwijderen van andermans werk.

Wat git push --force echt doet

Meestal laat Git je je wijzigingen alleen pushen als je lokale branch alles bevat wat al op de remote staat, plus je nieuwe commits. Soms herschrijf je echter je commitgeschiedenis via git rebase, squashen, of het verwijderen van gevoelige data. Dan wijkt je lokale branch af van de remote branch. Wanneer je daarna een nieuwe commit probeert te pushen, toont Git de foutmelding die de remote branch beschermt tegen verlies van werk.

Met git push --force vertel je Git de veiligheidscheck over te slaan en de remote branch te overschrijven met wat er in je lokale branch staat. 

Zo ziet dat eruit:

git push --force origin mainMogelijk gemaakt door

Dit werkt de main-branch van de remote bij zodat die overeenkomt met jouw lokale main en verwijdert alle commits die niet in je lokale branch staan. 

Stel je je Git-branch voor als een hoofdstuk in een gedeeld boek dat je team samen schrijft. Een standaard push is als nieuwe alinea’s aan het einde van het hoofdstuk toevoegen. Maar git push --force is krachtiger: het scheurt het huidige hoofdstuk eruit en vervangt het volledig door jouw versie. 

Het risico van git push --force is dat collega’s werk kunnen verliezen als ze hun wijzigingen hebben gebaseerd op commits die jij net hebt weggevaagd. In de volgende sectie bekijken we welke voorzorgsmaatregelen je moet nemen bij het werken met de  --force-optie.

Waarom dit alles voor je team kan breken

Als je je wijzigingen geforceerd pusht naar een gedeelde branch zoals main of develop, is de kans groot dat je het volgende meemaakt:

• Lokale branches van anderen raken uit sync: Als je teamgenoten de oude commits hebben gepulld die jij nu van de remote hebt gewist, komt hun lokale geschiedenis niet meer overeen met de server. Hun branches verwijzen naar commits die “verdwenen” zijn, wat verwarring veroorzaakt en 
• Pullen resulteert in verwarrende merges of fouten: Wanneer iemand probeert te git pull te doen nadat jij geforceerd hebt gepusht, weet Git niet hoe het de herschreven geschiedenis moet verenigen met hun lokale reeks commits. Dit leidt vaak tot vreemde merge-commits, cryptische fouten of situaties waarin teamgenoten worden gevraagd handmatig in te grijpen met git fetch, git reset of zelfs de branch opnieuw te clonen.
• CI/CD-pipelines kunnen falen: Pipelines vertrouwen vaak op consistente commit-hashes en een lineaire geschiedenis. Een force push kan ervoor zorgen dat tests falen, verkeerde code opnieuw wordt uitgerold of dat de pipeline crasht bij het herbouwen op verouderde commits.

Bekijk onze cursus CI/CD for Machine Learning om te begrijpen hoe je CI/CD-workflows opzet. Ik raad ook onze cursus Introduction to Data Versioning with DVC aan om het verschil tussen dataversiebeheer en codeversiebeheer te leren.

Laat me dit illustreren: je werkt op de feature-branch samen met een teamgenoot. Je ruimt je lokale geschiedenis op en draait vervolgens git push --force. Minuten later pusht je teamgenoot zijn wijzigingen. Die ziet fouten in Git. Bij het pullen ontstaan mergeconflicten en een verknipte commitgeschiedenis. Ondertussen faalt je CI-pipeline door missende commits. Nu verspilt je teamgenoot tijd aan het ontwarren van de branch en loopt de uitrol vertraging op.

Eén force push kan dit allemaal triggeren.

De veiligere optie: git push --force-with-lease

Om dit soort problemen te vermijden, raad ik aan git push --force-with-lease te gebruiken. Dit commando voegt een veiligheidscheck toe bij het pushen naar een remote branch om onverwachte commits te voorkomen.

git push --force-with-lease origin mainMogelijk gemaakt door

Zie --force-with-lease als “even vragen of de kust veilig is voordat je springt”. Voordat er iets gebeurt, controleert het of niemand anders de branch heeft gewijzigd. Als alles is zoals je het achterliet, wordt je geschiedenis bijgewerkt. Maar als er nieuwe wijzigingen zijn die je nog niet had, stopt Git je en vraagt het eerst de situatie te bekijken. Zo beschermt dit commando altijd je collega’s tegen onbedoeld overschrijven.

Herstellen van een mislukte force push

Als je commits bent kwijtgeraakt, geen paniek: je kunt ze nog herstellen. Git bewaart altijd een log van wijzigingen aan de huidige commit, inclusief herschrijvingen, in de reflog.

Zo kun je verloren commits terughalen:

Stap 1: Gebruik git reflog om verloren commits te vinden

Draai git reflog om je branchgeschiedenis te bekijken.

git reflogMogelijk gemaakt door

Je ziet je commits mogelijk zo:

abc1234 HEAD@{1}: push: force push
def5678 HEAD@{2}: commit: add new featureMogelijk gemaakt door

Stap 2: Herstel de verloren commit

Wanneer je de commit-hash hebt gevonden die je wilt herstellen, gebruik je onderstaand commando om naar de specifieke branchtoestand te gaan.

git checkout def5678Mogelijk gemaakt door

Stap 3: Maak een nieuwe branch

Maak een nieuwe git-branch om de bestanden veilig te herstellen.

git checkout -b recovery-branchMogelijk gemaakt door

Stap 4: Herstel de remote branch

Push nu de herstelde commits naar de branch:

git push origin recovery-branchMogelijk gemaakt door

Houd er rekening mee dat reflog-gegevens alleen op lokale machines bestaan. Daarom kun je verloren commits mogelijk niet terughalen als geen van je teamgenoten ze lokaal heeft opgeslagen.

Ik raad je aan onze cursus Intermediate Git te volgen om meer te leren over samenwerken en werken met branches in Git.

Best practices om git push --force veilig te gebruiken

Om de kans op problemen te verkleinen, zijn dit goede gewoonten:

• Geef de voorkeur aan --force-with-lease boven --force:  Deze methode is een veiligere optie die controleert of de remote branch sinds je laatste fetch niet is veranderd. Zo help je je teamgenoten te beschermen tegen per ongeluk overschrijven.

• Vermijd force-pushen naar gedeelde branches: Force-push nooit naar gedeelde branches zoals main, master, develop of release. Force push alleen naar je feature-branches waar jij de enige bijdrager bent, om verstoringen te voorkomen.

• Breng je team op de hoogte vóór een force push: Als je per se naar een gedeelde branch moet force-pushen, laat het je team weten. Zo kunnen zij hun werk veiligstellen en verlies voorkomen.

• Gebruik beschermde branches: Je kunt branches ook beschermen op platforms als GitHub, GitLab en Bitbucket. Dit beperkt directe edits en voorkomt per ongeluk force-pushes naar belangrijke branches.

Als je meer wilt leren over het beheren van private repo’s, bekijk dan onze cursus Introduction to GitHub Concepts om te begrijpen hoe je pull requests reviewt bij samenwerking op GitHub.

Conclusie

git push --force biedt een nuttige manier om de geschiedenis van je repo te herschrijven, of je nu commits wilt opschonen of gevoelige data wilt verwijderen. Wees altijd voorzichtig met dit commando om te voorkomen dat je de workflow van je team breekt.

Gebruik waar mogelijk --force-with-lease. Dat geeft je meer controle zonder het werk van anderen te riskeren. Met wat zorg en communicatie houd je je Git-geschiedenis netjes zonder je team in de problemen te brengen.

Ik raad je aan onze skill tracks Git Fundamentals en GitHub Foundations te bekijken om expert te worden in alles wat met Git te maken heeft.