Overal in dit boek hebben we tientallen Git commando’s geïntroduceerd en we hebben ons best gedaan om ze te introduceren met een verhaaltje, en langzaamaan meer commando’s toe te voegen. Echter, hiermee zijn we geeindigd met een situatie waarbij de voorbeelden van het gebruik van commando’s nogal versnipperd zijn geraakt over het hele boek.
In deze appendix zullen we alle Git commando’s die we hebben behandeld in dit boek nogmaals doornemen, grofweg gegroepeerd op het gebruik ervan. We zullen globaal bespreken wat elk commando doet en verwijzen naar de plaats in het boek waar je kunt vinden waar we het hebben gebruikt.
Er zijn twee commando’s die heel vaak gebruikt worden, van de eerste aanroepen van Git tot normale dagelijks gebruikte bijstellingen en referenties, de config en help commando’s.
Git heeft een standaard manier om vele honderden dingen te doen. Voor veel van deze dingen, kan je Git vertellen om deze dingen standaard anders uit te voeren, of je voorkeuren instellen. Dit kan alles omvatten van Git vertellen wat je naam is, tot voorkeuren voor specifieke werkstation kleuren of welke editor je gebruikt. Er zijn verscheidene bestanden die door dit commando gelezen en geschreven worden zodat je deze waarden globaal kunt instellen of specifiek voor specifieke repositories.
Het git config commando is in ongeveer elk hoofdstuk van dit boek gebruikt.
In ch01-getting-started.asc hebben we het gebruikt om onze naam, email adres en editor voorkeuren aan te geven voordat we zelfs waren begonnen met Git te gebruiken.
In ch02-git-basics-chapter.asc hebben we laten zien hoe je het kon gebruiken om commando-afkortingen te maken die lange optie-reeksen vervingen zodat je ze niet elke keer hoefde in te typen.
In ch03-git-branching.asc hebben we het gebruikt om --rebase de standaard manier te bepalen voor de aanroep van git pull.
In ch07-git-tools.asc hebben we het gebruikt om een standaard bewaarplaats in te richten voor je HTTP wachtwoorden.
In ch08-customizing-git.asc hebben we laten zien hoe besmeur en opschoon filters op te zetten voor gegevens die Git in en uit gaan.
Tot slot is heel ch08-customizing-git.asc toegewijd aan dit commando.
Het git help commando wordt gebruikt om je alle documentatie over elk commando te laten zien die geleverd wordt met Git.
Hoewel we een grof overzicht van de meer populaire commando’s laten zien in deze appendix, kan je voor een volledige opsomming van alle mogelijke opties en vlaggen voor elk commando altijd git help <commando> aanroepen.
We hebben het git help commando in ch01-getting-started.asc geïntroduceerd, en je laten zien hoe het te gebruiken om meer informatie te verkrijgen over de git shell in ch04-git-on-the-server.asc.
Er zijn twee manieren om een Git repository op te halen. Een manier is om het te kopiëren van een bestaande repository op het netwerk of ergens anders en de andere is om een nieuwe te maken in een bestaande directory.
Om een directory in een nieuwe Git repository te veranderen zodat je kunt beginnen met versiebeheer, kan je simpelweg git init aanroepen.
We hebben dit voor het eerst behandeld in ch02-git-basics-chapter.asc, waar we laten zien hoe een gloednieuwe repository gemaakt wordt om in te werken.
We hebben kort besproken hoe je de standaard branch van ``master'' kunt wijzigen in ch03-git-branching.asc.
We gebruiken dit commando om een lege bare repository te maken voor een server in ch04-git-on-the-server.asc.
Tot slot, behandelen we een aantal details over wat er achter de schermen gebeurt in ch10-git-internals.asc.
Het git clone commando is eigenlijk een soort wrapper om een aantal andere commando’s.
Het maakt een nieuwe directory, gaat daarin en roept git init aan om het een lege Git repository te maken, voegt een remote toe (git remote add) naar de URL die je het door hebt gegeven (standaard origin genaamd), roept een git fetch aan van die remote repository en checkt daarna de laatste commit uit naar je werk directory met git checkout.
Het git clone commando wordt in tientallen plaatsen in het boek gebruikt, maar we zullen een paar interessante plaatsen opnoemen.
Het wordt kort geïntroduceerd en uitgelegd in ch02-git-basics-chapter.asc, waar we een aantal voorbeelden behandelen.
In ch04-git-on-the-server.asc bekijken we het gebruik van de --bare optie om een kopie van een Git repository te maken zonder een werk directory.
In ch07-git-tools.asc gebruiken we het om een gebundelde Git repository te ontbundelen.
Tenslotte, in ch07-git-tools.asc hebben we de --recurse-submodules optie laten zien waarmee het clonen van een repository met submodules iets te vereenvoudigen.
Alhoewel het op vele andere plaatsen in dit boek wordt gebruikt, zijn dit de toepassingen die nogal uniek zijn, of waar het op manieren wordt gebruikt die een beetje afwijkend zijn.
Voor de gewone workflow van het stagen van inhoud en dit committen naar je historie, zijn er maar een paar basis commando’s.
Het git add commando voegt inhoud van de werk directory toe aan de staging area (of `index'') voor de volgende commit.
Als het `git commit commando wordt aangeroepen, kijkt het standaard alleen naar deze staging area, dus git add wordt gebruikt om de samenstelling van de volgende commit precies naar jouw eigen wens te bepalen.
Dit commando is een ongelofelijk belangrijk commando in Git en het wordt tientallen keren genoemd of gebruikt in dit boek. We zullen heel kort een aantal van de meer incourante gebruiken benoemen die kunnen worden gevonden.
We hebben git add voor het eerst geïntroduceerd en in detail uitgelegd in ch02-git-basics-chapter.asc.
We beschrijven hoe we het moeten gebruiken om merge conflicten op te lossen in ch03-git-branching.asc.
We behandelen het gebruik ervan om interactief alleen specifieke delen van een gewijzigd bestand te stagen in ch07-git-tools.asc.
Tot slot spelen we het op een laag niveau na in ch10-git-internals.asc, zodat je een idee krijgt van wat het achter de schermen doet.
Het git status commando laat je de verschillende stadia zien van bestanden in je werk directory en staging area.
Welke bestanden er zijn gewijzigd en nog niet gestaged en welke er zijn gestaged maar nog niet gecommit.
In zijn reguliere vorm, laat het je ook een aantal hints zien over hoe bestanden tussen deze stadia te verplaatsen.
We behandelen status voor het eerst in ch02-git-basics-chapter.asc, zowel in zijn basis en versimpelde vormen.
Alhoewel we het door het hele boek heen gebruiken, wordt vrijwel alles wat je met het git status commando kunt doen daar behandeld.
Het git diff commando wordt gebruikt als je de verschillen wilt zien tussen elke twee trees.
Dit kan het verschil zijn tussen je werk omgeving en je staging area (git diff op zichzelf), tussen je staging area en je laatste commit (git diff --staged), of tussen twee commits (git diff master branchB).
We kijken eerst naar de basis gebruiken van git diff in ch02-git-basics-chapter.asc, waar we laten zien hoe je kunt zien welke wijzigingen er zijn gestaged en welke nog niet.
We gebruiken het om te kijken of er mogelijke witruimte-problemen zijn voor we committen met de --check optie in
ch05-distributed-git.asc.
We zien hoe we de verschillen tussen branches efficiënter kunnen controleren met de git diff A…B syntax in ch05-distributed-git.asc.
We gebruiken het om de witruimte verschillen weg te filteren met -b en hoe de verschillende stadia van conflicterende bestanden te vergelijken met --theirs, --ours en --base in ch07-git-tools.asc.
En tot slot, gebruiken we het om efficiënt submodule wijzigingen te vergelijjken met --submodule in ch07-git-tools.asc.
Het git difftool commando roept simpelweg een externe tool aan om je de verschillen te tonen tussen twee trees in het geval dat je iets anders wilt gebruiken dan het ingebouwde git diff commando.
We vermelden dit slechts kort in ch02-git-basics-chapter.asc.
Het git commit commando neemt alle bestandsinhoud die zijn gestaged met git add en slaat een nieuwe permanente snapshot in de database op en verplaatst erna de branch verwijzer op de huidige branch daar naar toe.
We behandelen eerst de basis van committen in ch02-git-basics-chapter.asc.
Daar laten we ook zien hoe je de -a vlag kunt gebruiken om de git add stap over te slaan in de dagelijkse workflows en hoe je de -m vlag kunt gebruiken om een commit bericht uit de commando regel kunt doorgeven in plaats van een editor te laten opstarten.
In ch02-git-basics-chapter.asc behandelen we het gebruik van de --amend optie om de meest recente commit over te doen.
In ch03-git-branching.asc gaan we met veel meer detail in op wat git commit doet en waarom het doet wat het doet.
We keken naar hoe commits cryptografisch te tekenen met de -S vlag in ch07-git-tools.asc.
Tot slot, nemen we een kijkje naar wat het git commit commando op de achtergrond doet en hoe het echt is geïmplementeerd in ch10-git-internals.asc.
Het git reset commando is voornamelijk gebruikt om zaken terug te draaien, zoals je waarschijnlijk al kunt zien aan het werkwoord.
Het verplaatst de HEAD verwijzing en verandert optioneel de index of staging area en kan optioneel ook de werk directory wijzigen als je --hard gebruikt.
Deze laatste optie maakt het mogelijk met dit commando je werk te verliezen als je het niet juist gebruikt, dus verzeker je ervan dat je alles goed begrijpt voordat je het gebruikt.
We hebben feitelijk het eenvoudigste gebruik van git reset in ch02-git-basics-chapter.asc behandeld, waar we het hebben gebruikt om een bestand te unstagen waar we git add op hadden gebruikt.
We behandelen het daarna in behoorlijk meer detail in ch07-git-tools.asc, die volledig is gewijd aan de uitleg van dit commando.
We gebruiken git reset --hard om een merge af te breken in ch07-git-tools.asc, waar we ook git merge --abort gebruiken, wat een vorm van een wrapper is voor het git reset commando.
Het git rm commando wordt gebruikt om bestanden te verwijderen van de staging area en de werk directory voor Git.
Het lijkt op git add in die zin dat het de verwijdering van een bestand staged voor de volgende commit.
We behandelen het git rm commando in enige detail in ch02-git-basics-chapter.asc, inclusief het recursief verwijderen van bestanden en alleen bestanden verwijderen van de staging area maar ze in de werk directory ongemoeid te laten met --cached.
Het enige andere alternatieve gebruik van git rm in het boek is in ch10-git-internals.asc waar we het even gebruiken en de --ignore-unmatch uitleggen als we git filter-branch aanroepen, wat ervoor zorgt dat we niet met een fout eindigen als het bestand dat we proberen te verwijderen niet bestaat.
Dit kan nuttig zijn bij het maken van scripts.
Het git mv commando is een kleine gemaks-commando om een bestand te verplaatsen en dan git add aan te roepen op het nieuwe bestand en git rm op het oude bestand.
We noemen dit commando heel kort in ch02-git-basics-chapter.asc.
Het git clean commando wordt gebruikt om ongewenste bestanden te verwijderen uit je werk directory.
Dit zou het verwijderen van tijdelijke bouw-artefacten kunnen inhouden of merge conflict bestanden.
We hebben veel van de opties en scenario’s besproken waar je het clean commando zou kunnen gebruiken in ch07-git-tools.asc.
Er zijn maar een handjevol commando’s die de meeste van de branch en merge functionaliteit in Git implementeren.
Het git branch commando is eigenlijk een soort branch beheer gereedschap.
Het kan de branches die je hebt uitlijsten, een nieuwe branch aanmaken, branches verwijderen en hernoemen.
Het grootste gedeelte van ch03-git-branching.asc is gewijd aan het branch commando en het wordt door het gehele hoofdstuk gebruikt.
We introduceren het eerst in ch03-git-branching.asc en we behandelen de meeste van de andere mogelijkheden (uitlijsten en verwijderen) in ch03-git-branching.asc.
In ch03-git-branching.asc gebruiken we de git branch -u optie om een tracking branch op te zetten.
Tot slot, behandelen we een aantal dingen die het op de achtergrond doet in ch10-git-internals.asc.
Het git checkout commando wordt gebruikt om branches te wisselen en inhoud uit te cheken in je werk directory.
We komen het commando voor het eerst tegen in ch03-git-branching.asc samen met de git branch commando.
We zien hoe het te gebruiken om tracking branches te starten met de --track vlag in ch03-git-branching.asc.
We gebruiken het om bestandsconflicten te herintroduceren met --conflict=diff3 in ch07-git-tools.asc.
We behandelen het in nog meer detail in verband met haar relatie met git reset in ch07-git-tools.asc.
Tot slot, behandelen we een aantal implementatie details in ch10-git-internals.asc.
Het git merge tool wordt gebruikt om een of meerdere branches te mergen naar de branch die je hebt uitgechecked.
Het zal daarna de huidige branch voortbewegen naar het resultaat van de merge.
Het git merge commando werd voor het eerst geïntroduceerd in ch03-git-branching.asc.
En hoewel het op diverse plaatsen in het boek wordt gebruikt, zijn er over het algemeen erg weinig variaties op het merge commando, normaalgesproken alleen git merge <branch> met de naam van die ene branch die je wilt inmergen.
We hebben behandeld hoe een squashed merge te doen (waar Git het werk merged maar doet alsof het niet meer dan een nieuwe commit is zonder de historie van de branch die je in merged op te slaan) aan het einde van ch05-distributed-git.asc.
We hebben veel behandeld over het merge proces en commando, inclusief het -Xignore-space-change commando en de --abort vlag om een problematische merge af te breken in ch07-git-tools.asc.
We hebben gezien hoe handtekeningen te verifiëren als je project GPG tekenen gebruikt in ch07-git-tools.asc.
Tot slot, hebben we Subtree mergen behandeld in ch07-git-tools.asc.
Het git mergetool commando roept simpelweg een externe merge hulp aan in het geval dat je problemen hebt met een merge in Git.
We hebben het kort genoemd in ch03-git-branching.asc en behandelen met detail hoe je je eigen externe merge tool kunt implementeren in ch08-customizing-git.asc.
Het git log commando wordt gebruikt om de bereikbare opgeslagen historie van een project te laten zien vanaf de meeste recente commit snapshot en verder terug.
Standaard laat het alleen de historie zien van de branch waar je op dat moment op werkt, maar het kan een andere of zelfs meerdere heads of branches worden gegeven vanwaar het door de geschiedenis zal gaan traceren.
Het wordt ook vaak gebruikt om verschillen te laten zien tussen twee of meer branches op het commit niveau.
Dit commando wordt in vrijwel elk hoofdstuk van het boek gebruikt om de historie van het project te tonen.
We introduceren het commando en behandelen het met nogal wat detail in ch02-git-basics-chapter.asc.
Daar nemen we een kijkje naar de -p en --stat opties om een indruk te krijgen van wat er was geïntroduceerd in elke commit en de --pretty en --oneline opties om de historie meer beknopt te bekijken, samen met wat eenvoudige datum en auteur filter opties.
In ch03-git-branching.asc gebruiken we het met de --decorate optie om eenvoudig te laten zien waar onze branch verwijzingen zijn en we gebruiken ook de --graph optie om te zien hoe uiteenlopende histories eruit zien.
In ch05-distributed-git.asc en ch07-git-tools.asc behandelen we hoe de branchA..branchB syntax toe te passen om het git log commando te gebruiken om te bekijken welke commits er uniek zijn voor een branch in vergelijking met een andere branch.
In ch07-git-tools.asc behandelen we dit redelijk uitgebreid.
In ch07-git-tools.asc en ch07-git-tools.asc behandelen we het gebruik van het branchA…branchB formaat en de --left-right syntax om te zien wat er in een branch zit of de andere, maar niet in beide.
In ch07-git-tools.asc kijken we ook naar hoe de --merge optie te gebruiken als hulp om een merge conflict te debuggen en ook het gebruik van de --cc optie om naar merge conflicten te kijken in je historie.
In ch07-git-tools.asc gebruiken we de -g optie om de Git reflog te bekijken via dit gereedschap in plaats van branch navigatie te doen.
In ch07-git-tools.asc kijken we naar het gebruik van de -S en -L opties om een redelijk geraffineerde zoekopdrachten uit te voeren naar iets dat historisch heeft plaatsgevonden in de code, zoals het bekijken van de geschiedenis van een functie.
In ch07-git-tools.asc zien we hoe --show-signature te gebruiken om een validatie tekenreeks toe te voegen aan elke commit in de git log uitvoer afhankelijk van of het valide is getekend of niet.
Het git stash commando wordt gebruikt om tijdelijk niet-gecommit werk op te slaan, zodat je werk directory opgeschoond wordt; hierdoor hoef je geen onvolledig werk te committen naar een branch.
Dit wordt eigenlijk in zijn geheel behandeld in ch07-git-tools.asc.
Het git tag commando wordt gebruikt om een blijvende boekwijzer te geven aan een specifiek punt in de code historie.
Over het algemeen wordt dit gebruikt voor zaken zoals releases.
Dit commando wordt geïntroduceerd en in detail behandeld in ch02-git-basics-chapter.asc en we gebruiken het in de praktijk in ch05-distributed-git.asc.
We behandelen ook hoe een GPG getekende tag te maken met de -s vlag en verifiëren er een met de -v vlag in ch07-git-tools.asc.
Er zijn niet veel commando’s in Git die het netwerk benaderen, bijna alle commando’s werken op de lokale database. Als je er klaar voor bent om je werk te delen of wijzigingen binnen te halen (pull) van elders, zijn er een handjevol commando’s die te maken hebben met remote repositories.
Het git fetch commando communiceert met een remote repository en haalt alle informatie binnen die in die repository zit die nog niet in je huidige zit en bewaart dit in je lokale database.
We nemen voor het eerst een kijkje naar dit commando in ch02-git-basics-chapter.asc en we vervolgen met het kijken naar voorbeelden van het gebruik in ch03-git-branching.asc.
We gebruiken het ook in diverse voorbeelden in ch05-distributed-git.asc.
We gebruiken het om een enkele specifieke refentie op te halen die buiten de standaard ruimte is in ch06-github.asc en we zien hoe we iets uit een bundel kunnen halen in ch07-git-tools.asc.
We richten een aantal zeer eigen refspecs in om git fetch iets op een net andere manier te laten doen dan standaard in ch10-git-internals.asc.
Het git pull commando is feitelijk een combinatie van de git fetch en git merge commando’s, waar Git van de remote die je opgeeft gaat ophalen en daarna direct probeert het opgehaalde te mergen in de branch waar je op dat moment op zit.
We stellen je het kort voor in ch02-git-basics-chapter.asc en laten zien hoe je kunt bekijken wat het zal gaan mergen als je het aanroept in ch02-git-basics-chapter.asc.
We laten ook zien hoe het te gebruiken als hulp met bij problemen met rebasen in ch03-git-branching.asc.
We laten zien hoe het te gebruiken met een URL om wijzigingen op een eenmalige manier te pullen in ch05-distributed-git.asc.
Tot slot, vermelden we heel snel dat je de --verify-signature optie kunt gebruiken om te verifiëren dat commits die je binnenhaalt met GPG getekend zijn in ch07-git-tools.asc.
Het git push commando wordt gebruikt om te communiceren met een andere repository, berekenen wat je lokale database heeft en de remote niet, en daarna de verschillen te pushen naar de andere repository.
Het vereist wel dat je schrijfrechten hebt op de andere repository en normaalgesproken is dit dus op de een of andere manier geautenticeerd.
We nemen een eerste kijkje naar het git push commando in ch02-git-basics-chapter.asc.
Hier behandelen we de basisprincipes van het pushen van een branch naar een remote repository.
In ch03-git-branching.asc gaan we iets dieper in op het pushen van specifieke branches en in ch03-git-branching.asc zien we hoe tracking branches worden opgezet om automatisch naar te pushen.
In ch03-git-branching.asc gebruiken we de --delete vlag om een branch te verwijderen op de server met git push.
Door heel ch05-distributed-git.asc heen zien we een aantal voorbeelden van het gebruik van git push om werk op branches te delen middels meerdere remotes.
We zien hoe we het gebruiken om tags te delen die je gemaakt hebt met de --tags optie in ch02-git-basics-chapter.asc.
In ch07-git-tools.asc gebruiken we de --recurse-submodules optie om te controleren dat al onze submodule werk is gepubliceerd voordat we het superproject pushen, wat zeer behulpzaam kan zijn als je submodules gebruikt.
In ch08-customizing-git.asc bespreken we kort de pre-push hook, wat een script is die we kunnen opzetten om te draaien voordat een push voltooid is, om te verifiëren dat pushen hiervan toegestaan is.
Tot slot, in ch10-git-internals.asc kijken we naar pushen met een volledige refspect in plaats van de generieke afkortingen die we normaalgesproken gebruiken. Dit kan je helpen om heel specifiek te zijn over welk werk je wilt delen.
Het git remote commando is een beheertool voor jouw administratie van remote repositories.
Het stelt je in staat om lange URLs op te slaan als afkortingen, zoals `origin'' zodat je ze niet elke keer helemaal hoeft in te typen.
Je kunt er een aantal van hebben en het `git remote commando wordt gebruikt om ze toe te voegen, te wijzigen en te verwijderen.
Dit commando wordt in detail behandeld ch02-git-basics-chapter.asc, inclusief het uitlijsten, toevoegen, verwijderen en het hernoemen.
Het wordt daarnaast in bijna elk daaropvolgend hoofdstuk van het boek gebruikt, maar altijd in de standaard git remote add <naam> <url> formaat.
Het git archive commando wordt gebruikt om een archiefbestand te maken van een specifieke snapshot van het project.
We gebruiken git archive om een tarball te maken van een project om het te delen in ch05-distributed-git.asc.
Het git submodule commando wordt gebruikt om externe repositories te beheren binnen normale repositories.
Dit kan zijn voor libraries of andere tyepen gedeelde hulpmiddelen.
Het submodule commando heeft een aantal sub-commando’s (add, update, sync, etc) om deze hulpmiddelen te beheren.
Dit commando wordt alleen benoemd en in zijn volledigheid behandeld in ch07-git-tools.asc.
Het git show commando kan een Git object in een eenvoudige en voor een mens leesbare manier laten zien.
Normaalgesproken gebruik je dit om de informatie over een tag of een commit te laten zien.
We gebruiken het eerst om informatie van een geannoteeerde tag te laten zien in ch02-git-basics-chapter.asc.
Later gebruiken we het redelijk vaak in ch07-git-tools.asc om de commits te tonen waar verscheidene van onze revisie selecties naar toe worden vertaald.
Een van de meer interessante dingen die we met git show doen is in ch07-git-tools.asc waar we specifieke bestandsinhoud ophalen uit verschillende stadia gedurende een merge conflict.
Het git shortlog commando wordt gebruikt om de uitvoer van git log samen te vatten.
Het accepteert veel van dezelfde opties als het git log commando maar zal, in plaats van alle commits uit te lijsten, een samenvatting presenteren van de commits gegroepeerd per auteur.
We hebben laten zien hoe het te gebruiken om een mooie changelog te maken in ch05-distributed-git.asc.
Het git describe commando wordt gebruikt om alles te pakken wat naar een commit kan leiden en produceert een tekenreeks die redelijk mens leesbaar is en niet zal veranderen.
Het is een manier om een omschrijving van een commit te krijgen die net zo eenduidig is als een SHA-1, maar meer begrijpelijk.
We gebruiken git describe in ch05-distributed-git.asc en ch05-distributed-git.asc om een tekenreeks te verkrijgen om onze release bestand naar te vernoemen.
Git heeft een aantal commando’s die als hulp worden gebruikt bij het debuggen van een probleem in je code. Dit varieert van uitknobbelen waar iets is geïntroduceert tot wie het heeft geïntroduceerd.
Het git bisect gereedschap is een ongelofelijk behulpzaam debugging tool die gebruikt wordt om uit te vinden welke specifieke commit de eerste was om een bug of probleem te bevatten door middel van een automatische binaire zoekactie.
Het wordt volledig behandeld in ch07-git-tools.asc en wordt alleen in dat gedeelte genoemd.
Het git blame commando markeert de regels van elk bestand met welke commit de laatste was die een wijziging invoerde bij elke regel in het bestand en welke persoon de auteur was van die commit.
Dit is handig bij het uitzoeken van de persoon zodat er meer informatie kan worden gevraagd over een specifiek gedeelte van je code.
Dit wordt behandeld in ch07-git-tools.asc en wordt alleen in dat gedeelte genoemd.
Het git grep commando kan je helpen elke willekeurige tekenreeks of regular expressie te vinden in elk bestand in je broncode, zelfs oudere versies van je project.
Het wordt behandeld in ch07-git-tools.asc en wordt alleen in dat gedeelte genoemd.
Een aantal commando’s in Git draaien om het concept van het zien van commits in termen van de wijzigingen die ze introduceren, alsof de commit reeks een reeks van patches is. Deze commando’s helpen je je branches op deze manier te beheren.
Het git cherry-pick commando wordt gebruikt om de wijziging die in een enkele Git commit zit te pakken en deze te herintroduceren als een nieuwe commit op de branch waar je op dat moment op zit.
Dit kan behulpzaam zijn bij het selectief een of twee commits te nemen van een branch in plaats van de hele branch in te mergen, waarbij alle wijzigingen worden genomen.
Cherry picking wordt beschreven en gedemonstreerd in ch05-distributed-git.asc.
Het git rebase commando is eigenlijk een geautomatiseerde cherry-pick.
Het bepaalt een reeks van commits en gaat deze dan een voor een in dezelfde volgorde elders cherry-picken.
Rebasen wordt in detail behandeld in ch03-git-branching.asc, inclusief het behandelen van de samenwerkings-problematiek waar je mee te maken krijgt als je al publieke branches gaat rebasen.
We gebruiken het in de praktijk tijdens een voorbeeld van het splitsen van je historie in twee aparte repositories in ch07-git-tools.asc, waarbij we ook de --onto vlag gebruiken.
We behandelen het in een merge conflict geraken tijdens rebasen in ch07-git-tools.asc.
We gebruiken het ook in een interactieve script modus met de -i optie in ch07-git-tools.asc.
Het git revert commando is feitelijk een omgekeerde git cherry-pick.
Het maakt een nieuwe commit die de exacte tegenhanger van de wijziging die in de commit zit die je aanwijst toepast, en deze effectief ontdoet of terugdraait.
We gebruiken het in ch07-git-tools.asc om een merge commit terug te draaien.
Veel Git projecten, inclusief Git zelf, worden volledig onderhouden via mail-lijsten. Git heeft een aantal gereedschappen ingebouwd gekregen die helpen dit proces eenvoudiger te maken, van het genereren van patches die je eenvoudig kunt mailen tot het toepassen van deze patches vanuit een email-box.
Het git apply commando past een patch toe die met het git diff of zelfs met het GNU diff commando is gemaakt.
Dit is vergelijkbaar met wat het patch commando zou kunnen doen met een paar kleine verschillen.
We laten het gebruik zien en de omstandigheden waarin je het zou kunnen toepassen in ch05-distributed-git.asc.
Het git am commando wordt gebruikt om patches toe te passen vanuit een email inbox, en specifiek een die volgens mbox is geformatteerd.
Dit is handig voor het ontvangen van patches via email en deze eenvoudig op je project toe te passen.
We hebben de workflow en gebruik rond git am behandeld in ch05-distributed-git.asc inclusief het gebruik van de --resolved, -i en -3 opties.
Er zijn ook een aantal hooks die je kunt gebruiken als hulp in de workflow rond git am en ze worden allemaal behandeld in ch08-customizing-git.asc.
We hebben het ook gebruikt om GitHub Pull Request wijzigingen die als patch zijn geformatteerd toe te passen in ch06-github.asc.
Het git format-patch commando wordt gebruikt om een reeks van patches te generen in mbox formaat die je kunt gebruiken om ze correct geformatteerd naar een mail lijst te sturen.
We behandelen een voorbeeld van een bijdrage leveren aan een project met gebruik van het git format-patch tool in ch05-distributed-git.asc.
Het git imap-send commando zendt een mailbox gegenereerd met git format-patch naar een IMAP drafts folder.
We behandelen een voorbeeld van het bijdragen aan een project door het sturen van patches met de git imap-send tool in ch05-distributed-git.asc.
Het git send-email commando wordt gebruikt om patches via email te sturen die zijn gegenereerd met git format-patch.
We behandelen een voorbeeld van het bijdragen aan een project door het sturen van patches met het git send-email tool in ch05-distributed-git.asc.
Het git request-pull commando wordt eenvoudigweg gebruikt om een voorbeeld bericht te genereren om naar iemand te mailen.
Als je een branch hebt op een publieke server en iemand wilt laten weten hoe deze wijzigingen kunnen worden geïntegreerd zonder de patches via email te versturen, kan je dit commando aanroepen en de uitvoer sturen naar de persoon die je de wijzigingen wilt laten pullen.
We laten het gebruik van git request-pull om een pull message te laten genereren in ch05-distributed-git.asc.
Git wordt geleverd met een aantal commando’s om te integreren met andere versiebeheer systemen.
Het git svn commando wordt gebruikt om als client te communiceren met het Subversion versiebeheer systeem.
Dit houdt in dat je Git kunt gebruiken om checkouts en commits te doen naar en van een Subversion server.
Dit commando wordt gedetailleerd behandeld in ch09-git-and-other-systems.asc.
Voor andere versiebeheer systemen of het impoteren van bijna elk formaat, kan je git fast-import gebruiken om snel het andere formaat te mappen op iets wat Git eenvoudig kan vastleggen.
Dit commando wordt gedetailleerd behandeld in ch09-git-and-other-systems.asc.
Als je een Git repository beheert of iets ingrijpend moet repareren, geeft Git je een aantal beheer commando’s om je hierbij te helpen.
Het git gc commando roept vuilnis ophalen'' (garbage collection'') aan op je repository, waarbij onnodige bestanden in je database worden verwijderd en de overgebleven bestanden op een meer efficiënte manier worden opgeslagen.
Dit commando wordt normaalgesproken op de achtergrond voor jou aangeroepen, maar je kunt het handmatig aanroepen als je dat wilt. We behandelen een paar voorbeelden in ch10-git-internals.asc.
Het git fsck commando wordt gebruikt om de interne database te controleren op problemen of inconsistenties.
We gebruiken het slechts een keer heel kort in ch10-git-internals.asc om te zoeken naar loshangende (dangling) objecten.
Het git reflog commando neemt een log door waar in staat waar alle heads van al je branches hebben gestaan als je op zoek bent naar commits die je misschien bent verloren bij het herschrijven van histories.
We behandelen dit commando voornamelijk in ch07-git-tools.asc, waar we het normale gebruik laten zien en hoe git log -g te gebruiken om dezelfde informatie te laten zien als in de git log uitvoer.
We behandelen ook een praktisch voorbeeld van het herstellen van zo’n verloren branch in ch10-git-internals.asc.
Het git filter-branch commando wordt gebruikt om grote hoeveelheden commits te herschrijven volgens een bepaald patroon, zoals het overal verwijderen van een bestand of een hele repository terug te brengen tot een enkele subdirectory voor het extraheren van een project.
In ch07-git-tools.asc leggen we het commando uit en verkennen een aantal verschillende opties zoals --commit-filter, --subdirectory-filter en --tree-filter.
In ch09-git-and-other-systems.asc en ch09-git-and-other-systems.asc gebruiken we dit om geïmporteerde externe repositories te op te schonen.
Er zijn ook nog een behoorlijk aantal meer technische binnenwerk commando’s die we zijn tegengekomen in het boek.
De eerste die we tegenkomen is ls-remote in ch06-github.asc waar we het gebruiken om te kijken naar de kale referenties op de server.
We gebruiken ls-files in ch07-git-tools.asc, ch07-git-tools.asc en ch07-git-tools.asc om een meer technische kijk te nemen op hoe je staging gebied er eigenlijk uitziet.
We gebruiken rev-parse in ch07-git-tools.asc om zo ongeveer elke tekenreeks te nemen en het in een object SHA-1 te veranderen.
Echter, de meeste van de technische binnenwerk commando’s die we behandelen staan in ch10-git-internals.asc, wat meteen het belangrijkste onderwerp is waar dit hoofdstuk zich op richt. We hebben geprobeerd het gebruik van deze commando’s in de rest van het boek te vermijden.