3.5 Branchen in Git - Branches op afstand (Remote branches)

Als je een branch wil delen met de rest van de wereld, dan moet je het naar een remote terugzetten waar je schrijftoegang op hebt. Je lokale branches worden niet automatisch gesynchroniseerd met de remotes waar je naar schrijft — je moet de branches die je wilt delen expliciet pushen. Op die manier kun je privé branches gebruiken voor het werk dat je niet wil delen, en alleen die topic branches pushen waar je op wilt samenwerken.

Als je een branch genaamd serverfix hebt waar je met anderen aan wilt werken, dan kun je die op dezelfde manier pushen als waarop je dat voor de eerste branch hebt gedaan. Voer git push <remote> <branch< uit:

Dit is wel een beetje de bocht afsnijden. Git zal de serverfix-branchnaam automatisch expanderen naar refs/heads/serverfix:refs/heads/serverfix, wat staat voor “Neem mijn lokale serverfix branch en push die om de serverfix branch van de remote te vernieuwen.”. We zullen het refs/heads gedeelte gedetaileerd behandelen in Git Binnenwerk, maar je kunt het normaalgesproken weglaten. Je kun ook git push origin serverfix:serverfix doen, wat hetzelfde doet. Dit staat voor “Neem mijn serverfix en maak het de serverfix van de remote.” Je kunt dit formaat gebruiken om een lokale branch te pushen naar een remote branch die anders heet. Als je niet wil dat het serverfix heet aan de remote kant, kan je in plaats daarvan git push origin serverfix:awesomebranch gebruiken om je lokale serverfix-branch naar de awesomebranch op het remote project te pushen.

De volgende keer dat één van je medewerkers van de server fetcht zal deze een referentie krijgen naar de versie van serverfix op de server, onder de remote branch origin/serverfix:

Het is belangrijk om op te merken dat wanneer je een fetch doet die nieuwe remote-tracking branches ophaalt, je niet automatisch lokale aanpasbare kopieën daarvan hebt. In andere woorden, in dit geval heb je geen nieuwe serverfix-branch — je hebt alleen een origin/serverfix verwijzing die je niet kunt aanpassen.

Om dit werk in je huidige werk branch te mergen, kun je git merge origin/serverfix uitvoeren. Als je een eigen serverfix-branch wilt waar je op kunt werken, dan kun je deze op je remote-tracking branch baseren:

Dit maakt een lokale branch aan waar je op kunt werken, die begint waar origin/serverfix is.

Een lokale branch uitchecken van een remote-tracking branch creëert automatisch een zogenoemde “tracking branch” (“volg branch”, en de branch die hij volgt heet een “upstream branch”). Tracking branches zijn lokale branches die een directe releatie met een remote branch hebben. Als je op een tracking branch zit en git pull typt, dat weet Git automatisch naar welke server moet gaan om de wijzigingen op te halen en in welke branch deze moeten worden gemerged.

Als je een repository kloont, zal het over het algemeen automatisch een master-branch aanmaken die origin/master trackt. Maar je kan ook andere tracking branches aanmaken als je dat wilt — andere die branches op andere remotes tracken, of niet de master-branch tracken. Een eenvoudig voorbeeld is wat je zojuist gezien hebt: git checkout -b <branch> <remotenaam>/<branch> uitvoeren. Deze operatie komt dusdanig vaak voor dat Git de --track afkorting levert:

Sterker nog, dit is zo gewoon dat er zelfs een afkorting voor de afkorting is. Als de branch naam die je uit wilt checken (a) niet bestaat en (b) dezelfde naam maar op een remote voorkomt, zal Git een tracking branch voor je aanmaken:

Om een lokale branch te maken met een andere naam dan de remote branch, kun je simpelweg de eerste variant met een andere lokale branchnaam gebruiken:

Nu zal je lokale sf-branch automatisch pullen van origin/serverfix.

Als je al een lokale branch hebt en je wilt deze koppelen aan een remote branch die je zojuist gepulld hebt, of de stroomopwaartse branch die je trackt wijzigen, kan je de -u of --set-upstream-to optie gebruiken bij de git branch om het expliciet te zetten op de momenten dat jij het wilt.

Als je wilt zien welke tracking branches je ingericht hebt, kan je de -vv optie aan git branch meegeven. Dit zal jouw lokale branches afdrukken met meer informatie, inclusief wat elk van de branches trackt en of je lokale branch voorloopt, acherloopt of beide.

Dus hier kunnen we zien dat onze iss53 origin/iss53 trackt en twee “voorloopt”, wat inhoudt dat we lokaal twee commits hebben die nog niet naar de server zijn gepusht. We kunnen ook zien dat onze master-branch origin/master trackt en up-to-date is. Vervolgens zien we dat onze serverfix-branch de server-fix-good-branch trackt op onze teamone server en drie voorloopt en een achterloopt. Dit betekent dat er een commit op de server staat die we nog niet hebben gemerged en er drie commits lokaal staan die we nog niet gepusht hebben. Tenslotte kunnen we zien dat onze testing-branch geen enkele remote branch trackt.

Het is belangrijk om op te merken dat deze getallen accuraat zijn op het moment dat je voor het laatst gefetcht hebt van elke server. Dit commando maakt geen contact met de servers, het vertelt je wat het van deze servers lokaal heeft opgeslagen. Als je volledige up-to-date gegevens wilt hebben over voorsprong en achterstand zal je van alle remotes moeten fetchen voordat je dit aanroept. Je zou iets als volgt kunnen doen:

Waar het git fetch commando alle wijzigingen van de server zal ophalen die je nog niet hebt, zal het je werk directory helemaal niet wijzigen. Het haalt simpelweg de gegevens voor je op en laat het mergen aan jou over. Er is echter een commando git pull geheten die feitelijk een git fetch onmiddelijk gevolgd door een git merge is in de meeste gevallen. Als je een tracking branch opgezet hebt zoals in de vorige paragraaf getoond, expliciet opgezet of voor je opgezet door de clone of checkout commando’s, zal git pull kijken welke server en branch je huidige branch trackt, van die server fetchen en de betreffende remote branch daarin mergen.

Over het algemeen is het beter om de fetch en merge commando’s expliciet te gebruiken omdat de magie van git pull vaak verwarrend kan zijn.

Stel dat je klaar bent met een remote branch - zeg maar, jij en je medewerkers zijn klaar met een feature en hebben het gemerged in de master-branch van de remote (of welke branch jullie stabiele code ook in zit). Je kunt een remote branch verwijderen met de --delete optie bij git push. Als je de serverfix-branch van de server wilt verwijderen, dan voer je het volgende uit:

Alles wat dit doet is de pointer van de server verwijderen. De Git server zal over het algemeen de gegevens nog een poos behouden totdat de garbage collection draait, dus als het per ongeluk verwijderd is, is het vaak eenvoudig terug te halen.