Git switch vs checkout: het verschil uitgelegd

Lange tijd regelde git checkout vrijwel alles rond navigeren in een repository, van branches wisselen tot bestanden herstellen en oude commits bekijken. Die flexibiliteit zorgde voor onduidelijkheid: dezelfde syntax kon, afhankelijk van de context, iets anders betekenen.

Een kleine typo kon je van branch laten wisselen terwijl je eigenlijk een bestand wilde herstellen. Even snel de geschiedenis checken met git checkout <commit-hash> kon je ongemerkt in een detached HEAD-state achterlaten. Het commando deed het wel, maar je moest voortdurend rekening houden met de meerdere gedragingen.

Daarom introduceerde Git 2.23 git switch, een meer gespecialiseerde command voor branchoperaties.

In deze gids laat ik je zien hoe git switch verschilt van git checkout. We bekijken ook waar elk commando past in moderne workflows en welke scopes ze hebben.

Is Git nog relatief nieuw voor je? Leer dan eerst de basis in onze cursus Introduction to Git.

Wat is Git switch?

git switch is een dedicated commando, geïntroduceerd in Git 2.23, voor het navigeren tussen en aanmaken van branches. Het maakt schakelen tussen branches schoner, veiliger en minder foutgevoelig.

Voor die tijd gebruikten ontwikkelaars git checkout om van branch te wisselen. Het probleem was dat git checkout meerdere, niet-verwante taken afhandelde: 

• Branches wisselen
• Bestanden herstellen
• Commits inspecteren

Daardoor raakte het commando overbelast en werd misbruik makkelijker.

Git heeft dit opgelost door verantwoordelijkheden te scheiden. git switch regelt nu het wisselen en aanmaken van branches, en git restore het herstellen van bestanden. Deze scheiding verlaagt de ambiguïteit en verkleint het risico op onbedoelde bestandswijzigingen.

In de praktijk verplaatst git switch branch-name je huidige HEAD-pointer naar de opgegeven branchnaam. Je kunt ook git switch -c new-branch gebruiken om een nieuwe branch te maken én daar naartoe te schakelen.

Git switch vs checkout: de kernmechaniek

Nu je weet waarom git switch is geïntroduceerd, kijken we hoe het onder de motorkap daadwerkelijk verschilt van git checkout.

Doelgerichte branch-voering

Voor Git 2.23 deed git checkout zowel branchnavigatie als bestandsherstel. Dat werkte, maar mengde twee fundamenteel verschillende concepten. Het verplaatst HEAD, herstelt bestanden en checkt commits uit. Afhankelijk van je gebruik manipuleert het de HEAD-pointer, de index en de working tree.

git switch richt zich uitsluitend op het verplaatsen van de HEAD-pointer tussen branches. Wanneer je git switch branch-name uitvoert, werkt Git HEAD bij zodat die naar die branch verwijst en past het de werkdirectory aan om ermee overeen te komen. Dit commando bestaat dus specifiek voor branchnavigatie en -creatie. Met git switch en git restore zijn de verantwoordelijkheden netjes gescheiden:

• git switch verplaatst HEAD tussen branches.

• git restore wijzigt bestanden in de working tree of index.

Vroeger moest je bijvoorbeeld een bestand herstellen met: git checkout HEAD -- file.txt. Tegenwoordig is de aanbevolen aanpak: git restore file.txt.

Hier ben je een bestand aan het herstellen, niet aan het navigeren tussen branches. In scripts en teamdocumentatie verbetert dit onderscheid de leesbaarheid en verkleint het de kans op fouten.

Evolutie van Git-commando’s

Git 2.23 scheidt verantwoordelijkheden door git switch te introduceren voor branchoperaties en git restore voor bestandsherstel.

Daarvoor fungeerde git checkout als een multifunctionele tool. Het kon van branch wisselen, bestanden herstellen of naar willekeurige commits gaan. Dat zorgde echter voor verwarring, vooral voor nieuwe gebruikers. Door het commando op te splitsen, verminderde Git de ambiguïteit en werden veelvoorkomende workflows duidelijker.

Detached HEAD-gedrag

In Git wijst HEAD normaal gesproken naar een branch. Die branch wijst op zijn beurt naar de laatste commit. Wanneer je een nieuwe commit maakt, schuift Git de branch vooruit. Dat is de standaardworkflow.

Een detached HEAD ontstaat wanneer HEAD direct naar een commit wijst in plaats van naar een branch. In die staat zit je niet meer op een branch. Als je een nieuwe commit maakt, wordt die wel aangemaakt, maar geen enkele branchnaam verwijst ernaar. Tenzij je expliciet een branch aanmaakt, blijven die commits ongerefereerd en kunnen ze later lastig terug te vinden zijn.

Wanneer je git checkout <commit-hash> uitvoert, gaat Git automatisch naar de detached HEAD-modus. Git schakelt naar die commit en detacht HEAD zonder extra bevestiging. Dit gedrag is geldig, maar je komt zo makkelijk onbewust in detached modus terecht.

Daarentegen vereist git switch expliciete vermelding. Om HEAD te detachen moet je git switch --detach <commit-hash> gebruiken. Zonder de --detach-vlag werkt git switch alleen met branches. Dit ontwerp verkleint de kans op per ongeluk gedetacheerde states en maakt branchworkflows veiliger en voorspelbaarder.

Belangrijkste functionele verschillen tussen Git switch en checkout

Nu we de verschillen op hoofdlijnen hebben behandeld, kijken we naar syntax, scope en veiligheidsaspecten.

Commandsyntax en aanmaken

Om met git switch een nieuwe branch te maken en er meteen naartoe te schakelen, gebruik je git switch -c <branch-name>. Met git checkout is het equivalente commando git checkout -b <branch-name>.

Beide commando’s maken een nieuwe branch en schakelen ernaartoe, maar het verschil zit in hoe duidelijk het commando zijn intentie uitdrukt. In git switch geeft de -c-vlag direct aan dat je een branch aanmaakt, terwijl -b in git checkout historisch „branch” betekent, maar minder expliciet is in intentie.

git switch introduceert ook de -C-vlag: git switch -C <branch-name>. Het effect is sterker dan dat van -c: het forceert het aanmaken van de branch, of reset deze als hij al bestaat. Dit gedrag is expliciet en branch-gericht. In git checkout bestaat een vergelijkbaar force-gedrag, maar de semantiek is minder duidelijk gescheiden omdat het commando meerdere doelen dient.

Scope van operaties

git switch werkt uitsluitend met branches. Het kan geen bestanden herstellen, wijzigingen unstagen of specifieke paden uit eerdere commits uitchecken. Het ondersteunt kortom geen bewerkingsniveau op bestandsniveau.

Daarentegen kan git checkout wel op bestandsniveau opereren. Zo herstelt git checkout <commit> -- <file> een specifiek bestand uit een eerdere commit. 

Moderne Git-documentatie raadt echter aan om hiervoor git restore te gebruiken. Het belangrijkste punt is dat git switch bestandsmanipulatie bewust uitsluit om de scope smal en voorspelbaar te houden.

Veiligheid en disambiguatie

Een veelvoorkomend probleem met git checkout is dubbelzinnigheid. Als een branchnaam en bestandsnaam identiek zijn, kan het, afhankelijk van de context, van branch wisselen of een bestand herstellen. git switch voorkomt die ambiguïteit volledig. Het werkt alleen met branches. Als je geen geldige branchnaam opgeeft, faalt Git duidelijk in plaats van te raden. 

git switch biedt ook duidelijkere foutafhandeling wanneer lokale wijzigingen conflicteren met de doelbranch. Als schakelen branches onbevestigd werk zou overschrijven, stopt Git de operatie en toont het een directe foutmelding, zoals de volgende: 

• Als de branch niet bestaat: fatal: invalid reference: feature/login

• Als lokale wijzigingen zouden worden overschreven: error: Your local changes to the following files would be overwritten by checkout

• Als de branch al bestaat bij gebruik van -c: fatal: a branch named 'feature/login' already exists

Dergelijke duidelijke foutmeldingen verkleinen de kans op onbedoelde statuswijzigingen.

Praktische voorbeelden van Git switch

git switch wordt veel duidelijker zodra je het in echte workflows ziet. Deze voorbeelden laten zien hoe het zich gedraagt in alledaags branchbeheer en waarom het veiliger en voorspelbaarder aanvoelt dan git checkout.

Standaard branchoperaties

In het dagelijks werk wissel je vooral tussen branches of maak je nieuwe aan.

• Om naar een bestaande lokale branch te schakelen, gebruik je: git switch <branch_name>. Hierbij verplaatst Git HEAD naar de genoemde branchnaam en werkt je werkdirectory bij om die branch te weerspiegelen.

• Om een nieuwe branch voor een nieuwe feature genaamd „new_ui” te maken en er in één stap naartoe te schakelen, gebruik je git switch -c feature/new-ui. Dit maakt de branch vanaf je huidige commit en verplaatst HEAD er meteen naartoe.

• Als je een bestaande branch moet resetten of overschrijven, gebruik dan: git switch -C feature/new-ui. De hoofdletter -C forceert het aanmaken of reset de branchpointer. Hiermee maak je destructieve intentie expliciet.

• Je kunt ook snel wisselen tussen je laatste twee branches met git switch -. Handig bij het reviewen op de ene branch en telkens terugkeren naar je featurebranch.

Werken met remote branches

Vaak bestaat een branch wel op de remote maar nog niet lokaal. Iemand pusht bijvoorbeeld origin/bugfix, maar jij hebt die lokaal nog niet aangemaakt.

• Als je uitvoert: git switch bugfix, maakt Git een lokale bugfix-branch en stelt die in om de remote branch origin/bugfix te volgen, ervan uitgaand dat er een duidelijke match in origin is. Dit vereenvoudigt samenwerken, omdat je upstream-tracking niet handmatig hoeft te zetten.

• Wil je voorkomen dat Git gokt, gebruik dan: git switch --no-guess bugfix. Nu faalt Git als de branch niet lokaal bestaat. Nuttig in striktere workflows waar automatische tracking verwarring kan veroorzaken.

• Als je de trackingbranch liever expliciet aanmaakt, gebruik dan git switch -c bugfix --track origin/bugfix. Zo is de trackingrelatie duidelijk in het commando zelf.

Experimenteel commits inspecteren

Soms wil je gewoon even naar een oude commit kijken. Misschien wil je een vorige versie testen of nagaan wanneer een bug is geïntroduceerd. In dat geval wil je tijdelijk naar dat punt in de geschiedenis gaan.

Met git switch moet je dat expliciet aangeven: git switch --detach <commit-hash>.

De --detach-vlag zegt tegen Git: verplaats HEAD direct naar deze commit, niet naar een branch. Je kunt nu de code verkennen, tests draaien of het project bouwen. Als je in deze staat nieuwe commits maakt, zijn die nergens aan gekoppeld tenzij je een branch aanmaakt.

Met git checkout <commit-hash> gebeurt hetzelfde automatisch, zonder extra vlag. Zo kom je makkelijk onbedoeld in detached modus, terwijl de vereiste --detach-vlag in git switch dat voorkomt. 

Git switch integreren in je workflow

Laten we vervolgens bekijken hoe je git switch in typische Git-workflows kunt integreren.

Scenario-gebaseerde keuze

In moderne ontwikkelworkflows zou git switch al het branch-gerelateerde werk moeten afhandelen. Dat omvat 

• Routinematige feature-ontwikkeling
• Pull requests reviewen
• Lokaal rebasen
• CI/CD-scripts die tijdens builds branches uitchecken

Omdat git switch zich uitsluitend op branchbeheer richt, communiceert het de intentie duidelijk.

git checkout heeft nog steeds een rol, maar die is nu smaller. Legacy-automatisering die vóór Git 2.23 is geschreven, vertrouwt er vaak op. Bepaalde herstelacties op bestandsniveau kunnen het ook nog gebruiken, al is git restore de geprefereerde vervanger voor de toekomst.

Veelvoorkomende fouten oplossen

Er zijn twee scenario’s die problemen kunnen veroorzaken bij het gebruik van git switch.

„Your local changes would be overwritten”

Een veelvoorkomend probleem wanneer je probeert van branch te wisselen terwijl er lokale wijzigingen zijn, is „error: Your local changes would be overwritten”. Git blokkeert de actie omdat schakelen onbevestigd werk zou overschrijven. Je hebt twee veilige opties:

1. Wil je de wijzigingen later bewaren, voer dan git stash uit voordat je naar de doelbranch schakelt. Na het schakelen kun je ze terughalen met git stash pop.

2. Wil je lokale wijzigingen bewust weggooien, gebruik dan: git switch --discard-changes target-branch. Deze optie zegt tegen Git dat lokale wijzigingen worden weggegooid en dat index en working tree worden teruggezet naar de doelbranch (verwijdert geen ongetrackte bestanden).

Per ongeluk in een detached HEAD-state belanden

Een ander scenario is dat je per ongeluk in een detached HEAD-state terechtkomt. Als je merkt dat je niet op een branch zit maar werk hebt dat je wilt behouden, maak dan meteen een nieuwe branch: git switch -c recovery-branch. Hiermee koppel je je huidige commithistorie aan een benoemde branch en behoud je je wijzigingen.

Best practices voor het adopteren van Git switch

git switch adopteren is meer dan een voorkeurscommando. Het is een kleine structurele upgrade in hoe teams over Git-workflows denken. De voordelen stapelen zich op als de adoptie consistent is in documentatie, onboarding en automatisering.

Migratiestrategieën voor teams

Begin met je interne documentatie. Als je „Aan de slag”-gidsen nog git checkout aanleren voor branches wisselen, werk ze dan bij naar git switch. Behoud checkout alleen waar het echt nodig is.

Training speelt ook een rol. Moderne Git-commando’s leveren duidelijkere foutmeldingen, vooral wanneer lokale wijzigingen conflicteren met een branchwissel. Moedig ontwikkelaars aan deze berichten te lezen en te begrijpen in plaats van ze als generieke fouten te zien. De nieuwere set commando’s is explicieter; dat herkennen vergroot het vertrouwen en vermindert fouten.

Consistentie in automatisering

Geef in shellscripts, CI-pijplijnen en Git-aliases de voorkeur aan git switch voor branchnavigatie, omdat het de intentie meteen duidelijk maakt. Een script dat git switch main gebruikt is makkelijker te interpreteren dan één dat git checkout gebruikt, wat meerdere betekenissen kan hebben. 

Als je Git-aliases definieert, werk ze dan bij naar modern gebruik. Een alias voor het aanmaken van featurebranches moet bijvoorbeeld git switch -c gebruiken, niet git checkout -b.

Controleer tot slot Git-versies in alle omgevingen. git switch vereist Git 2.23 of hoger. Zorg dat lokale ontwikkelmachines, CI-runners en buildservers hieraan voldoen voordat je op het nieuwe commando standaardiseert. Een simpele versiecheck voorkomt subtiele compatibiliteitsproblemen.

Conclusie

Kijk je naar het grotere plaatje, dan is het echte voordeel van git switch simpel: het maakt branchbeheer duidelijker, veiliger en doelgerichter. Als je het commando uitvoert, is er geen ambiguïteit over wat het doet. Je wisselt van branch. Dat is alles. En dat beetje extra duidelijkheid haalt verrassend veel wrijving uit het dagelijkse ontwikkelwerk.

git checkout is echter niet afgeschaft; je kunt het nog steeds gebruiken om bestanden te herstellen, tussen branches te wisselen of complexere scenario’s af te handelen. Maar voor dagelijkse branchnavigatie moedigt Git je aan om git switch te gebruiken.

Als volgende stap raad ik onze cursus Intermediate Git aan, die zich richt op samenwerken met Git.