2.2 Git Basics - Veranderinge aan die repository vaslê

Die hoofhulpmiddel wat jy gebruik om te bepaal watter lêers in watter toestand is, is die git status opdrag. As jy hierdie opdrag direk na 'n kloon uitvoer, behoort jy iets soos die volgende te sien:

Dit beteken jy het 'n skoon werkdirectory; met ander woorde, daar is geen tracked lêers wat gewysig is nie. Git sien ook geen untracked lêers nie, anders sou hulle hier gelys word. Ten slotte vertel die opdrag jou op watter tak (branch) jy is en lig jou in dat dit nie afgewyk het van dieselfde tak op die bediener nie. Vir eers is daardie tak altyd master, wat die verstek is; jy hoef jou nog nie daaroor te bekommer nie. Git Branching sal takke en verwysings in detail behandel.

Kom ons sê jy voeg 'n nuwe lêer by jou projek, 'n eenvoudige README lêer. As die lêer voorheen nog nie bestaan het nie, en jy voer git status uit, sal jy jou untracked lêer soos volg sien:

Jy kan sien dat jou nuwe README lêer untracked is, omdat dit onder die “Untracked files” opskrif in jou status uitvoer staan. Untracked beteken basies dat Git 'n lêer sien wat jy nie in die vorige snapshot (commit) gehad het nie, en wat nog nie gestaged is nie; Git sal dit nie in jou commit snapshots begin insluit totdat jy dit uitdruklik aansê om dit te doen nie. Dit doen dit sodat jy nie per ongeluk gegenereerde binêre lêers of ander lêers insluit wat jy nie bedoel het om in te sluit nie. Jy wil wel die README insluit, so kom ons begin die lêer track.

Om 'n nuwe lêer te begin track, gebruik jy die git add opdrag. Om die README lêer te begin track, kan jy dit uitvoer:

As jy jou status opdrag weer uitvoer, kan jy sien dat jou README lêer nou tracked en staged is om gecommit te word:

Jy kan sien dat dit gestaged is omdat dit onder die “Changes to be committed” opskrif gelys is. As jy op hierdie punt commit, sal die weergawe van die lêer op die tydstip wat jy git add uitgevoer het, in die daaropvolgende historiese snapshot bygevoeg word. Jy onthou dalk dat toe jy vroeër git init uitgevoer het, jy daarna git add <files> uitgevoer het — dit was om lêers in jou directory te begin track. Die git add opdrag neem 'n padnaam in vir óf 'n lêer óf 'n directory; as dit 'n directory is, voeg die opdrag al die lêers in daardie directory rekursief by.

Kom ons verander 'n lêer wat reeds tracked was. As jy 'n voorheen tracked lêer genaamd CONTRIBUTING.md wysig en dan weer jou git status opdrag uitvoer, kry jy iets wat so lyk:

Die CONTRIBUTING.md lêer verskyn onder 'n afdeling genaamd “Changes not staged for commit” — wat beteken dat 'n lêer wat tracked is, in die werkdirectory gewysig is maar nog nie gestaged is nie. Om dit te stage, voer jy die git add opdrag uit. git add is 'n veeldoelige opdrag — jy gebruik dit om nuwe lêers te begin track, om lêers te stage, en om ander dinge te doen soos om lêers met 'n merge-konflik as opgelos te merk. Dit mag help om daaraan te dink as “voeg presies hierdie inhoud by die volgende commit” eerder as “voeg hierdie lêer by die projek”. Kom ons voer nou git add uit om die CONTRIBUTING.md lêer te stage, en voer dan weer git status uit:

Beide lêers is gestaged en sal in jou volgende commit ingaan. Op hierdie stadium onthou jy dalk nog een klein verandering wat jy wil maak in CONTRIBUTING.md voordat jy dit commit. Jy maak dit weer oop en maak daardie verandering, en jy is gereed om te commit. Kom ons voer egter git status nog een keer uit:

Wat gaan hier aan? Nou word CONTRIBUTING.md as beide gestaged en unstaged gelys. Hoe is dit moontlik? Dit blyk dat Git 'n lêer stage presies soos dit is wanneer jy die git add opdrag uitvoer. As jy nou commit, sal die weergawe van CONTRIBUTING.md soos dit was toe jy laas die git add opdrag uitgevoer het in die commit beland, nie die weergawe van die lêer soos dit in jou werkdirectory lyk wanneer jy git commit uitvoer nie. As jy 'n lêer wysig nadat jy git add uitgevoer het, moet jy weer git add uitvoer om die nuutste weergawe van die lêer te stage:

Terwyl die git status uitvoer redelik omvattend is, is dit ook nogal woordryk. Git het ook 'n kort status vlag sodat jy jou veranderinge op 'n meer kompakte manier kan sien. As jy git status -s of git status --short uitvoer, kry jy 'n baie eenvoudiger uitvoer van die opdrag:

Nuwe lêers wat nie tracked is nie het 'n ?? langs hulle, nuwe lêers wat by die staging area bygevoeg is het 'n A, gewysigde lêers het 'n M en so aan. Daar is twee kolomme in die uitvoer — die linkerkolom dui die status van die staging area aan en die regterkolom dui die status van die werkdirectory aan. So byvoorbeeld in daardie uitvoer is die README lêer gewysig in die werkdirectory maar nog nie gestaged nie, terwyl die lib/simplegit.rb lêer gewysig en gestaged is. Die Rakefile is gewysig, gestaged en toe weer gewysig, so daar is veranderinge daaraan wat beide gestaged en unstaged is.

Dikwels sal jy 'n klas lêers hê wat jy nie wil hê Git outomaties moet byvoeg of selfs as untracked vir jou wys nie. Dit is oor die algemeen outomaties gegenereerde lêers soos loglêers of lêers wat deur jou bou-stelsel geproduseer word. In sulke gevalle kan jy 'n lêer skep met die naam .gitignore wat patrone bevat om by hulle te pas. Hier is 'n voorbeeld van 'n .gitignore lêer:

Die eerste reël sê vir Git om enige lêers te ignoreer wat op “.o” of “.a” eindig — objek- en argieflêers wat dalk die produk van jou kodebouery is. Die tweede reël sê vir Git om alle lêers te ignoreer waarvan die name met 'n tilde (~) eindig, wat deur baie teksredigeerders soos Emacs gebruik word om tydelike lêers te merk. Jy kan ook 'n log, tmp, of pid directory insluit; outomaties gegenereerde dokumentasie; en so meer. Om 'n .gitignore lêer vir jou nuwe repository op te stel voordat jy aan die gang kom, is oor die algemeen 'n goeie idee sodat jy nie per ongeluk lêers commit wat jy regtig nie in jou Git repository wil hê nie.

Die reëls vir die patrone wat jy in die .gitignore lêer kan plaas, is soos volg:

Glob-patrone is soos vereenvoudigde gereelde uitdrukkings (regular expressions) wat shells gebruik. 'n Sterretjie () pas by nul of meer karakters; [abc] pas by enige karakter binne die blokhakies (in hierdie geval a, b, of c); 'n vraagteken (?) pas by 'n enkele karakter; en blokhakies wat karakters insluit wat deur 'n streepie geskei is ([0-9]), pas by enige karakter tussen hulle (in hierdie geval 0 tot 9). Jy kan ook twee sterretjies gebruik om geneste directories te pas; a/*/z sal by a/z, a/b/z, a/b/c/z, en so aan pas.

Hier is nog 'n voorbeeld van 'n .gitignore lêer:

As die git status opdrag te vaag is vir jou — jy wil presies weet wat jy verander het, nie net watter lêers verander is nie — kan jy die git diff opdrag gebruik. Ons sal git diff later in meer detail behandel, maar jy sal dit waarskynlik die meeste gebruik om hierdie twee vrae te beantwoord: Wat het jy verander maar nog nie gestaged nie? En wat het jy gestaged wat jy op die punt staan om te commit? Alhoewel git status daardie vrae baie algemeen beantwoord deur die lêername te lys, wys git diff jou die presiese reëls wat bygevoeg en verwyder is — die patch, as’t ware.

Kom ons sê jy wysig en stage die README lêer weer en wysig dan die CONTRIBUTING.md lêer sonder om dit te stage. As jy jou git status opdrag uitvoer, sien jy weereens iets soos hierdie:

Om te sien wat jy verander het maar nog nie gestaged het nie, tik git diff met geen ander argumente nie:

Daardie opdrag vergelyk wat in jou werkdirectory is met wat in jou staging area is. Die resultaat vertel jou watter veranderinge jy gemaak het wat jy nog nie gestaged het nie.

As jy wil sien wat jy gestaged het wat in jou volgende commit sal ingaan, kan jy git diff --staged gebruik. Hierdie opdrag vergelyk jou gestagede veranderinge met jou laaste commit:

Dit is belangrik om daarop te let dat git diff op sy eie nie alle veranderinge wys wat gemaak is sedert jou laaste commit nie — slegs veranderinge wat steeds unstaged is. As jy al jou veranderinge gestaged het, sal git diff vir jou geen uitvoer gee nie.

Vir nog 'n voorbeeld, as jy die CONTRIBUTING.md lêer stage en dit dan wysig, kan jy git diff gebruik om die veranderinge in die lêer te sien wat gestaged is en die veranderinge wat unstaged is. As ons omgewing so lyk:

Nou kan jy git diff gebruik om te sien wat steeds unstaged is:

en git diff --cached om te sien wat jy tot dusver gestaged het (--staged en --cached is sinonieme):

Nou dat jou staging area opgestel is soos jy dit wil hê, kan jy jou veranderinge commit. Onthou dat enigiets wat steeds unstaged is — enige lêers wat jy geskep of gewysig het waarop jy nie git add uitgevoer het sedert jy dit geredigeer het nie — nie in hierdie commit sal ingaan nie. Hulle sal as gewysigde lêers op jou skyf bly staan. In hierdie geval, kom ons sê dat die laaste keer wat jy git status uitgevoer het, jy gesien het dat alles gestaged is, so jy is gereed om jou veranderinge te commit. Die maklikste manier om te commit is om git commit te tik:

Deur dit te doen begin jou gekose redigeerder.

Die redigeerder wys die volgende teks (hierdie voorbeeld is 'n Vim-skerm):

Jy kan sien dat die verstek commit-boodskap die nuutste uitvoer van die git status opdrag as kommentaar bevat en een leë reël heel bo. Jy kan hierdie kommentare verwyder en jou eie commit-boodskap intik, of jy kan hulle daar laat om jou te help onthou wat jy besig is om te commit.

Wanneer jy die redigeerder verlaat, skep Git jou commit met daardie commit-boodskap (met die kommentare en diff verwyder).

As 'n alternatief kan jy jou commit-boodskap inlyn intik met die commit opdrag deur dit na 'n -m vlag te spesifiseer, soos hier:

Nou het jy jou eerste commit gemaak! Jy kan sien dat die commit jou 'n bietjie uitvoer oor homself gegee het: op watter tak jy gecommit het (master), watter SHA-1 checksum die commit het (463dc4f), hoeveel lêers verander is, en statistieke oor reëls bygevoeg en verwyder in die commit.

Onthou dat die commit die snapshot opneem wat jy in jou staging area opgestel het. Enigiets wat jy nie gestaged het nie, sit nog steeds daar gewysig; jy kan nog 'n commit doen om dit by jou geskiedenis te voeg. Elke keer as jy 'n commit uitvoer, lê jy 'n snapshot van jou projek vas waarna jy later kan terugkeer of dit mee kan vergelyk.

Alhoewel dit ongelooflik nuttig kan wees om commits presies te vorm soos jy hulle wil hê, is die staging area soms 'n bietjie meer kompleks as wat jy in jou werkvloei benodig. As jy die staging area wil oorslaan, bied Git 'n eenvoudige kortpad. Deur die -a opsie by die git commit opdrag te voeg, maak dat Git outomaties elke lêer wat reeds tracked is stage voordat die commit gedoen word, wat jou toelaat om die git add gedeelte oor te slaan:

Let op hoe jy in hierdie geval nie git add op die CONTRIBUTING.md lêer hoef uit te voer voordat jy commit nie. Dit is omdat die -a vlag alle veranderde lêers insluit. Dit is gerieflik, maar wees versigtig; soms sal hierdie vlag veroorsaak dat jy ongewenste veranderinge insluit.

Om 'n lêer uit Git te verwyder, moet jy dit van jou tracked lêers verwyder (meer akkuraat, verwyder dit uit jou staging area) en dan commit. Die git rm opdrag doen dit, en verwyder ook die lêer uit jou werkdirectory sodat jy dit nie volgende keer as 'n untracked lêer sien nie.

As jy bloot die lêer uit jou werkdirectory verwyder, wys dit onder die “Changes not staged for commit” (dit wil sê, unstaged) area van jou git status uitvoer:

Dan, as jy git rm uitvoer, stage dit die lêer se verwydering:

Die volgende keer as jy commit, sal die lêer weg wees en nie meer tracked word nie. As jy die lêer gewysig het of reeds by die staging area bygevoeg het, moet jy die verwydering forseer met die -f opsie. Dit is 'n veiligheidskenmerk om die toevallige verwydering van data wat nog nie in 'n snapshot vasgelê is nie en wat nie uit Git herwin kan word nie, te voorkom.

Nog 'n nuttige ding wat jy dalk wil doen, is om die lêer in jou werkdirectory te hou maar dit uit jou staging area te verwyder. Met ander woorde, jy wil dalk die lêer op jou hardeskyf hou, maar nie hê Git moet dit meer track nie. Dit is veral nuttig as jy vergeet het om iets by jou .gitignore lêer te voeg en dit per ongeluk gestaged het, soos 'n groot loglêer of 'n klomp .a saamgestelde lêers. Om dit te doen, gebruik die --cached opsie:

Jy kan lêers, directories, en file-glob patrone aan die git rm opdrag meegee. Dit beteken jy kan dinge doen soos:

Let op die truskuinsstreep (backslash) (\) voor die *. Dit is nodig omdat Git sy eie lêernaam-uitbreiding doen, bykomend tot jou shell se lêernaam-uitbreiding. Hierdie opdrag verwyder alle lêers wat die .log uitbreiding in die log/ directory het. Of, jy kan iets soos hierdie doen:

Hierdie opdrag verwyder alle lêers waarvan die name eindig met 'n ~.

Anders as baie ander VCS’e, track Git nie uitdruklik die verskuiwing van lêers nie. As jy 'n lêer in Git hernoem, word geen metadata in Git gestoor wat vir hom sê jy het die lêer hernoem nie. Git is egter redelik slim om dit agterna uit te pluis — ons sal 'n bietjie later na die opsporing van lêerverskuiwings kyk.

Dit is dus 'n bietjie verwarrend dat Git 'n mv opdrag het. As jy 'n lêer in Git wil hernoem, kan jy iets soos dit uitvoer:

en dit werk heeltemal goed. Eintlik, as jy so iets uitvoer en na die status kyk, sal jy sien dat Git dit as 'n hernoemde lêer beskou:

Dit is egter gelykstaande aan die uitvoer van so iets:

Git vind implisiet uit dat dit 'n hernoeming is, so dit maak nie saak of jy 'n lêer op daardie manier of met die mv opdrag hernoem nie. Die enigste werklike verskil is dat git mv een opdrag in plaas van drie is — dit is 'n geriefsfunksie. Belangriker nog, jy kan enige hulpmiddel gebruik wat jy wil om 'n lêer te hernoem, en die add/rm later hanteer, net voor jy commit.