Pull is fetch plus integratie

Een lokale branch en zijn upstream kunnen al overeenkomen, zodat er geen nieuw werk te integreren is. Die rustige toestand is de veiligste plek om Gits gemaksopdracht git pull te bekijken, zolang je de twee onderdelen ervan in je denkmodel zichtbaar houdt.

De afbeelding toont een fast-forward-pull. Andere pulls kunnen in plaats daarvan een mergecommit maken of rebase gebruiken. Boven staat de lokale repository na fetch (“local repository after fetch”): de werkboom (“working tree”) toont nog commit B. Onder staat de lokale repository na pull: daar toont de werkboom commit C. Links staat telkens de remote.

Pull voert twee taken uit

De opdracht git pull fetcht eerst vanuit de upstreamremote en werkt remote-tracking informatie zoals origin/main bij. Daarna integreert die de opgehaalde upstreambranch in de huidige lokale branch. Die tweede stap is niet altijd hetzelfde als merge: Git kan worden ingesteld of expliciet de opdracht krijgen om te mergen, te rebasen of alleen een fast-forward te accepteren. Een pull kan dus de lokale main en de werkboom verplaatsen, in tegenstelling tot een fetch.

Je repository shop is al volledig geïntegreerd en gepusht. De gewone opdracht nu uitvoeren is veilig omdat er niets nieuws te integreren is:

git pull
git status

Git meldt dat de branch al actueel is en de werkboom blijft schoon. Als de geschiedenissen uiteen waren gelopen en er geen integratievoorkeur was gekozen, zou moderne Git kunnen stoppen en je om een keuze vragen in plaats van te gokken. Daarom was git fetch, gevolgd door inspectie en een expliciete git merge origin/main, de juiste leerroute voor de eerdere divergentie.

Gehoste hulpmiddelen bouwen rond dezelfde uitwisseling

De oefeningen gebruikten een lokaal pad voor origin. Bij een hostingdienst bewaart een remote doorgaans een HTTPS- of SSH-URL. De URL verandert hoe Git de andere repository bereikt; niet wat commits, branches, origin of origin/main betekenen. De dienst kan authenticatie vereisen: bewijs dat jouw account die repository mag lezen of bijwerken. Het instellen van accounts, tokens en sleutels hoort bij de dienst, niet bij Gits geschiedenismodel.

Een fork is een andere repository die een hostingdienst onder een ander account of een andere naamruimte maakt. Het is geen branch en niet de werkkopie die git clone maakt. Je kunt een fork klonen en er commits mee uitwisselen met dezelfde fetch-, merge-, pull- en pushbewerkingen die je lokaal hebt geoefend.

Een pull request, bij sommige diensten merge request genoemd, is een gehost voorstel om commits te beoordelen en de ene branch in de andere te integreren. Het is geen commit en niet de opdracht git pull. De website voegt discussie en review toe rond de Git-geschiedenissen; die geschiedenissen komen nog steeds samen via de integratiewerking die je al kent.

Het veilige patroon is nu duidelijk onder zowel lokale als gehoste hulpmiddelen: fetch om te vernieuwen wat je repository weet, vergelijk de geschiedenissen, integreer zonder een van beide kanten weg te gooien en push pas wanneer de gedeelde tip een voorouder van het resultaat blijft.