Git 🌙
Chapters ▾ 2nd Edition

2.2 Osnove Git - Snemanje sprememb v repozitorij

Snemanje sprememb v repozitorij

Na tej točki bi morali v najboljšem primeru imeti pred seboj na vaši lokalni napravi repozitorij Git in izvlek (angl. checkout) ali delovno kopijo vseh njegovih datotek. Običajno boste želeli začeti delati spremembe in potrditi posnetke teh sprememb v vaš repozitorij vsakič, ko projekt doseže stanje, ki ga želite posneti.

Pomnite, da je lahko vsaka datoteka v vašem delovnem direktoriju v dveh stanjih: sledena ali nesledena. Sledene datoteke so datoteke, ki so bile v zadnjem posnetku, kot tudi katerekoli na novo pripravljene datoteke; lahko so nespremenjene, spremenjene, ali dane v področje priprave. Na kratko, sledene datoteke so datoteke, za katere Git ve.

Nesledene datoteke so vse ostale — katerakoli datoteka v vašem delovnem direktoriju, ki ni bila v vašem zadnjem posnetku in ni v vašem področju priprave. Ko prvič klonirate repozitorij, bodo vse vaše datoteke sledene in nespremenjene, ker jih je Git ravnokar izvlekel in jih še niste kakorkoli urejali.

Ko boste urejali datoteke, jih Git vidi kot spremenjene, ker ste jih spremenili od zadnje potrditve. Ko boste delali, izbrane spremenjene datoteke daste v pripravo in nato potrdite vse vaše spremembe v pripravi ter cikel se ponovi.

Življenjski cikel statusa vaših datotek
Slika 8. Življenjski cikel statusa vaših datotek

Preverjanje statusa vaših datotek

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:

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working tree clean

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.

Opomba

GitHub je v sredini leta 2020 spremenil privzeto ime glavne veje iz master v main, drugi gostitelji Git pa so sledili zgledu. Tako lahko opazite, da je privzeto ime veje v nekaterih novo ustvarjenih repozitorijih main in ne master. Poleg tega se lahko privzeto ime veje spremeni (kot ste videli v Vaše privzeto ime veje), zato lahko vidite drugačno ime za privzeto vejo.

Kljub temu pa Git še vedno uporablja master kot privzeto ime, zato ga bomo uporabljali v celotni knjigi.

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:

$ echo 'My Project' > README
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Untracked files:
  (use "git add <file>..." to include in what will be committed)

    README

nothing added to commit but untracked files present (use "git add" to track)

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.

Sledenje novih datotek

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

$ git add README

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

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)

    new file:   README

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.

Priprava spremenjenih datotek

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:

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   README

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

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:

$ git add CONTRIBUTING.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   README
    modified:   CONTRIBUTING.md

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:

$ vim CONTRIBUTING.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   README
    modified:   CONTRIBUTING.md

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

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:

$ git add CONTRIBUTING.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   README
    modified:   CONTRIBUTING.md

Kratek status

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.

$ git status -s
 M README
MM Rakefile
A  lib/git.rb
M  lib/simplegit.rb
?? LICENSE.txt

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.

Ignoriranje datotek

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:

$ cat .gitignore
*.[oa]
*~

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:

  • Prazne vrstice ali vrstice, ki se začnejo z #, so ignorirane.

  • Standardni vzorci glob delujejo in bodo uporabljeni rekurzivno skozi celotno delovno drevesno strukturo.

  • Vzorce lahko začnete s poševnico (/), da se izognete rekurziji.

  • Vzorce lahko zaključite s poševnico (/), da določite direktorij.

  • Vzorec lahko negirate tako, da ga začnete s klicajem (!).

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:

# ignore all .a files
*.a

# but do track lib.a, even though you're ignoring .a files above
!lib.a

# only ignore the TODO file in the current directory, not subdir/TODO
/TODO

# ignore all files in any directory named build
build/

# ignore doc/notes.txt, but not doc/server/arch.txt
doc/*.txt

# ignore all .pdf files in the doc/ directory and any of its subdirectories
doc/**/*.pdf
Namig

GitHub upravlja precej celovit seznam dobrih primerov datotek .gitignore za ducate projektov in jezikov na https://github.com/github/gitignore, če želite začetno točko za svoj projekt.

Opomba

V enostavnem primeru ima lahko repozitorij eno datoteko .gitignore v svojem vrhnjem direktoriju, ki velja rekurzivno za celoten repozitorij. Vendar je mogoče imeti tudi dodatne datoteke .gitignore v poddirektorijih. Pravila v teh ugnezdenih datotekah .gitignore veljajo samo za datoteke znotraj direktorija, v katerem je. Repozitorij izvorne kode jedra Linux ima 206 datotek .gitignore.

Iti v podrobnosti večih datotek .gitignore je izven obsega te knjige; za več informacij poglejte man gitignore.

Ogled vaših sprememb v področju priprave in izven njega

Č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:

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    modified:   README

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

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

$ git diff
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 8ebb991..643e24f 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -65,7 +65,8 @@ branch directly, things can get messy.
 Please include a nice description of your changes when you submit your PR;
 if we have to read the whole diff to figure out why you're contributing
 in the first place, you're less likely to get feedback and have your change
-merged in.
+merged in. Also, split your changes into comprehensive chunks if your patch is
+longer than a dozen lines.

 If you are starting to work on a particular area, feel free to submit a PR
 that highlights your work in progress (and note in the PR title that it's

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:

$ git diff --staged
diff --git a/README b/README
new file mode 100644
index 0000000..03902a1
--- /dev/null
+++ b/README
@@ -0,0 +1 @@
+My Project

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:

$ git add CONTRIBUTING.md
$ echo '# test line' >> CONTRIBUTING.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    modified:   CONTRIBUTING.md

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

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

$ git diff
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 643e24f..87f08c8 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -119,3 +119,4 @@ at the
 ## Starter Projects

 See our [projects list](https://github.com/libgit2/libgit2/blob/development/PROJECTS.md).
+# test line

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

$ git diff --cached
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 8ebb991..643e24f 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -65,7 +65,8 @@ branch directly, things can get messy.
 Please include a nice description of your changes when you submit your PR;
 if we have to read the whole diff to figure out why you're contributing
 in the first place, you're less likely to get feedback and have your change
-merged in.
+merged in. Also, split your changes into comprehensive chunks if your patch is
+longer than a dozen lines.

 If you are starting to work on a particular area, feel free to submit a PR
 that highlights your work in progress (and note in the PR title that it's
Opomba
Git diff v zunanjem orodju

Skozi preostanek knjige bomo nadaljevali z uporabo ukaza git diff na različne načine. Je še drug način za pogledati te spremembe, če imate namesto tega raje grafični ali zunanji pregledovalnik diff. Če poženete git difftool namesto git diff, lahko pogledate katerekoli od teh sprememb v programu, kot so emerge, vimdiff in mnogi ostali (vključno s komercialnimi produkti). Poženite git difftool --tool-help, da vidite, kaj je na voljo na vašem sistemu.

Potrjevanje vaših sprememb

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:

$ git commit

To zažene vaš urejevalnik po izbiri.

Opomba

To je nastavljeno v vaši spremenljivki okolja lupine $EDITOR — običajno vim ali emacs, vendar jo lahko nastavite, s čimer koli želite, z uporabo ukaza git config --global core.editor, kot ste videli v poglavju Začetek.

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

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Your branch is up-to-date with 'origin/master'.
#
# Changes to be committed:
#	new file:   README
#	modified:   CONTRIBUTING.md
#
~
~
~
".git/COMMIT_EDITMSG" 9L, 283C

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.

Opomba

Za še bolj eksplicitni opomnik, kaj ste spremenili, lahko podate možnost -v ukazu git commit. To doda tudi razliko vaše spremembe v urejevalnik, da lahko točno vidite, katere spremembe 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:

$ git commit -m "Story 182: fix benchmarks for speed"
[master 463dc4f] Story 182: fix benchmarks for speed
 2 files changed, 2 insertions(+)
 create mode 100644 README

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.

Preskok področja priprave

Č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:

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

no changes added to commit (use "git add" and/or "git commit -a")
$ git commit -a -m 'Add new benchmarks'
[master 83e38c7] Add new benchmarks
 1 file changed, 5 insertions(+), 0 deletions(-)

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.

Odstranjevanje datotek

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:

$ rm PROJECTS.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        deleted:    PROJECTS.md

no changes added to commit (use "git add" and/or "git commit -a")

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

$ git rm PROJECTS.md
rm 'PROJECTS.md'
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    deleted:    PROJECTS.md

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:

$ git rm --cached README

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

$ git rm log/\*.log

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:

$ git rm \*~

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

Premikanje datotek

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:

$ git mv file_from file_to

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

$ git mv README.md README
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    renamed:    README.md -> README

Vendar to je enakovredno pogonu nečesa takega:

$ mv README.md README
$ git rm README.md
$ git add README

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.

scroll-to-top