-
1. Aan de slag
- 1.1 Over versiebeheer
- 1.2 Een kort historisch overzicht van Git
- 1.3 Wat is Git?
- 1.4 De commando-regel
- 1.5 Git installeren
- 1.6 Git klaarmaken voor eerste gebruik
- 1.7 Hulp krijgen
- 1.8 Samenvatting
-
2. Git Basics
-
3. Branchen in Git
- 3.1 Branches in vogelvlucht
- 3.2 Eenvoudig branchen en mergen
- 3.3 Branch-beheer
- 3.4 Branch workflows
- 3.5 Branches op afstand (Remote branches)
- 3.6 Rebasen
- 3.7 Samenvatting
-
4. Git op de server
- 4.1 De protocollen
- 4.2 Git op een server krijgen
- 4.3 Je publieke SSH sleutel genereren
- 4.4 De server opzetten
- 4.5 Git Daemon
- 4.6 Slimme HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Hosting oplossingen van derden
- 4.10 Samenvatting
-
5. Gedistribueerd Git
-
6. GitHub
-
7. Git Tools
- 7.1 Revisie Selectie
- 7.2 Interactief stagen
- 7.3 Stashen en opschonen
- 7.4 Je werk tekenen
- 7.5 Zoeken
- 7.6 Geschiedenis herschrijven
- 7.7 Reset ontrafeld
- 7.8 Mergen voor gevorderden
- 7.9 Rerere
- 7.10 Debuggen met Git
- 7.11 Submodules
- 7.12 Bundelen
- 7.13 Vervangen
- 7.14 Het opslaan van inloggegevens
- 7.15 Samenvatting
-
8. Git aanpassen
- 8.1 Git configuratie
- 8.2 Git attributen
- 8.3 Git Hooks
- 8.4 Een voorbeeld van Git-afgedwongen beleid
- 8.5 Samenvatting
-
9. Git en andere systemen
- 9.1 Git als een client
- 9.2 Migreren naar Git
- 9.3 Samenvatting
-
10. Git Binnenwerk
- 10.1 Binnenwerk en koetswerk (plumbing and porcelain)
- 10.2 Git objecten
- 10.3 Git Referenties
- 10.4 Packfiles
- 10.5 De Refspec
- 10.6 Uitwisseling protocollen
- 10.7 Onderhoud en gegevensherstel
- 10.8 Omgevingsvariabelen
- 10.9 Samenvatting
-
A1. Bijlage A: Git in andere omgevingen
- A1.1 Grafische interfaces
- A1.2 Git in Visual Studio
- A1.3 Git in Visual Studio Code
- A1.4 Git in Eclipse
- A1.5 Git in Sublime Text
- A1.6 Git in Bash
- A1.7 Git in Zsh
- A1.8 Git in PowerShell
- A1.9 Samenvatting
-
A2. Bijlage B: Git in je applicaties inbouwen
- A2.1 Commando-regel Git
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
- A2.5 Dulwich
-
A3. Bijlage C: Git Commando’s
- A3.1 Setup en configuratie
- A3.2 Projecten ophalen en maken
- A3.3 Basic Snapshotten
- A3.4 Branchen en mergen
- A3.5 Projecten delen en bijwerken
- A3.6 Inspectie en vergelijking
- A3.7 Debuggen
- A3.8 Patchen
- A3.9 Email
- A3.10 Externe systemen
- A3.11 Beheer
- A3.12 Binnenwerk commando’s (plumbing commando’s)
10.5 Git Binnenwerk - De Refspec
De Refspec
In dit hele boek hebben we eenvoudige verbanden (mappings) gebruikt tussen remote branches naar lokale referenties, maar ze kunnen veel complexer zijn. Stel even dat je met de paar laatste secties hebt meegedaan en een kleine lokale Git repository gemaakt hebt, en nu een remote eraan zou willen toevoegen:
$ git remote add origin https://github.com/schacon/simplegit-progit
Dit commando voegt een sectie toe aan je .git/config
bestand, waarbij de naam van de remote (origin
) wordt opgegeven, de URL van de remote repository en de refspec die gebruikt moet worden voor het fetchen:
[remote "origin"]
url = https://github.com/schacon/simplegit-progit
fetch = +refs/heads/*:refs/remotes/origin/*
Het formaat van de refspec is, eerst, een optionele {plus}
, gevolgd door <src>:<dst>, waar `<src>
het patroon is voor referenties aan de remote kant, en <dst>
de plaats is waar deze referenties lokaal zullen worden getrackt.
De {plus}
draagt Git op om de referenties bij te werken zelfs als het geen fast-forward is.
In het standaard geval dat automatisch wordt geschreven door een git remote add origin
commando, zal Git alle referenties onder refs/heads
op de server fetchen en ze lokaal naar refs/remotes/origin
schrijven.
Dus, als er een master
-branch op de server is, kan je de log van deze branch op deze manieren benaderen:
$ git log origin/master
$ git log remotes/origin/master
$ git log refs/remotes/origin/master
Dit is allemaal gelijkwaardig, omdat Git elk van deze uitwerkt tot refs/remotes/origin/master
.
Als je in plaats hiervan Git alleen de master
-branch wilt laten pullen, en niet elke andere branch op de remote
server, kan je de fetch regel wijzigen zodat het alleen naar die branch wijst:
fetch = +refs/heads/master:refs/remotes/origin/master
Dit is gewoon de standaard refspec voor git fetch
naar die remote.
Als je een eenmalige fetch wilt doen, kan je de refspec ook op de command regel opgeven.
Om de master
-branch te pullen van de remote naar een lokale origin/mymaster
, kan je dit aanroepen
$ git fetch origin master:refs/remotes/origin/mymaster
Je kunt ook meerdere refspecs opgeven. Op de commando regel kan je meerdere branches als volgt pullen:
$ git fetch origin master:refs/remotes/origin/mymaster \
topic:refs/remotes/origin/topic
From git@github.com:schacon/simplegit
! [rejected] master -> origin/mymaster (non fast forward)
* [new branch] topic -> origin/topic
In dit geval wordt de pull van de master
-branch geweigerd omdat het niet als een fast-forward referentie was opgegeven.
Je kunt dat overschrijven door een {plus}
voor de refspec op te geven.
Je kunt ook meerdere respecs voor fetchen aangeven in je configuratie bestand.
Als je altijd de master
en experiment
-branches wilt fetchen, voeg je twee regels toe:
[remote "origin"]
url = https://github.com/schacon/simplegit-progit
fetch = +refs/heads/master:refs/remotes/origin/master
fetch = +refs/heads/experiment:refs/remotes/origin/experiment
Je kunt niet gedeeltelijke globs in het patroon opgeven, dus dit zou ongeldig zijn:
fetch = +refs/heads/qa*:refs/remotes/origin/qa*
Echter, je kunt naamsruimten (namespaces) of directories opgeven om zoiets voor elkaar te krijgen. Als je een QA team hebt die een reeks van branches pusht, en je wilt de master branch verkrijgen en alle branches van het QA team maar niets anders, kan je een configuratie instelling als deze gebruiken:
[remote "origin"]
url = https://github.com/schacon/simplegit-progit
fetch = +refs/heads/master:refs/remotes/origin/master
fetch = +refs/heads/qa/*:refs/remotes/origin/qa/*
Als je een complexe workflow proces hebt waarbij een QA-team branches pusht, waarbij ontwikkelaar branches pushen en integratie teams die pushen naar en samenwerken op remote branches, kan je ze op deze manier eenvoudig namespaces toewijzen.
Refspecs pushen
Het is leuk dat je namespaced referenties op deze manier kunt fetchen, maar hoe krijgt het QA-team om te beginnen hun branches in een qa/
namespace?
Je krijgt dit voor elkaar door refspecs te gebruiken om te pushen.
Als het QA-team hun master
-branch naar qa/master
op de remote server wil pushen, kunnen ze dit aanroepen:
$ git push origin master:refs/heads/qa/master
Als ze willen dat Git dit elke keer automatisch doet als ze git push origin
aanroepen, kunnen ze een push
waarde aan hun configuratie bestand toevoegen:
[remote "origin"]
url = https://github.com/schacon/simplegit-progit
fetch = +refs/heads/*:refs/remotes/origin/*
push = refs/heads/master:refs/heads/qa/master
Nogmaals, dit zal ervoor zorgen dat een git push origin
de lokale master
-branch standaard naar de remote qa/master
-branch pusht.
Noot
|
Je kunt de refspec niet gebruiken om van de ene repository te fetchen en te pushen naar een andere. Voor een voorbeeld hoe dit wel te doen, zie Houd je GitHub openbare repository up-to-date. |
References verwijderen
Je kunt de refspec ook gebruiken om referenties te verwijderen van de remote server door iets als dit aan te roepen:
$ git push origin :topic
Omdat de refspec <src>:<dst>
is zegt dit, door het weglaten van het <src>
gedeelte, eigenlijk dat de topic branch van de remote niets moet worden, waarmee het wordt verwijderd.
Of je kunt de nieuwere syntax gebruiken (beschikbaar vanaf Git v1.7.0):
$ git push origin --delete topic