Remotes, zonder server · oefening
Fetchen zonder main te verplaatsen
Alle drie de repositories komen nu overeen. Om te zien wat fetch werkelijk doet, maak je één latere commit in garden, push je die naar de bare repository en fetch je die in garden-copy. Er is maar één schrijver, dus de geschiedenissen lopen niet uiteen.
Laat garden en zijn origin vooruitgaan
Ga vanuit garden-copy terug naar de klaargezette repository garden en open daarna een nieuwe bezorgnotitie in nano:
cd ../garden
nano -w delivery.txt
Typ deze ene regel, sla op met Ctrl-O en Enter en sluit af met Ctrl-X:
Seed delivery: Friday
Stage de opgeslagen notitie en commit die met opdrachten die je al kent:
git add delivery.txt
git commit -m "Record the seed delivery"
De lokale main van garden heeft nu één commit die de andere repositories nog niet hebben. In les 3 legde -u een upstream voor deze branch vast. Omdat die relatie de remote en branch al levert, is nu alleen git push genoeg:
git push
De push verplaatst main in origin.git naar de nieuwe commit. Die werkt ook de eigen registratie origin/main van garden bij. garden-copy heeft sinds het klonen geen informatie uitgewisseld, dus beide refs daar staan nog bij de meegeleverde commit.
Fetch in de kloon
git fetch benadert een ingestelde remote, haalt commits en andere objecten op die de huidige repository mist en werkt de bijbehorende remote-tracking refs bij. Het verplaatst je lokale branch niet en verandert de uitgecheckte bestanden niet.
Ga terug naar de kloon en fetch vanuit de standaardremote origin:
cd ../garden-copy
git fetch
Het woord “benaderen” betekent hier niet dat er een netwerk is. garden-copy leest de repository ../origin.git ernaast rechtstreeks van schijf.
Vergelijk de lokale main met origin/main
Lees eerst de remote-tracking geschiedenis en daarna de geschiedenis van de lokale branch:
git log origin/main
git log main
git status
origin/main bevat nu delivery.txt, omdat fetch de registratie van de remotebranch in de kloon heeft bijgewerkt. De lokale main eindigt nog steeds bij de meegeleverde commit List the first plants. Ook de werkboom van de kloon bevat nog alleen README.md en plants.txt en is schoon.
Dat verschil is de les om te onthouden:
garden main ---------> new delivery commit
origin.git main -----> new delivery commit
garden-copy origin/main -> new delivery commit
garden-copy main ----> seeded List the first plants commit
Fetch bracht informatie de kloon in zonder te kiezen wat er met de lokale branch moest gebeuren. Werk combineren of vooruitzetten na fetch hoort bij het volgende hoofdstuk.
Waarom kunnen origin/main en de lokale main na git fetch naar verschillende commits wijzen?
Dat verschil tussen origin/main en main binnen de kloon is geen fout die je snel moet corrigeren. Git houdt bewust twee feiten uit elkaar: wat de andere repository bevatte toen je voor het laatst keek, en wat jij hebt besloten ermee te doen. Door die apart te houden kun je eerst kijken en dan pas handelen.
Beslissen wat je ermee doet is hoofdstuk 8. Daar wordt het lastiger op precies de manier die dit hoofdstuk vermeed: beide kanten zijn verdergegaan.