2.2 Git Basics - Wijzigingen aan de repository vastleggen

Het commando dat je voornamelijk zult gebruiken om te bepalen welk bestand zich in welke status bevindt is git status. Als je dit commando direct na het clonen uitvoert, dan zal je zoiets als het volgende zien:

Dit betekent dat je een schone werkdirectory hebt; met andere woorden er zijn geen tracked bestanden die gewijzigd zijn. Git ziet ook geen untracked bestanden, anders zouden ze hier getoond worden. Als laatste vertelt het commando op welke tak (branch) je nu zit en informeert je dat het niet is afgeweken van dezelfde branch op de server. Voor nu is deze branch altijd “master”, dat is de standaard; besteed daar voor nu nog geen aandacht aan. In Branchen in Git wordt gedetaileerd ingegaan op branches en referenties.

Stel dat je een nieuw bestand toevoegt aan je project, een simpel README bestand. Als het bestand voorheen nog niet bestond, en je doet git status, dan zul je het niet getrackte bestand op deze manier zien:

Je kunt zien dat het nieuwe README bestand untracked is, omdat het onder de “Untracked files” kop staat in je status uitvoer. Untracked betekent eigenlijk dat Git een bestand ziet dat je niet in de vorige snapshot (commit) had; Git zal het niet aan je commit snapshots toevoegen totdat jij dit expliciet aangeeft. De reden hiervoor is dat je niet per ongeluk gegenereerde binaire bestanden toevoegt, of andere bestanden die je niet had willen toevoegen. Je wilt dit README bestand in het vervolg wel meenemen, dus laten we het gaan tracken.

Om een nieuw bestand te beginnen te tracken, gebruik je het commando git add. Om de README te tracken, voer je dit uit:

Als je het status commando nogmaals uitvoert, zie je dat je README bestand nu tracked en staged is voor committen:

Je kunt zien dat het gestaged is, omdat het onder de kop “Changes to be committed” staat. Als je nu een commit doet, zal de versie van het bestand zoals het was ten tijde van je git add commando in het volgende historische snapshot toegevoegd worden. Je zult je misschien herinneren dat, toen je git init eerder uitvoerde, je daarna git add (bestanden) uitvoerde; dat was om bestanden in je directory te beginnen te tracken. Het git add commando beschouwt een padnaam als een bestand of een directory. Als de padnaam een directory is, dan voegt het commando alle bestanden in die directory recursief toe.

Laten we een getrackte bestand wijzigen. Als je een reeds getrackt bestand genaamd CONTRIBUTING.md wijzigt, en dan het git status commando nog eens uitvoert, krijg je iets dat er zo uitziet:

Het "CONTRIBUTING.md" bestand verschijnt onder een sectie genaamd “Changes not staged for commit”, wat inhoudt dat een bestand dat wordt getrackt is gewijzigd in de werkdirectory, maar nog niet is gestaged. Om het te stagen, voer je het git add commando uit. git add is een veelzijdig commando: je gebruikt het om nieuwe bestanden te laten tracken, om bestanden te stagen, en om andere dingen zoals een bestand met een mergeconflict als opgelost te markeren. Het kan behulpzaam zijn om het commando te zien als “voeg deze inhoud toe aan de volgende commit” in plaats van “voeg dit bestand toe aan het project”. Laten we nu git add uitvoeren om het CONTRIBUTING.md bestand te stagen, en dan nog eens git status uitvoeren:

Beide bestanden zijn gestaged en zullen met je volgende commit meegaan. Stel nu dat je je herinnert dat je nog een kleine wijziging in CONTRIBUTING.md wilt maken voordat je het commit. Je opent het opnieuw en maakt die wijziging, en dan ben je klaar voor de commit. Alhoewel, laten we git status nog een keer uitvoeren:

Wat krijgen we nu? Nu staat CONTRIBUTING.md bij de staged en unstaged genoemd. Hoe is dat mogelijk? Het blijkt dat Git een bestand precies zoals het is staged wanneer je het git add commando uitvoert. Als je nu commit, dan zal de versie van CONTRIBUTING.md zoals het was toen je voor 't laatst git add uitvoerde worden toegevoegd in de commit, en niet de versie van het bestand zoals het eruit ziet in je werkdirectory toen je git commit uitvoerde. Als je een bestand wijzigt nadat je git add uitvoert, dan moet je git add nogmaals uitvoeren om de laatste versie van het bestand te stagen:

Alhoewel de git status uitvoer redelijk uitgebreid is, is het ook nogal breedsprakig. Git heeft ook een vlag voor een korte status, zodat je je wijzigingen in een meer compact overzicht ziet. Als je git status -s of git status --short typt krijg je een veel simpelere uitvoer van het commando.

Nieuwe bestanden die nog niet worden getrackt hebben een ?? naast zich, nieuwe bestanden die aan de staging area zijn toegevoegd hebben een A, gewijzigde bestanden een M enzovoort. Er zijn twee kolommen in de uitvoer: de linker kolom geeft de status van de staging area weer en de rechter kolom de status van je werk directory. Als voorbeeld in de uitvoer is het README bestand gewijzigd in de werk directory maar nog niet gestaged, terwijl het lib/simplegit.rb bestand gewijzigd en gestaged is. Rakefile is gewijzigd, gestaged en weer gewijzigd, dus er zijn daar wijzigingen die zowel gestaged als ongestaged zijn.

Vaak zul je een klasse bestanden hebben waarvan je niet wilt dat Git deze automatisch toevoegt of zelfs maar als untracked toont. Dit zijn doorgaans automatisch gegenereerde bestanden zoals logbestanden of bestanden die geproduceerd worden door je bouwsysteem. In die gevallen kun je een bestand genaamd .gitignore maken, waarin patronen staan die die bestanden passen. Hier is een voorbeeld van een .gitignore bestand:

De eerste regel vertelt Git om ieder bestand te negeren waarvan de naam eindigt op een “.o” of “.a” (object en archief bestanden die het product kunnen zijn van het bouwen van je code). De tweede regel vertelt Git dat ze alle bestanden moet negeren die eindigen op een tilde (~), wat gebruikt wordt door editors zoals Emacs om tijdelijke bestanden aan te geven. Je kunt ook log, tmp of een pid directory toevoegen, automatisch gegenereerde documentatie, enzovoort. Een .gitignore bestand aanmaken voordat je gaat beginnen is over het algemeen een goed idee, zodat je niet per ongeluk bestanden commit die je echt niet in je Git repository wilt hebben.

De regels voor patronen die je in het .gitignore bestand kunt zetten zijn als volgt:

Expansie (glob) patronen zijn vereenvoudigde reguliere expressies die in shell-omgevingen gebruikt worden. Een asterisk (*) komt overeen met nul of meer karakters, [abc] komt overeen met ieder karakter dat tussen de blokhaken staat (in dit geval a, b of c), een vraagteken (?) komt overeen met een enkel karakter en blokhaken waartussen karakters staan die gescheiden zijn door een streepje ([0-9]) komen overeen met ieder karakter dat tussen die karakters zit (in dit geval 0 tot en met 9). Je kunt ook twee asterisken gebruiken om geneste directories aan te geven: a/**/z komt overeen met a/z, a/b/z, a/b/c/z en zo verder.

Hier is nog een voorbeeld van een .gitignore bestand:

Als het git status commando te vaag is voor je - je wilt precies weten wat je veranderd hebt en niet alleen welke bestanden veranderd zijn - dan kan je het git diff commando gebruiken. We zullen git diff later in meer detail bespreken, maar je zult dit commando het meest gebruiken om deze twee vragen te beantwoorden: Wat heb je veranderd maar nog niet gestaged? En wat heb je gestaged en sta je op het punt te committen? Waar git status deze vragen heel algemeen beantwoordt door de bestandsnamen te tonen, laat git diff je de exacte toegevoegde en verwijderde regels zien, de patch, als het ware.

Stel dat je het README bestand opnieuw verandert en staget, en dan het CONTRIBUTING.md bestand verandert zonder het te stagen. Als je het git status commando uitvoert, dan zie je nogmaals zoiets als dit:

Om te zien wat je gewijzigd maar nog niet gestaged hebt, type je git diff in zonder verdere argumenten:

Dat commando vergelijkt wat er in je werkdirectory zit met wat er in je staging area zit. Het resultaat laat je zien welke wijzigingen je gedaan hebt, die je nog niet gestaged hebt.

Als je wilt zien wat je gestaged hebt en in je volgende commit zal zitten, dan kun je git diff --staged gebruiken. Dit commando vergelijkt je gestagede wijzigingen met je laatste commit:

Het is belangrijk om op te merken dat git diff zelf niet alle wijzigingen sinds je laatste commit laat zien, alleen wijzigingen die nog niet gestaged zijn. Als je al je wijzigingen gestaged hebt, zal git diff geen uitvoer geven.

Nog een voorbeeld. Als je het CONTRIBUTING.md bestand staget en vervolgens verandert, dan kun je git diff gebruiken om de wijzigingen in het bestand te zien dat gestaged is en de wijzigingen die niet gestaged zijn. Stel onze omgeving ziet er zo uit:

Nu kun je git diff gebruiken om te zien wat nog niet gestaged is:

en git diff --cached om te zien wat je tot nog toe gestaged hebt (--staged en --cached zijn synoniem):

Nu je staging area gevuld is zoals jij het wilt, kun je de wijzigingen committen. Onthoud dat alles wat niet gestaged is, dus elk bestand dat je gemaakt of gewijzigd hebt en waarop je nog geen git add uitgevoerd hebt, niet in deze commit mee zal gaan. Ze zullen als gewijzigde bestanden op je schijf blijven staan. Stel in dit geval dat, toen je de laatste keer git status uitvoerde, je zag dat alles gestaged was. Dus je bent er klaar voor om je wijzigingen te committen. De makkelijkste manier om te committen is om git commit in te typen:

Dit start de door jou gekozen editor op. (Dit wordt bepaald door de EDITOR omgevingsvariabele in je shell, meestal vim of emacs, alhoewel je kunt instellen op welke editor je wilt gebruiken met het git config --global core.editor commando zoals je hier Aan de slag gezien hebt).

De editor laat de volgende tekst zien (dit voorbeeld is een Vim scherm):

Je kunt zien dat de standaard commit boodschap de laatste output van het git status commando als commentaar bevat en een lege regel bovenaan. Je kunt deze commentaren verwijderen en je eigen commit boodschap intypen, of je kunt ze laten staan om je eraan te helpen herinneren wat je aan het committen bent. (Om een meer expliciete herinnering van je wijzigingen te zien kun je de -v optie meegeven aan git commit. Als je dit doet zet Git de diff van je veranderingen in je editor zodat je precies kunt zien welke wijzingen je gaat committen.) Als je de editor verlaat, creëert Git je commit boodschap (zonder de commentaren of de diff).

Als alternatief kun je de commit boodschap met het commit commando meegeven door hem achter de -m vlag te specificeren, zoals hier:

Nu heb je je eerste commit gemaakt! Je kunt zien dat de commit je wat uitvoer over zichzelf heeft gegeven: op welke branch je gecommit hebt (master), welke SHA-1 checksum de commit heeft (463dc4f), hoeveel bestanden er veranderd zijn, en statistieken over toegevoegde en verwijderde regels in de commit.

Onthoud dat commit de snapshot, die je in je staging area hebt gezet, opslaat. Alles wat je niet gestaged hebt staat nog steeds gewijzigd; je kunt een volgende commit doen om het aan je geschiedenis toe te voegen. Elke keer dat je een commit doet, leg je een snapshot van je project vast waarnaar je later terug kunt draaien of waarmee je kunt vergelijken.

Alhoewel het ontzettend nuttig kan zijn om commits precies zoals je wilt te maken, is de staging area soms iets ingewikkelder dan je in je workflow nodig hebt. Als je de staging area wilt overslaan, dan kan je met Git makkelijk de route inkorten. Door de -a optie aan het git commit commando mee te geven zal Git automatisch ieder bestand dat al getrackt wordt voor de commit stagen, zodat je het git add gedeelte kunt overslaan:

Merk op dat je nu geen git add op het “CONTRIBUTING.md” bestand hoeft te doen voordat je commit. Dat is omdat de -a vlag alle gewijzigde bestanden insluit. Dat is handig, maar wees voorzichtig; soms zal deze vlag veroorzaken dat je wijzigingen meeneemt die je eigenlijk niet had gewild.

Om een bestand uit Git te verwijderen, moet je het van de getrackte bestanden verwijderen (of om precies te zijn: verwijderen van je staging area) en dan een commit doen. Het git rm commando doet dat, en verwijdert het bestand ook van je werk directory zodat je het de volgende keer niet als een untracked bestand ziet.

Als je het bestand simpelweg verwijdert uit je werk directory, zal het te zien zijn onder het “Changes not staged for commit” - (dat wil zeggen, unstaged) gedeelte van je git status uitvoer:

Als je daarna git rm uitvoert, zal de verwijdering van het bestand gestaged worden:

Als je de volgende keer een commit doet, zal het bestand verdwenen zijn en niet meer getrackt worden. Als je het bestand veranderd hebt of al aan de staging area hebt toegevoegd, dan zul je de verwijdering moeten forceren met de -f optie. Dit is een veiligheidsmaatregel om te voorkomen dat je per ongeluk data die nog niet in een snapshot zit, en dus niet teruggehaald kan worden uit Git, weggooit.

Een ander handigheidje dat je misschien wilt gebruiken is het bestand in je werkdirectory houden, maar van je staging area verwijderen. Met andere woorden, je wilt het bestand misschien op je harde schijf bewaren, maar niet dat Git het bestand nog trackt. Dit is erg handig als je iets vergeten bent aan je .gitignore bestand toe te voegen, en het per ongeluk gestaged hebt, zoals een groot logbestand, of een serie .a gecompileerde bestanden. Gebruik de --cached optie om dit te doen:

Je kunt bestanden, directories en bestandspatronen aan het git rm commando meegeven. Dat betekent dat je zoiets als dit kunt doen:

Let op de backslash (\) voor de *. Dit is nodig omdat Git zijn eigen bestandsnaam-expansie doet, naast die van je shell. Dit commando verwijdert alle bestanden die de .log extensie hebben in de log/ directory. Of, je kunt zoiets als dit doen:

Dit commando verwijdert alle bestanden die eindigen met ~.

Anders dan vele andere VCS systemen, traceert Git niet expliciet verplaatsingen van bestanden. Als je een bestand een nieuwe naam geeft in Git, is er geen metadata opgeslagen in Git die vertelt dat je het bestand hernoemd hebt. Maar Git is slim genoeg om dit alsnog te zien, we zullen bestandsverplaatsing-detectie wat later behandelen.

Het is daarom een beetje verwarrend dat Git een mv commando heeft. Als je een bestand wilt hernoemen in Git, kun je zoiets als dit doen

en dat werkt prima. Sterker nog, als je zoiets als dit uitvoert en naar de status kijkt, zul je zien dat Git het als een hernoemd bestand beschouwt:

Maar dat is gelijk aan het uitvoeren van het volgende:

Git komt er impliciet achter dat het om een hernoemd bestand gaat, dus het maakt niet uit of je een bestand op deze manier hernoemt of met het mv commando. Het enige echte verschil is dat het mv commando slechts één commando is in plaats van drie - het is een gemaksfunctie. Belangrijker nog is dat je iedere applicatie kunt gebruiken om een bestand te hernoemen, en de add/rm later kunt afhandelen voordat je commit.