-
1. Začetek
- 1.1 O nadzoru različic
- 1.2 Kratka zgodovina Gita
- 1.3 Kaj je Git?
- 1.4 Ukazna vrstica
- 1.5 Namestitev Gita
- 1.6 Prva nastavitev Gita
- 1.7 Pridobivanje pomoči
- 1.8 Povzetek
-
2. Osnove Git
- 2.1 Pridobivanje repozitorija Git
- 2.2 Snemanje sprememb v repozitorij
- 2.3 Pregled zgodovine potrditev
- 2.4 Razveljavljanje stvari
- 2.5 Delo z daljavami
- 2.6 Označevanje
- 2.7 Aliasi Git
- 2.8 Povzetek
-
3. Veje Git
- 3.1 Veje na kratko
- 3.2 Osnove vej in združevanja
- 3.3 Upravljanje vej
- 3.4 Poteki dela z vejami
- 3.5 Oddaljene veje
- 3.6 Ponovno baziranje
- 3.7 Povzetek
-
4. Git na strežniku
- 4.1 Protokoli
- 4.2 Pridobitev Gita na strežniku
- 4.3 Generiranje vaših javnih ključev SSH
- 4.4 Nastavitev strežnika
- 4.5 Prikriti proces Git
- 4.6 Pametni HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Možnosti gostovanja pri tretjih ponudnikih
- 4.10 Povzetek
-
5. Porazdeljeni Git
- 5.1 Porazdeljeni poteki dela
- 5.2 Prispevek k projektu
- 5.3 Vzdrževanje projekta
- 5.4 Povzetek
-
6. GitHub
-
7. Orodja Git
- 7.1 Izbira revizije
- 7.2 Interaktivno pripravljanje
- 7.3 Shranjevanje na varno (angl. stashing) in čiščenje
- 7.4 Podpisovanje vašega dela
- 7.5 Iskanje
- 7.6 Prepisovanje zgodovine
- 7.7 Demistifikacija ponastavitve
- 7.8 Napredno združevanje
- 7.9 Rerere
- 7.10 Razhroščevanje z Gitom
- 7.11 Podmoduli
- 7.12 Povezovanje v pakete
- 7.13 Zamenjava
- 7.14 Shramba poverilnic
- 7.15 Povzetek
-
8. Prilagoditev Gita
- 8.1 Konfiguracija Git
- 8.2 Atributi Git
- 8.3 Kljuke Git
- 8.4 Primer pravilnika, ki ga uveljavlja Git
- 8.5 Povzetek
-
9. Git in ostali sistemi
- 9.1 Git kot odjemalec
- 9.2 Migracija na Git
- 9.3 Povzetek
-
10. Notranjost Gita
- 10.1 Napeljava in keramika
- 10.2 Objekti Git
- 10.3 Reference Git
- 10.4 Packfiles (datoteke zmanjšanih podatkov)
- 10.5 Refspec
- 10.6 Protokoli prenosa
- 10.7 Vzdrževanje in obnovitev podatkov
- 10.8 Spremenljivke okolja
- 10.9 Povzetek
-
A1. Dodatek A: Git v drugih okoljih
- A1.1 Grafični vmesniki
- A1.2 Git v Visual Studio
- A1.3 Git v Visual Studio Code
- A1.4 Git v IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine
- A1.5 Git v Sublime Text
- A1.6 Git v Bashu
- A1.7 Git v Zsh
- A1.8 Git v Powershellu
- A1.9 Povzetek
-
A2. Dodatek B: Vdelava Gita v vašo aplikacijo
- A2.1 Git v ukazni vrstici
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
- A2.5 Dulwich
-
A3. Dodatek C: Ukazi Git
- A3.1 Nastavitev in konfiguracija
- A3.2 Pridobivanje in ustvarjanje projektov
- A3.3 Osnove posnetkov
- A3.4 Veje in združevanje
- A3.5 Deljenje in posodabljanje projektov
- A3.6 Pregled in primerjava
- A3.7 Razhroščevanje
- A3.8 Popravljanje
- A3.9 E-pošta
- A3.10 Zunanji sistemi
- A3.11 Administracija
- A3.12 Orodja za sisteme napeljave
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.
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 Kljub temu pa Git še vedno uporablja |
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 |
Opomba
|
V enostavnem primeru ima lahko repozitorij eno datoteko Iti v podrobnosti večih datotek |
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 |
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 |
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 |
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.