2.2 Osnove Git - Snemanje sprememb v repozitorij

Glavno orodje, ki ga uporabljate, da določite, katere datoteke so v kakšnem stanju, je ukaz git status. Če ta ukaz poženete neposredno po kloniranju, bi morali videti nekaj takega:

To pomeni, da imate čisti delovni direktorij; z drugimi besedami, nobena od vaših datotek ni sledena ali spremenjena. Git tudi ne vidi kakršnihkoli nesledenih datotek, drugače bi bile tu izpisane. Na koncu vam ukaz pove, na kateri veji ste in vas obvesti, da ne izhaja iz iste veje na strežniku. Za sedaj je ta veja vedno master, kar je privzeto; to naj vas tu ne skrbi. Poglavje Veje Git bo šlo podrobno čez veje in reference.

Recimo, da dodate v svoj projekt novo datoteko, kot je enostavna datoteka README. Če datoteka prej še ni obstajala in poženete git status, boste takole videli svojo nesledeno datoteko:

Vidite lahko, da vaša nova datoteka README ni sledena, ker je pod »Untracked files«, kar je v vašem izpisu statusa. Nesledeno v osnovi pomeni, da Git vidi datoteko, ki je niste imeli v prejšnjem posnetku (potrditvi) in še ni bila dana v pripravo; Git je ne bo začel vključevati v vaše potrjene posnetke, dokler mu tega eksplicitno ne naročite. To dela zato, da ne začnete po nesreči vključevati generiranih binarnih datotek ali ostalih datotek, ki jih niste mislili vključiti. Želeli boste začeti z vključevanjem README, torej začnimo s sledenjem datoteke.

Da začnete slediti novi datoteki, uporabite ukaz git add. Da začnete slediti datoteki README, lahko poženete naslednje:

Če ponovno poženete svoj ukaz statusa, lahko vidite, da je vaša datoteka README sedaj sledena in dana v pripravo za potrjevanje:

Da je dana v pripravo, lahko veste, ker je pod naslovom »Changes to be committed«. Če na tej točki izvedete potrditev, bo različica datoteke v času, ko ste pognali git add, v naknadni zgodovini posnetka. Morda se spomnite, ko ste prej pognali git init, ste nato pognali git add <files> — to je bil začetek sledenja datotek v vašem direktoriju. Ukaz git add vzame ime poti za datoteko ali pa direktorij; če je direktorij, ukaz doda vse datoteke v tem direktoriju rekurzivno.

Spremenimo datoteko, ki je bila že sledena. Če spremenite prej sledeno datoteko imenovano CONTRIBUTING.md in nato ponovno poženete vaš ukaz git status, dobite nekaj, kar je videti takole:

Datoteka CONTRIBUTING.md se pojavi pod razdelkom imenovan »Changes not staged for commit« — kar pomeni, da je bila sledena datoteka spremenjena v delovnem direktoriju, vendar še ni bila dana v področje priprave. Za dodajanje v področje priprave, poženite ukaz git add. git add je ukaz z več pomeni — uporabite ga za začetek sledenja novih datotek, da daste datoteke v področje priprave in naredite druge stvari, kot je označevanje datotek konfliktov združevanja za rešene. Lahko je v pomoč razmišljati o tem bolj v smislu »Dodaj točno to vsebino naslednji potrditvi«, kot pa »Dodaj to datoteko projektu«. Poženimo sedaj git add, da dodamo datoteko CONTRIBUTING.md v področje priprave in nato ponovno poženimo git status:

Obe datoteki sta dani v področje priprave in šli bosta v vašo naslednjo potrditev. Na tej točki predpostavimo, da se spomnite neke majhne spremembe, ki jo želite narediti v CONTRIBUTING.md, preden jo potrdite. Ponovno jo odprete in naredite to spremembo in že ste pripravljeni na potrditev. Vendar poženimo git status še enkrat:

Kaj za vraga? Sedaj je CONTRIBUTING.md izpisan tako kot v področju priprave kot tudi v področju izven le-te. Kako je to mogoče? Izkaže se, da Git da datoteko v področje priprave točno tako, kot je, ko poženete ukaz git add. Če naredite potrditev sedaj s tem, da poženete ukaz git commit, bo šla v potrditev različica CONTRIBUTING.md, kakršna je bila, ko ste nazadnje pognali ukaz git add, ne pa kot različica datoteke, kakor je videti v vašem delovnem direktoriju. Če spremenite datoteko po tem, ko poženete git add, morate ponovno pognati git add, da daste v področje priprave zadnjo različico datoteke:

Medtem ko je izpis git status precej celovit, je tudi precej gostobeseden. Git ima tudi kratko zastavico statusa, da lahko vidite svoje spremembe na bolj kompakten način. Če poženete git status -s ali git status --short, dobite veliko bolj poenostavljen izpis iz ukaza.

Nove nesledene datoteke imajo zraven njih ??, nove datoteke, ki so bile dodane v področje priprave, imajo A, spremenjene datoteke imajo M in tako dalje. Obstajata dva stolpca za izpis — levi stolpec označuje, da je bila datoteka dana v pripravo in desni stolpec označuje status v delovni drevesni strukturi. Torej na primer v tem izpisu je datoteka README spremenjena v delovnem direktoriju, vendar še ni dana v pripravo, medtem ko je datoteka lib/simplegit.rb spremenjena in dana v pripravo. Rakefile je bila spremenjena, dana v pripravo in nato ponovno spremenjena, torej so na njej spremembe, ki so dane tako v pripravo kot tudi ne.

Pogostokrat boste imeli razred datotek, ki jih ne želite, da jih Git avtomatično doda ali celo prikazuje kot sledene. To so v splošnem avtomatsko generirane datoteke, kot so datoteke dnevnika ali datoteke proizvedene z vašim sistemom gradnje. V teh primerih lahko ustvarite vzorec seznama datotek, ki se mu prilegajo, z imenom .gitignore. Tu je primer datoteke .gitignore:

Prva vrstica pove Gitu, naj ignorira katerekoli datoteke, ki se končajo z ».o« ali ».a« — objekti in arhivske datoteke, ki so lahko produkt gradnje vaše kode. Druga vrstica pove Gitu, naj ignorira vse datoteke, ki se končajo s tildo (~), ki jo uporabljajo mnogi tekstovni urejevalniki, kot je Emacs, da označujejo začasne datoteke. Dodate lahko tudi direktorij log, tmp ali pid, avtomatsko generirano dokumentacijo itd. Nastavitev datoteke .gitignore preden začnete, je v splošnem dobra ideja, da po nesreči ne potrdite datotek, ki jih v resnici ne želite imeti v svojem repozitoriju Git.

Pravila vzorcev, ki jih lahko vključite v datoteko .gitignore, so naslednja:

Vzorci glob so kot poenostavljeni splošni izrazi, ki jih uporablja lupina. Zvezdica (*) se prilega nič ali več znakom; [abc] se prilega katerimkoli znakom znotraj oglatih oklepajev (v tem primeru a, b, ali c); vprašaj (?) se prilega enemu znaku; ter znaki oviti z oglatimi oklepaji in ločeni s pomišljaji ([0-9]) se prilegajo katerim koli znakom med njimi (v tem primeru od 0 do 9). Lahko uporabite tudi dve zvezdici, kar se prilega ugnezdenim direktorijem; a/**/z se prilega a/z, a/b/z a/b/c/z itd.

Tu je drug primer datoteke .gitignore:

Če vam ukaz git status ni preveč jasen — želite vedeti točno, kaj ste spremenili, ne samo katere datoteke so bile spremenjene — lahko uporabite ukaz git diff. git diff bomo pokrili v več podrobnostih kasneje, vendar ga boste uporabljali najpogosteje za odgovor na ti dve vprašanji: Kaj ste spremenili, vendar še ni dano v področje priprave? In kaj ste dali v področje priprave, da boste potrdili? Čeprav git status odgovori ta vprašanja zelo splošno z izpisom seznama imen datotek, vam git diff prikaže točne vrstice, ki so bile dodane in odstranjene — programski popravek, kakršne so bile.

Recimo, da urejate in ponovno daste v področje priprave datoteko README ter nato uredite datoteko CONTRIBUTING.md, brez da jo daste v področje priprave. Če poženete vaš ukaz git status, vidite ponovno nekaj takega:

Da vidite, kaj ste spremenili, vendar niste še dali v področje priprave, vpišite git diff brez argumentov:

Ukaz primerja, kaj je v vašem delovnem direktoriju s tem, kar je v vašem področju priprave. Rezultat vam pove spremembe, ki ste jih naredili in ki še niso dane v pripravo.

Če želite videti, kaj ste dali v področje priprave, da bo šlo v vašo naslednjo potrditev, lahko uporabite git diff --staged. Ta ukaz primerja vaše spremembe dane v področje priprave z vašo zadnjo potrditvijo:

Pomembno je omeniti, da git diff sam po sebi ne prikaže vseh sprememb, ki ste jih naredili od svoje zadnje potrditve — prikaže samo spremembe, ki še vedno niso dane področje priprave. Če ste dali v področje priprave vse svoje spremembe, vam git diff ne bo dal nobenega izpisa.

Za drug primer, če daste datoteko CONTRIBUTING.md v področje priprave in jo nato uredite, lahko uporabite git diff, da vidite spremembe v datoteki, ki je dana v področje priprave in spremembe, ki še niso dane v pripravo. Če je naše okolje videti takole:

Sedaj lahko uporabite git diff, da vidite, kaj še vedno ni dano v področje priprave:

in git diff --cached, da vidite, kaj ste do sedaj dali v področje priprave (--staged in --cached sta sinonima):

Sedaj, ko je vaše področje priprave nastavljeno na način, kot ga želite, lahko potrdite svoje spremembe. Pomnite, da karkoli, kar še ni dano v področje priprave — katerekoli datoteke, ki jih ustvarite ali spremenite, in na njih še niste pognali git add, odkar ste jih uredili — ne bodo šle v to potrditev. Ostale bodo kot spremenjene datoteke na vašem disku. V tem primeru, recimo, da zadnjič, ko ste pognali git status, ste videli, da je vse dano v pripravo, torej ste pripravljeni, da potrdite svoje spremembe. Najenostavnejši način za potrditev je vpis git commit:

To zažene vaš urejevalnik po izbiri.

Urejevalnik prikaže naslednje besedilo (ta primer je zaslon Vim):

Vidite lahko, da privzeto sporočilo potrditve vsebuje zadnji izpis ukaza git status, ki je zakomentiran in na vrhu ima eno prazno vrstico. Te komentarje lahko odstranite in vpišete svoje sporočilo potrditve, ali jih pustite tam, da vam pomagajo, se spomniti, kaj potrjujete.

Ko zapustite urejevalnik, Git ustvari vašo potrditev s sporočilom potrditve (z odstranjenimi komentarji in razliko).

Alternativno lahko vpišete vaše sporočilo potrditve znotraj vrstice z ukazom commit, ki ga določite po zastavici -m takole:

Sedaj ste ustvarili svojo prvo potrditev! Vidite lahko, da vam je potrjevanje dalo izpis o samem sebi: v katero vejo ste dali potrditev (master), katera je kontrolna vsota SHA-1, ki jo ima potrditev (463dc4f), koliko datotek je bilo spremenjenih in statistiko o dodanih in odstranjenih vrsticah v potrditvi.

Zapomnite si, da potrditev snema posnetke, ki ste jih nastavili v svojem področju priprave. Karkoli, kar niste dali v pripravo, še vedno čaka spremenjeno; lahko naredite drugo potrditev, da to dodate v svojo zgodovino. Vsakič, ko izvedete potrditev, posnamete posnetek svojega projekta, ki ga lahko povrnete ali primerjate kasneje.

Čeprav je področje priprave posebej uporabno za izdelovanje potrditev točno takih, kakor jih želite, je včasih bolj kompleksno, kot ga potrebujete v svojem poteku dela. Če želite področje priprave preskočiti, Git ponuja enostavno bližnjico. Dodajanje možnosti -a ukazu git commit naredi, da Git avtomatično doda vsako datoteko, ki je že sledena, preden naredi potrditev in vam omogoči preskočiti del git add:

Bodite pozorni, kako vam v tem primeru ni bilo potrebno pognati git add na datoteki CONTRIBUTING.md pred vašo potrditvijo. To je zato, ker zastavica -a vključuje vse spremenjene datoteke. To je priročno, vendar bodite pazljivi; včasih vam ta zastavica vključi tudi neželene spremembe.

Da odstranite datoteko iz Gita, jo morate odstraniti iz svojih sledenih datotek (bolj točno, odstraniti iz vašega področja priprave) in nato narediti potrditev. To naredi ukaz git rm in prav tako odstrani datoteko iz vašega delovnega direktorija, da je naslednjič ne vidite kot nesledeno datoteko.

Če datoteko enostavno odstranite iz svojega delovnega direktorija, se prikaže pod »Changes not staged for commit« (to je izven področja priprave), v področju vašega izpisa git status:

Nato, če poženete git rm, doda odstranjevanje datoteke v področje priprave:

Naslednjič ko naredite potrditev, bo datoteka odstranjena in ne bo več sledena. Če ste datoteko spremenili, ali jo že dodali v področje priprave, morate prisiliti odstranjevanje z možnostjo -f. To je varnostna lastnost, da prepreči odstranjevanje podatkov po nesreči, ki še niso bili posneti v posnetku in ne morejo biti povrnjeni iz Gita.

Druga uporabna stvar, ki jo morda želite narediti, je slediti datoteki v vašem delovnem drevesu, vendar jo odstraniti iz vašega področja priprave. Z drugimi besedami, morda želite slediti datoteki na svojem trdem disku, vendar ji ne več slediti v Gitu. To je posebej uporabno, če pozabite dodati nekaj v vašo datoteko .gitignore in jo po nesreči daste v pripravo, kot je velika datoteka dnevnika ali skupek prevedenih datotek .a. Da to naredite, uporabite možnost --cached:

Lahko podate datoteke, direktorije in vzorce datotek glob k ukazu git rm. To pomeni, da lahko naredite stvari, kot je:

Bodite pozorni na levo poševnico (\) pred *. To je potrebno, ker Git naredi njegovo lastno razširjanje imen datotek poleg vašega razširjanja imen datotek lupine. Ta ukaz odstrani vse datoteke, ki imajo končnico .log v direktoriju log/. Ali pa lahko naredite nekaj takega:

Ta ukaz odstrani vse datoteke, ki se končajo z ~.

Z razliko od ostalih sistemov VCS, Git eksplicitno ne sledi premikanju datotek. Če v Gitu preimenujete datoteko, ni shranjenih v Gitu nobenih metapodatkov, ki vam povejo, da ste preimenovali datoteko. Vendar je Git glede ugotavljanja precej pameten — z zaznavanjem premikanja datotek se bomo ukvarjali nekoliko kasneje.

Torej je nekoliko nejasno, da ima Git ukaz mv. Če želite preimenovati datoteko v Gitu, lahko poženete nekaj takega:

kar deluje odlično. V bistvu, če poženete nekaj takega in pogledate status, boste videli, da ima Git to datoteko za preimenovano:

Vendar to je enakovredno pogonu nečesa takega:

Git posredno ugotovi, da gre za preimenovanje, torej ni pomembno, ali preimenujete datoteko na ta način ali z ukazom mv. Edina resnična razlika je, da je ukaz git mv en ukaz namesto treh — gre za funkcijo priročnosti. Bolj pomembno, za preimenovanje datoteke lahko uporabite katerokoli orodje želite in naslovite add/rm kasneje, preden potrjujete.