diff --git a/C-git-commands.asc b/C-git-commands.asc index b62fc032..47e9a321 100644 --- a/C-git-commands.asc +++ b/C-git-commands.asc @@ -35,7 +35,7 @@ V razdelku <> smo pokazali, kako ga lahko V razdelku <> smo ga uporabili, da smo določili privzeto vedenje `--rebase`, ko zaženemo ukaz `git pull`. -V razdelku <> smo ga uporabili, da smo nastavili privzeti repozitorij za vaša HTTP gesla. +V razdelku <> smo ga uporabili, da smo nastavili privzeti repozitorij za vaša gesla HTTP. V razdelku <> smo pokazali, kako nastaviti t.i. filtra `smudge` in `clean` na vsebini, ki prihaja in odhaja iz Gita. @@ -175,7 +175,7 @@ To smo omenili le na kratko v <>. Ukaz `git commit` vzame vsebino datotek, ki so bile dane v pripravo z `git add` in zabeleži nov trajni posnetek v bazi podatkov in nato premakne kazalec veje na trenutni veji. Osnove za izvajanje posnetkov smo predstavili v <>. -Tam smo prikazali tudi, kako uporabiti zastavico `-a`, da preskočite korak `git add` v vsakodnevnih delovnih procesih in kako uporabiti zastavico `-m`, da na ukazni vrstici predate sporočilo za potrditev namesto zagona urejevalnika. +Tam smo prikazali tudi, kako uporabiti zastavico `-a`, da preskočite korak `git add` v vsakodnevnih potekih dela in kako uporabiti zastavico `-m`, da na ukazni vrstici predate sporočilo za potrditev namesto zagona urejevalnika. V poglavju <> smo predstavili uporabo možnosti `--amend`, s katero lahko ponovno opravite zadnjo potrditev. @@ -357,7 +357,7 @@ V poglavju <> smo videli, kako ga uporabi V poglavju <> smo uporabili možnost `--recurse-submodules`, da smo preverili, ali je bilo vso delo z našimi podmoduli objavljeno, preden potisnemo nadrejeni projekt, kar je lahko resnično koristno pri uporabi podmodulov. -V poglavju <> smo na kratko govorili o kavlju `pre-push`, ki je skripta, ki jo lahko nastavimo, da se izvede pred končanjem potiskanja, da preveri, ali je potiskanje dovoljeno. +V poglavju <> smo na kratko govorili o kljuki `pre-push`, ki je skripta, ki jo lahko nastavimo, da se izvede pred končanjem potiskanja, da preveri, ali je potiskanje dovoljeno. Na koncu, smo si v poglavju <> ogledali potiskanje z uporabo celotnega refspec-a namesto splošnih bližnjic, ki se običajno uporabljajo. To vam lahko pomaga, da boste zelo specifični glede dela, ki ga želite deliti. @@ -476,7 +476,7 @@ Git ima vgrajena orodja, ki pomagajo olajšati ta proces, od ustvarjanja popravk ==== git apply -Ukaz `git apply` uporabi popravek, ustvarjen z ukazom `git diff` ali celo z GNU diff ukazom. +Ukaz `git apply` uporabi programski popravek, ustvarjen z ukazom `git diff` ali celo z ukazom GNU diff. Podobno kot ukaz `patch` naredi z nekaj manjšimi razlikami. V poglavju <> smo predstavili uporabo in okoliščine, v katerih ga lahko uporabimo. @@ -486,9 +486,9 @@ V poglavju <> smo predstavili uporabo Ukaz `git am` se uporablja za uporabo programskih popravkov iz poštnega nabiralnika, posebej tistega, ki je oblikovan kot mbox. To je uporabno za prejemanje popravkov preko e-pošte in njihovo enostavno uporabo v projektu. -Pokrili smo uporabo in delovni tok okoli `git am` v <>, vključno z uporabo možnosti `--resolved`, `-i` in `-3`. +Pokrili smo uporabo in potek dela okoli `git am` v <>, vključno z uporabo možnosti `--resolved`, `-i` in `-3`. -Obstaja tudi veliko število kaveljčkov, ki jih lahko uporabite za pomoč pri delovnem toku okoli `git am` in vsi so opisani v poglavju <>. +Obstaja tudi veliko število kljuk, ki jih lahko uporabite za pomoč pri poteku dela okoli `git am` in vsi so opisani v poglavju <>. Uporabimo ga tudi za uporabo sprememb oblikovanih kot popravki za zahteve potegov na GitHubu v poglavju <>. diff --git a/book/01-introduction/sections/help.asc b/book/01-introduction/sections/help.asc index 199e1d4c..f8f8f722 100644 --- a/book/01-introduction/sections/help.asc +++ b/book/01-introduction/sections/help.asc @@ -23,7 +23,7 @@ Ti kanali so pogosto napolnjeni s stotinami ljudi, ki veliko vedo o Gitu in so p Poleg tega, če ne potrebujete obsežne pomoči v obliki man-strani, ampak samo potrebujete hitro osvežitev o možnostih za določen ukaz v Git, lahko zaprosite za bolj jedrnat izhod "`help`" z uporabo možnosti `-h`, kot na primer: -[source,console] +[source,console?prompt=$] ---- $ git add -h usage: git add [] [--] ... diff --git a/book/02-git-basics/sections/aliases.asc b/book/02-git-basics/sections/aliases.asc index 1f055168..730f47b6 100644 --- a/book/02-git-basics/sections/aliases.asc +++ b/book/02-git-basics/sections/aliases.asc @@ -46,7 +46,7 @@ $ git config --global alias.last 'log -1 HEAD' Na ta način lahko enostavneje pogledate zadnjo potrditev: -[source,console] +[source,console?prompt=$] ---- $ git last commit 66938dae3329c7aebe598c2246a8e6af90d04646 diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index 406fd33d..e6107736 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -48,7 +48,7 @@ Kljub temu pa Git še vedno uporablja `master` kot privzeto ime, zato ga bomo up Recimo, da dodate v vaš projekt novo datoteko, kot je enostavna datoteka `README`. Če datoteka prej še ni obstajala in poženete `git status`, boste videli vašo nesledeno datoteko sledeče: -[source,console] +[source,console?prompt=$] ---- $ echo 'My Project' > README $ git status @@ -80,7 +80,7 @@ $ git add README Če ponovno poženete vaš ukaz statusa, lahko vidite, da je vaša datoteka `README` sedaj sledena in dana v pripravo za potrjevanje: -[source,console] +[source,console?prompt=$] ---- $ git status On branch master @@ -102,7 +102,7 @@ Ukaz `git add` vzame ime poti za bodisi datoteko ali pa direktorij; če je direk 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 izgleda takole: -[source,console] +[source,console?prompt=$] ---- $ git status On branch master @@ -126,7 +126,7 @@ Za dodajanje v področje priprave, poženite ukaz `git add`. Lahko je v pomoč razmišljati o tem bolj v smislu "`dodaj točno to vsebino naslednji potrditvi`", kot pa "`dodaj to datoteko projektu`".(((git commands, add))) Poženimo sedaj `git add`, da dodamo datoteko `CONTRIBUTING.md` v področje priprave in nato ponovno poženimo `git status`: -[source,console] +[source,console?prompt=$] ---- $ git add CONTRIBUTING.md $ git status @@ -145,7 +145,7 @@ Na tej točki predpostavimo, da se spomnite neke majhne spremembe, ki jo želite Ponovno jo odprete in naredite to spremembo in že ste pripravljeni na potrditev. Vendar poženimo `git status` še enkrat: -[source,console] +[source,console?prompt=$] ---- $ vim CONTRIBUTING.md $ git status @@ -172,7 +172,7 @@ Izkaže se, da Git da datoteko v področje priprave točno tako, kot je, ko pož Č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 izgleda v vašem delovnem direktoriju. Če spremenite datoteko po tem, ko poženete `git add`, morate ponovno pognati `git add`, da date v področje priprave zadnjo različico datoteke: -[source,console] +[source,console?prompt=$] ---- $ git add CONTRIBUTING.md $ git status @@ -282,12 +282,12 @@ Iti v podrobnosti večih datotek `.gitignore` je izven obsega te knjige; za več Č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 commands, 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 - popravek, kakršne so bile. +Č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 date v področje priprave datoteko `README` ter nato uredite datoteko `CONTRIBUTING.md` brez, da jo date v področje priprave. Če poženete vaš ukaz `git status`, vidite ponovno nekaj takega: -[source,console] +[source,console?prompt=$] ---- $ git status On branch master @@ -306,7 +306,7 @@ Changes not staged for commit: Da vidite, kaj ste spremenili, vendar niste še dali v področje priprave, vpišite `git diff` brez argumentov: -[source,console] +[source,console?prompt=$] ---- $ git diff diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md @@ -349,7 +349,7 @@ Pomembno je omeniti, da `git diff` sam po sebi ne prikaže vseh sprememb, ki ste Za drug primer, če date 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 naše okolje izgleda takole: -[source,console] +[source,console?prompt=$] ---- $ git add CONTRIBUTING.md $ echo '# test line' >> CONTRIBUTING.md @@ -370,7 +370,7 @@ Changes not staged for commit: Sedaj lahko uporabite `git diff`, da vidite, kaj še vedno ni dano v področje priprave: -[source,console] +[source,console?prompt=$] ---- $ git diff diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md @@ -386,7 +386,7 @@ index 643e24f..87f08c8 100644 in `git diff --cached`, da vidite, kaj ste do sedaj dali v področje priprave (`--staged` in `--cached` sta sinonima): -[source,console] +[source,console?prompt=$] ---- $ git diff --cached diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md @@ -490,7 +490,7 @@ Vsakič, ko izvedete potrditev, posnamete posnetek vašega projekta, ki ga lahko Č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`: -[source,console] +[source,console?prompt=$] ---- $ git status On branch master @@ -520,7 +520,7 @@ To naredi ukaz `git rm` in prav tako odstrani datoteko iz vašega delovnega dire Če datoteko enostavno odstranite iz vašega 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`: -[source,console] +[source,console?prompt=$] ---- $ rm PROJECTS.md $ git status @@ -537,7 +537,7 @@ 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: -[source,console] +[source,console?prompt=$] ---- $ git rm PROJECTS.md rm 'PROJECTS.md' @@ -603,7 +603,7 @@ $ git mv file_from file_to kar deluje odlično. V bistvu, če poženete nekaj takega in pogledate status, boste videli, da Git to datoteko smatra kot preimenovano: -[source,console] +[source,console?prompt=$] ---- $ git mv README.md README $ git status diff --git a/book/02-git-basics/sections/remotes.asc b/book/02-git-basics/sections/remotes.asc index 5fac170a..f8ce3334 100644 --- a/book/02-git-basics/sections/remotes.asc +++ b/book/02-git-basics/sections/remotes.asc @@ -90,7 +90,7 @@ pb https://github.com/paulboone/ticgit (push) Sedaj lahko v ukazni vrstici uporabite niz `pb` namesto celotnega URL-ja. Na primer, če želite prenesti vse informacije, ki jih ima Paul, vendar jih vi še nimate v vašem repozitoriju, lahko poženete `git fetch pb`: -[source,console] +[source,console?prompt=$] ---- $ git fetch pb remote: Counting objects: 43, done. diff --git a/book/02-git-basics/sections/tagging.asc b/book/02-git-basics/sections/tagging.asc index 876cbdc4..75af42fc 100644 --- a/book/02-git-basics/sections/tagging.asc +++ b/book/02-git-basics/sections/tagging.asc @@ -78,7 +78,7 @@ v1.4 Z uporabo ukaza `git show` lahko pogledate podatke oznake skupaj s potrditvijo, ki je bila označena: -[source,console] +[source,console?prompt=$] ---- $ git show v1.4 tag v1.4 @@ -117,7 +117,7 @@ v1.5 Tokrat, če poženete `git show` na oznaki, ne boste videli dodatnih informacij oznake.(((git commands, show))) Ukaz samo prikazuje potrditev: -[source,console] +[source,console?prompt=$] ---- $ git show v1.4-lw commit ca82a6dff817ec66f44342007202690a93763949 @@ -158,7 +158,7 @@ $ git tag -a v1.2 9fceb02 Vidite lahko, da ste označili potrditev:(((git commands, tag))) -[source,console] +[source,console?prompt=$] ---- $ git tag v0.1 @@ -189,7 +189,7 @@ Privzeto, ukaz `git push` ne prenese oznak na oddaljene strežnike.(((git comman Morali boste eksplicitno poslati oznake na deljeni strežnik za tem, ko ste jih naredili. Ta proces je enak deljenju oddaljenih vej - lahko poženete `git push origin `. -[source,console] +[source,console?prompt=$] ---- $ git push origin v1.5 Counting objects: 14, done. @@ -204,7 +204,7 @@ To git@github.com:schacon/simplegit.git Če imate veliko oznak, ki jih želite poslati naenkrat, lahko uporabite tudi možnost `--tags` pri ukazu `git push`. To bo na oddaljeni strežnik preneslo vse vaše oznake, ki še niso tam. -[source,console] +[source,console?prompt=$] ---- $ git push origin --tags Counting objects: 1, done. @@ -256,11 +256,11 @@ Drugi (in bolj intuitiven) način za brisanje oddaljene oznake je: $ git push origin --delete ---- -==== Izpisovanje oznak +==== Izvlečenje oznak Če želite pogledati različice datotek, na katere oznaka kaže, lahko naredite `git checkout` določene oznake, vendar vam to vaš repozitorij da v stanje "`detached HEAD`", kar ima določene stranske učinke: -[source,console] +[source,console?prompt=$] ---- $ git checkout v2.0.0 Note: switching to 'v2.0.0'. diff --git a/book/02-git-basics/sections/undoing.asc b/book/02-git-basics/sections/undoing.asc index 5f94ebe9..7fd1f8b4 100644 --- a/book/02-git-basics/sections/undoing.asc +++ b/book/02-git-basics/sections/undoing.asc @@ -55,7 +55,7 @@ Na primer, recimo, da ste spremenili dve datoteki in jih želite potrditi kot dv Kako lahko povrnete eno izmed dveh iz področja priprave? Ukaz `git status` vas opomni: -[source,console] +[source,console?prompt=$] ---- $ git add * $ git status @@ -70,7 +70,7 @@ Changes to be committed: Ravno pod tekstom "`Changes to be committed`", pravi, da uporabite `git reset HEAD ...` za povrnitev iz področja priprave. Torej uporabimo ta nasvet za povrnitev datoteke `CONTRIBUTING.md` iz priprave: -[source,console] +[source,console?prompt=$] ---- $ git reset HEAD CONTRIBUTING.md Unstaged changes after reset: @@ -108,7 +108,7 @@ Kako jo lahko enostavno razveljavite - povrnete nazaj v stanje, kakor je izgleda Na srečo vam `git status` prav tako pove, kako to narediti. V izpisu zadnjega primera izgleda področje izven priprave takole: -[source,console] +[source,console?prompt=$] ---- Changes not staged for commit: (use "git add ..." to update what will be committed) @@ -120,7 +120,7 @@ Changes not staged for commit: Precej jasno vam pove, kako zavreči spremembe, ki ste jih naredili. Naredimo, kar pravi: -[source,console] +[source,console?prompt=$] ---- $ git checkout -- CONTRIBUTING.md $ git status @@ -164,7 +164,7 @@ Na primer, recimo, da ste spremenili dve datoteki in ju želite potrditi kot dve Kako lahko razveljavite eno od teh dveh datotek? Ukaz `git status` vas opomni: -[source,console] +[source,console?prompt=$] ---- $ git add * $ git status @@ -179,7 +179,7 @@ Changes to be committed: Takoj pod besedilom "`Changes to be committed`" piše, da uporabite `git restore --staged ...` za razveljavitev področja priprave. Zato uporabimo ta nasvet, da razveljavimo datoteko `CONTRIBUTING.md`: -[source,console] +[source,console?prompt=$] ---- $ git restore --staged CONTRIBUTING.md $ git status @@ -204,7 +204,7 @@ Kako lahko to enostavno razveljavite - vrnete nazaj, kakor je bilo nazadnje potr Na srečo vam `git status` prav tako pove, kako to storiti. V izpisu zadnjega primera področje izven priprave izgleda takole: -[source,console] +[source,console?prompt=$] ---- Changes not staged for commit: (use "git add ..." to update what will be committed) @@ -216,7 +216,7 @@ Changes not staged for commit: Jasno vam pove, kako zavreči spremembe, ki ste jih naredili. Naredimo to, kar pravi: -[source,console] +[source,console?prompt=$] ---- $ git restore CONTRIBUTING.md $ git status diff --git a/book/02-git-basics/sections/viewing-history.asc b/book/02-git-basics/sections/viewing-history.asc index 33d856a0..e3b7701e 100644 --- a/book/02-git-basics/sections/viewing-history.asc +++ b/book/02-git-basics/sections/viewing-history.asc @@ -14,7 +14,7 @@ $ git clone https://github.com/schacon/simplegit-progit Ko poženete `git log` v tem projektu, bi morali dobiti izpis, ki izgleda nekako takole:(((git commands, log))) -[source,console] +[source,console?prompt=$] ---- $ git log commit ca82a6dff817ec66f44342007202690a93763949 @@ -45,7 +45,7 @@ Tukaj bomo prikazali nekaj najbolj popularnih. Ena najbolj uporabnih možnosti je `-p` ali `--patch`, ki prikaže razlike (izpis _popravkov_) predstavljene v vsaki potrditvi. Lahko uporabite tudi `-2`, ki omeji izpis na samo zadnja dva vnosa: -[source,console] +[source,console?prompt=$] ---- $ git log -p -2 commit ca82a6dff817ec66f44342007202690a93763949 @@ -94,7 +94,7 @@ To je zelo uporabno za pregled kode ali za hitro brskanje, kaj se je zgodilo med Z `git log` lahko uporabite tudi možnosti serije povzetkov. Na primer, če želite videti nekaj skrajšanih statistik za vsako potrditev, lahko uporabite možnost `--stat`: -[source,console] +[source,console?prompt=$] ---- $ git log --stat commit ca82a6dff817ec66f44342007202690a93763949 @@ -181,7 +181,7 @@ a11bef0 - Scott Chacon, 6 years ago : Initial commit Lahko se sprašujete, kaj je razlika med _avtorjem_ in _potrjevalcem_. Avtor (author) je oseba, ki je prvotno napisala delo, potrjevalec (commiter) je pa oseba, ki je zadnja dodala delo. -Torej, če ste poslali popravek projektu in eden izmed osrednjih članov ekipe doda ta popravek, oba dobita zasluge - vi kot avtor in osrednji član kot potrjevalec. +Torej, če ste poslali programski popravek projektu in eden izmed osrednjih članov ekipe doda ta popravek, oba dobita zasluge - vi kot avtor in osrednji član kot potrjevalec. To razlikovanje bomo pokrili nekoliko podrobneje v poglavju <>. Vrednosti možnosti `oneline` in `format` sta posebej uporabni z drugimi možnostmi `log` imenovanimi `--graph`. @@ -212,7 +212,7 @@ To so samo nekatere enostavne možnosti oblike izpisa za `git log` - jih je pa [cols="1,4",options="header"] |================================ | Možnost | Opis -| `-p` | Prikaži popravek, ki je bil predstavljen v vsaki potrditvi. +| `-p` | Prikaži programski popravek, ki je bil predstavljen v vsaki potrditvi. | `--stat` | Prikaži statistiko za spremenjene datoteke v vsaki potrditvi. | `--shortstat` | Prikaži samo vrstice sprememb/vstavkov/izbrisov iz ukaza `--stat`. | `--name-only` | Prikaži seznam spremenjenih datotek za informacijo potrditve. @@ -287,7 +287,7 @@ V <> bomo za vašo referenco izpisali te možnosti skupaj s še n Na primer, če želite videti, katere potrditve, ki so spremenile datoteke testiranja v zgodovini izvorne kode Git, je naredil Junio Hamano v mesesu oktobru 2008 in niso bile potrditve združevanja, lahko poženete nekaj takega:(((log filtering))) -[source,console] +[source,console?prompt=$] ---- $ git log --pretty="%h - %s" --author='Junio C Hamano' --since="2008-10-01" \ --before="2008-11-01" --no-merges -- t/ diff --git a/book/03-git-branching/sections/basic-branching-and-merging.asc b/book/03-git-branching/sections/basic-branching-and-merging.asc index fab533c4..ad7cb9a5 100644 --- a/book/03-git-branching/sections/basic-branching-and-merging.asc +++ b/book/03-git-branching/sections/basic-branching-and-merging.asc @@ -108,12 +108,12 @@ V tej združitvi boste opazili frazo "`fast-forward`". Ker je potrjevanje `C4`, kamor kaže veja `hotfix`, ki ste jo združili, direktno pred potrditvijo `C2, na kateri ste, Git enostavno premakne kazalec naprej. Povedano drugače, ko poskušate združiti eno potrditev z drugo, ki se jo lahko doseže s sledenjem zgodovine prve potrditve, Git poenostavi stvari, tako da prestavi kazalec naprej, ker ni nobenega različnega dela za združiti skupaj - to se imenuje "`fast-forward.`" -Vaša sprememba je sedaj v posnetku potrditve, ki kaže na vejo `master` in popravek lahko postavite. +Vaša sprememba je sedaj v posnetku potrditve, ki kaže na vejo `master`, in programski popravek lahko postavite. .Veja `master` je hitro previta naprej na `hotfix` image::images/basic-branching-5.png[Veja `master` je hitro previta naprej na `hotfix`] -Ko je vaš zelo pomemben hiter popravek postavljen, ste pripravljeni preklopiti nazaj k delu, ki ste ga delali, predenso vas zmotili. +Ko je vaš zelo pomemben hiter programski popravek postavljen, ste pripravljeni preklopiti nazaj k delu, ki ste ga delali, predenso vas zmotili. Vendar najprej boste izbrisali vejo `hotfix`, ker je ne potrebujete več - veja `master` kaže na isto mesto. Izbrišete jo lahko z možnostjo `-d` ukazu `git branch`: @@ -187,9 +187,9 @@ $ git branch -d iss53 (((merging, conflicts))) Občasno ta proces ne gre gladko. Če ste spremenili isti del neke datoteke na različna načina v dveh vejah, ki ju združujete skupaj, jih Git ne bo mogel gladko združiti. -Če je vaš popravek za težavo #53 spremenil isti del datoteke kot veja `hotfix`, boste dobili konflikt združevanja, ki izgleda nekako takole: +Če je vaš programski popravek za težavo #53 spremenil isti del datoteke kot veja `hotfix`, boste dobili konflikt združevanja, ki izgleda nekako takole: -[source,console] +[source,console?prompt=$] ---- $ git merge iss53 Auto-merging index.html @@ -201,7 +201,7 @@ Git ni avtomatično ustvaril potrditve združevanja. Ustavil je proces, dokler ne rešite konflikta. Če želite videti, katere datoteke niso združene na katerikoli točki po konfliktu združevanja, lahko poženete `git status`: -[source,console] +[source,console?prompt=$] ---- $ git status On branch master @@ -292,7 +292,7 @@ Changes to be committed: Če ste s tem zadovoljni in potrdite, da je bilo dano v področje priprave vse, kar je imelo konflikte, lahko vpišete `git commit`, da končate potrditev združevanja. Sporočilo potrditve privzeto izgleda nekako takole: -[source,console] +[source,console?prompt=$] ---- Merge branch 'iss53' diff --git a/book/03-git-branching/sections/branch-management.asc b/book/03-git-branching/sections/branch-management.asc index 9d778bef..f33c53d9 100644 --- a/book/03-git-branching/sections/branch-management.asc +++ b/book/03-git-branching/sections/branch-management.asc @@ -88,7 +88,7 @@ Kako to storiti? Lokalno preimenujte vejo z ukazom `git branch --move`: -[source, console] +[source,console] ---- $ git branch --move bad-branch-name corrected-branch-name ---- @@ -103,7 +103,7 @@ $ git push --set-upstream origin corrected-branch-name Sedaj si bomo na kratko ogledali, kje smo: -[source, console] +[source,console] ---- $ git branch --all * corrected-branch-name @@ -177,7 +177,7 @@ Zdaj imate pred seboj še nekaj nalog, ki jih morate opraviti, da dokončate pre Ko boste opravili vse te naloge in boste prepričani, da veja `main` deluje enako kot veja `master`, lahko izbrišete vejo `master`: -[source, console] +[source,console] ---- $ git push origin --delete master ---- diff --git a/book/03-git-branching/sections/nutshell.asc b/book/03-git-branching/sections/nutshell.asc index dbd1ab49..4e087d9d 100644 --- a/book/03-git-branching/sections/nutshell.asc +++ b/book/03-git-branching/sections/nutshell.asc @@ -77,7 +77,7 @@ image::images/head-to-master.png["HEAD, ki kaže na vejo"] To lahko enostavno pogledate, da poženete ukaz `git log`, ki vam prikaže, kam kazalci veje kažejo. Ta možnost se imenuje `--decorate`. -[source,console] +[source,console?prompt=$] ---- $ git log --oneline --decorate f30ab (HEAD -> master, testing) Add feature #32 - ability to add new formats to the central interface @@ -172,7 +172,7 @@ image::images/advance-master.png[Različna zgodovina] To lahko enostavno pogledate tudi z ukazom `git log`. Če poženete `git log --oneline --decorate --graph --all` bo izpisal zgodovino vaših potrditev, prikazal, kje so kazalci vej in kako se je vaša zgodovina spremenila. -[source,console] +[source,console?prompt=$] ---- $ git log --oneline --decorate --graph --all * c2b9e (HEAD, master) Made other changes diff --git a/book/03-git-branching/sections/rebasing.asc b/book/03-git-branching/sections/rebasing.asc index 6ee828cf..f756d77f 100644 --- a/book/03-git-branching/sections/rebasing.asc +++ b/book/03-git-branching/sections/rebasing.asc @@ -19,7 +19,7 @@ Izvede tri-načinsko združevanje med dvema zadnjima posnetkoma vej (`C3` in `C4 .Združitev za integracijo zgodovine različnega dela image::images/basic-rebase-2.png[Združitev za integracijo zgodovine različnega dela] -Vendar obstaja še drug način: vzamete vzamete popravek spremembe, ki je bil predstavljen v `C4` in ga ponovno uporabite na vrhu `C3`. +Vendar obstaja še drug način: vzamete vzamete programski popravek spremembe, ki je bil predstavljen v `C4` in ga ponovno uporabite na vrhu `C3`. V Gitu se to imenuje _ponovno baziranje_. Z ukazom `rebase` lahko vzamete vse spremembe, ki so bile potrjene na eni veji, in jih ponovite na drugi veji.(((git commands, rebase))) @@ -183,7 +183,7 @@ Precej gotovo je domnevati, da drug razvijalec ne želi imeti `C4` in `C6` v zgo Če *se* najdete v situaciji, kot je ta, ima Git nekaj dodatne čarobnosti, ki vam lahko pomaga. Če nekdo v vaši ekipi potisne spremembe, ki prepišejo delo, na katerem ste osnovali vaše delo, je vaš izziv ugotoviti, kaj je vaše in kaj so prepisali drugi. -Izkaže se, da poleg kontrolne vsote SHA-1 potrditve, Git preračuna tudi kontrolno vsoto, ki je osnovana samo kot popravek predstavljen v potrditvi. +Izkaže se, da poleg kontrolne vsote SHA-1 potrditve, Git preračuna tudi kontrolno vsoto, ki je osnovana samo kot programski popravek predstavljen v potrditvi. To se imenuje "`patch-id`". Če povlečete delo, ki je bilo prepisano in osnovano na vrhu nove potrditve vašega partnerja, lahko Git tudi pogostokrat uspešno ugotovi, kaj je unikatno vaše in to uporabi nazaj na vrhu nove veje. @@ -192,7 +192,7 @@ Na primer, če v prejšnjem scenariju namesto, da delate združevanje, ko ste na * Določil, katero delo je unikatno za vašo vejo (`C2`, `C3`, `C4`, `C6`, `C7`) * Določil, katere niso potrditve združevanja (`C2`, `C3`, `C4`) -* Določil, katere niso bile prepisane v ciljni veji (samo `C2` in `C3`, saj je `C4` enak popravek kot `C4'`) +* Določil, katere niso bile prepisane v ciljni veji (samo `C2` in `C3`, saj je `C4` enak programski popravek kot `C4'`) * Uporabil te potrditve na vrhu `teamone/master` Torej namesto rezultata, ki ga vidimo v <<_merge_rebase_work>>, bi dobili nekaj bolj takega, kot je <<_rebase_rebase_work>>. @@ -202,7 +202,7 @@ Torej namesto rezultata, ki ga vidimo v <<_merge_rebase_work>>, bi dobili nekaj image::images/perils-of-rebasing-5.png[Ponovno baziranje na osnovi prisilno potisnjenega ponovno baziranega dela] To deluje zgolj, če sta `C4` in `C4'`, ki ju je naredil vaš partner skoraj točno enaka popravka. -Drugače ponovno baziranje ne bo zmožno vedeti, da je duplikat in bo dodalo drug `C4` podoben popravek (ki ga verjetno ne bo uspelo uporabiti na gladek način, saj bi spremembe že bile vsaj nekako tam). +Drugače ponovno baziranje ne bo zmožno vedeti, da je duplikat in bo dodalo drug `C4` podoben programski popravek (ki ga verjetno ne bo uspelo uporabiti na gladek način, saj bi spremembe že bile vsaj nekako tam). To lahko tudi poenostavite s pogonom `git pull --rebase` namesto običajnega `git pull`. Lahko pa to naredite ročno z `git fetch`, kateremu v tem primeru sledi `git rebase teamone/master`. diff --git a/book/03-git-branching/sections/remote-branches.asc b/book/03-git-branching/sections/remote-branches.asc index ccb88120..971f1d94 100644 --- a/book/03-git-branching/sections/remote-branches.asc +++ b/book/03-git-branching/sections/remote-branches.asc @@ -67,7 +67,7 @@ Na ta način lahko uporabite zasebne veje za delo, ki ga ne želite deliti, in p Če imate vejo imenovano `serverfix`, na kateri želite delati z drugimi, jo lahko potisnete na enak način, kakor ste potisnili vašo prvo vejo. Poženite `git push `:(((git commands, push))) -[source,console] +[source,console?prompt=$] ---- $ git push origin serverfix Counting objects: 24, done. @@ -130,7 +130,7 @@ To vam da lokalno vejo, na kateri lahko delate, in se začne, kjer je `origin/se ==== Sledenje vej (((branches, tracking)))(((branches, upstream))) -Izvlečenje lokalne veje iz veje, ki sledi daljavi, avtomatično ustvari, kar se imenuje "`sledena veja`" oz. "`tracking branch`" (in veja, ki ji sledi, se imenuje "`upstream branch`"). +Izvlečenje lokalne veje iz veje, ki sledi daljavi, avtomatično ustvari, kar se imenuje "`sledena veja`" (ang."`tracking branch`") in veja, ki ji sledi, se imenuje "`upstream branch`". Sledene veje so lokalne veje, ki imajo direktno relacijo z oddaljeno vejo. Če ste na sledeni veji in vpišete `git pull`, Git avtomatsko ve, iz katerega strežnika prenesti in katero vejo združiti. diff --git a/book/04-git-server/sections/git-daemon.asc b/book/04-git-server/sections/git-daemon.asc index 862e2a3a..91fb2600 100644 --- a/book/04-git-server/sections/git-daemon.asc +++ b/book/04-git-server/sections/git-daemon.asc @@ -24,7 +24,7 @@ Ta proces lahko prikrijete na število načinov, odvisno od operacijskega sistem Ker je `systemd` najpogostejši zagonski sistem na modernih distribucijah Linuxa, ga lahko uporabite za ta namen. Enostavno dodate datoteko v `/etc/systemd/system/git-daemon.service` s sledečo vsebino: -[source,console] +[source,ini] ---- [Unit] Description=Start Git Daemon diff --git a/book/04-git-server/sections/protocols.asc b/book/04-git-server/sections/protocols.asc index 2528f172..a4afee1f 100644 --- a/book/04-git-server/sections/protocols.asc +++ b/book/04-git-server/sections/protocols.asc @@ -87,10 +87,10 @@ V bistvu za storitve, kot je GitHub, je URL, ki ga uporabljate za ogled repozito ===== Neumni HTTP (((protocols, dumb HTTP))) -Če se strežnik ne odzove s pametno Git HTTP storitvijo, se bo odjemalec Git poskušal vrniti k enostavnejšemu neumnemu oz. _Dumb_ protokolu HTTP. +Če se strežnik ne odzove s pametno Git HTTP storitvijo, se bo odjemalec Git poskušal vrniti k enostavnejšemu _neumnemu_ (ang. _Dumb_) protokolu HTTP. Neummni protokol pričakuje, da je goli repozitorij Git ponujen kot običajne datoteke s spletnega strežnika. Lepota neumnega protokola HTTP je enostavnost nastavitve. -V osnovi je vse, kar morate narediti, dati goli repozitorij Git pod vaš vrhnji dokumentni HTTP direktorij in nastaviti določeno kjuko `post-update` ter ste zaključili (glejte <>). +V osnovi je vse, kar morate narediti, dati goli repozitorij Git pod vaš vrhnji dokumentni direktorij HTTP in nastaviti določeno kjuko `post-update` ter ste zaključili (glejte <>). Na tej točki kdorkoli, ki lahko dostopa do spletnega strežnika, pod katerim ste dali repozitorij, lahko tudi klonira vaš repozitorij. Da omogočite bralni dostop do vašega repozitorija preko HTTP, naredite nekaj takega: diff --git a/book/05-distributed-git/sections/contributing.asc b/book/05-distributed-git/sections/contributing.asc index 8780e3a2..2be42680 100644 --- a/book/05-distributed-git/sections/contributing.asc +++ b/book/05-distributed-git/sections/contributing.asc @@ -23,7 +23,7 @@ Ali je sistem poročnika na mestu in ali jim morate najprej poslati vaše delo? Naslednja spremenljivka je vaš dostop potrditev. Potek dela, ki je zahtevan za prispevanje projektu je veliko bolj drugačen, če imate dostop pisanja k projektu, kot če ga nimate. Če nimate dostopa za pisanje, kako ima projekt raje, da sprejme prispevano delo? -Ali ima sploh politiko? +Ali ima sploh pravilnik? Koliko dela prispevate na določen čas? Kako pogosto prispevate? @@ -506,7 +506,7 @@ Prvi primer opisuje prispevanje preko razvejanja na gostiteljih Git, ki podpiraj Mnoge strane gostiteljev to podpirajo (vključno z GitHub, BitBucket, Google Code, repo.or.cz in ostalimi) in mnogi vzdrževalci projektov pričakujejo ta stil prispevanja. Naslednji razdelek se ukvarja s projekti, ki imajo raje sprejeti prispevane popravke preko e-pošte. -Najprej boste verjetno želeli klonirati glavni repozitorij, ustvariti tematsko vejo za popravek ali serijo popravkov, ki jih planirate prispevati in narediti delo tam. +Najprej boste verjetno želeli klonirati glavni repozitorij, ustvariti tematsko vejo za programski popravek ali serijo popravkov, ki jih planirate prispevati in narediti delo tam. Zaporedje izgleda v osnovi takole: [source,console] @@ -522,7 +522,7 @@ $ git commit [NOTE] ==== -Lahko boste želeli uporabiti `rebase -i`, da vaše delo stisnete v eno potrditev ali delo preuredite v potrditve, da naredite popravek enostavnejši za pregled razvijalcev - za več informacij o interaktivnem ponovnem baziranju glejte <>. +Lahko boste želeli uporabiti `rebase -i`, da vaše delo stisnete v eno potrditev ali delo preuredite v potrditve, da naredite programski popravek enostavnejši za pregled razvijalcev - za več informacij o interaktivnem ponovnem baziranju glejte <>. ==== Ko je delo vaše veje končano in ste pripravljeni prispevati nazaj vzdrževalcem, pojdite na prvotno stran projekta in kliknite na gumb "`Fork`", kar bo ustvarilo vašo lastno zapisljivo razvejitev projekta. @@ -657,7 +657,7 @@ $ git commit (((git commands, format-patch))) Sedaj imate dve potrditvi, ki ju želite poslati na e-poštni seznam. -Uporabili boste `git format-patch`, da generirate mbox oblikovane datoteke, ki jih lahko pošljete preko e-pošte na seznam - vsako potrditev pretvori v sporočilo e-pošte s prvo vrstico sporočila potrditve kot zadevo in preostanek sporočila plus popravek, ki ga potrditev predstavlja kot telo. +Uporabili boste `git format-patch`, da generirate mbox oblikovane datoteke, ki jih lahko pošljete preko e-pošte na seznam - vsako potrditev pretvori v sporočilo e-pošte s prvo vrstico sporočila potrditve kot zadevo in preostanek sporočila plus programski popravek, ki ga potrditev predstavlja kot telo. Dobra stvar pri tem je, da uporaba popravka generiranega iz e-pošte s `format-patch` ustrezno ohrani vse informacije potrditve. [source,console] @@ -708,7 +708,7 @@ Lahko tudi uredite te datoteke popravka, da dodate več informacij za seznam e-p Da to pošljete po e-pošti na e-poštni seznam, lahko bodisi prilepite datoteko v vaš e-poštni program, ali pa pošljete preko programa ukazne vrstice. Lepljenje teksta pogostokrat povzroča težave oblikovanja, posebej s "`pametnejšimi`" odjemalci, ki ne ohranjajo ustrezno novih vrstic in ostalih praznih znakov. Na srečo, Git ponuja orodje, ki vam pomaga poslati ustrezno oblikovane popravke preko IMAP, kar je za vas lahko enostavnejše. -Prikazali bomo, kako poslati popravek preko Gmaila, kar je e-poštni agent, ki ga najbolje poznamo; preberete lahko podrobna navodila za število poštnih programov na koncu zgoraj omenjene datoteke `Documentation/SubmittingPatches` v izvorni kodi Git. +Prikazali bomo, kako poslati pogramski popravek preko Gmaila, kar je e-poštni agent, ki ga najbolje poznamo; preberete lahko podrobna navodila za število poštnih programov na koncu zgoraj omenjene datoteke `Documentation/SubmittingPatches` v izvorni kodi Git. (((git commands, config)))(((email))) Najprej morate nastaviti razdelek imap v vaši datoteki `~/.gitconfig`. @@ -738,9 +738,9 @@ sending 2 messages 100% (2/2) done ---- -V tem trenutku, bi morali imeti dostop do vaše mape osnutkov (Drafts), lahko spremenite polje To na seznam e-pošte, na katerega pošiljate popravek, opcijsko CC za vzdrževalca ali osebo odgovorno za ta razdelek in lahko ga pošljete. +V tem trenutku, bi morali imeti dostop do vaše mape osnutkov (Drafts), lahko spremenite polje To na seznam e-pošte, na katerega pošiljate programski popravek, opcijsko CC za vzdrževalca ali osebo odgovorno za ta razdelek in lahko ga pošljete. -Popravek lahko pošljete tudi preko strežnika SMTP. +Programski popravek lahko pošljete tudi preko strežnika SMTP. Kot prej, lahko nastavite vsako vrednost ločeno s serijo ukazov `git config`, ali pa jih dodate ročno v razdelek sendemail vaše datoteke `~/.gitconfig`: [source,ini] @@ -765,7 +765,7 @@ Who should the emails be sent to? jessica@example.com Message-ID to be used as In-Reply-To for the first email? y ---- -Nato Git izpljune kopico informacij dnevnika, kar izgleda nekako takole za vsak popravek, ki ga pošiljate: +Nato Git izpljune kopico informacij dnevnika, kar izgleda nekako takole za vsak programski popravek, ki ga pošiljate: [source,text] ---- diff --git a/book/05-distributed-git/sections/distributed-workflows.asc b/book/05-distributed-git/sections/distributed-workflows.asc index 6768a145..c7031abc 100644 --- a/book/05-distributed-git/sections/distributed-workflows.asc +++ b/book/05-distributed-git/sections/distributed-workflows.asc @@ -44,12 +44,12 @@ Nato lahko vzdrževalcu glavnega projekta pošljete zahtevek, da povleče vaše Vzdrževalec lahko nato doda vaš repozitorij kot daljavo, testira vaše spremembe lokalno, jih združi v svojo vejo in potisne nazaj v svoj repozitorij. Proces deluje sledeče (glejte <>): -1. Vzdrževalec projekta potisne v svoj javni repozitorij. -2. Prispevalec klonira ta repozitorij in naredi spremembe. -3. Prispevalec potisne v svojo lastno kopijo. -4. Prispevalec pošlje vzdrževalcu e-pošto, kjer ga prosi, da povleče spremembe. -5. Vzdrževalec doda repozitorij prispevalca kot daljavo in združi lokalno. -6. Vzdrževalec potisne združene spremembe v glavni repozitorij. +1. Vzdrževalec projekta potisne v svoj javni repozitorij. +2. Prispevalec klonira ta repozitorij in naredi spremembe. +3. Prispevalec potisne v svojo lastno kopijo. +4. Prispevalec pošlje vzdrževalcu e-pošto, kjer ga prosi, da povleče spremembe. +5. Vzdrževalec doda repozitorij prispevalca kot daljavo in združi lokalno. +6. Vzdrževalec potisne združene spremembe v glavni repozitorij. [[wfdiag_b]] .Potek dela s povezovalnim upraviteljem @@ -70,11 +70,11 @@ Vsi poročniki imajo enega upravitelja integracije znanega kot dobronamerni dikt Dobronamerni diktator potisne iz svojega direktorija na referenčni repozitorij, iz katerega morajo vsi sodelavci povleči. Proces deluje takole (glejte <>): -1. Splošni razvijalci delajo na svojih tematskih vejah in ponovno bazirajo svoje delo glede na `master`. - Veja `master` je veja referenčnega repozitorija, na katerega diktator potiska. -2. Poročniki združijo razvijalčeve tematske veje v svojo vejo `master`. -3. Diktator združi poročnikove veje `master` v diktatorjevo vejo `master`. -4. Diktator potisne to vejo `master` v referenčni repozitorij, da lahko ostali razvijalci ponovno bazirajo na njem. +1. Splošni razvijalci delajo na svojih tematskih vejah in ponovno bazirajo svoje delo glede na `master`. + Veja `master` je veja referenčnega repozitorija, na katerega diktator potiska. +2. Poročniki združijo razvijalčeve tematske veje v svojo vejo `master`. +3. Diktator združi poročnikove veje `master` v diktatorjevo vejo `master`. +4. Diktator potisne to vejo `master` v referenčni repozitorij, da lahko ostali razvijalci ponovno bazirajo na njem. [[wfdiag_c]] .Potek dela z dobronamernim diktatorjem diff --git a/book/05-distributed-git/sections/maintaining.asc b/book/05-distributed-git/sections/maintaining.asc index d6daccd8..8fd85832 100644 --- a/book/05-distributed-git/sections/maintaining.asc +++ b/book/05-distributed-git/sections/maintaining.asc @@ -9,7 +9,7 @@ Bodisi če vzdržujete kanonični repozitorij ali želite pomagati s potrditvijo (((branches, topic))) Ko razmišljate o integraciji novega dela, je v splošnem dobra ideja poskusiti na _tematski veji_ - začasni veji, posebej narejeni za preskušanje tega novega dela. -Na ta način je enostavno prilagoditi popravek individualno, ali pa ga pustiti, če ne deluje, dokler nimate časa se vrniti nazaj k njemu. +Na ta način je enostavno prilagoditi programski popravek individualno, ali pa ga pustiti, če ne deluje, dokler nimate časa se vrniti nazaj k njemu. Če ustvarite enostavno ime veje na osnovi teme dela, katerega boste poskusili, kot je `ruby_client` ali nekaj podobno opisljivega, si lahko enostavno zapomnite, če jo morate opustiti za nekaj časa in se kasneje vrniti. Vzdrževalec projekta Git tudi stremi k poimenovanju teh vej v imenskem prostoru - kot je `sc/ruby_client`, kjer je `sc` kratica za osebo, ki je prispevala delo. Kot se boste spomnili, lahko ustvarite vejo na osnovi vaše veje `master` takole: @@ -32,14 +32,14 @@ Sedaj ste pripravljeni dodati prispevano delo, ki ste ga prejeli, v to tematsko ==== Uporaba popravkov iz e-pošte (((email, applying patches from))) -Če prejmete popravek, ki ga morate integrirati v vaš projekt, preko e-pošte, morate uporabiti popravek na vaši tematski veji, da ga ocenite. +Če prejmete programski popravek, ki ga morate integrirati v vaš projekt, preko e-pošte, morate uporabiti popravek na vaši tematski veji, da ga ocenite. Na voljo sta dva načina za uporabo e-poštnega popravka: z `git apply` ali z `git am`. ===== Uporaba popravka z `apply` (((git commands, apply))) -Če prejmete popravek od nekoga, ki ga je generiral z `git diff` ali kakšno variacijo Unix ukaza `diff` (kar ni priporočljivo; glejte naslednji razdelek), ga lahko uporabite z ukazom `git apply`. -Predpostavljamo, da ste shranili popravek v `/tmp/patch-ruby-client.patch`, lahko uporabite popravek sledeče: +Če prejmete programski popravek od nekoga, ki ga je generiral z `git diff` ali kakšno variacijo Unix ukaza `diff` (kar ni priporočljivo; glejte naslednji razdelek), ga lahko uporabite z ukazom `git apply`. +Predpostavljamo, da ste shranili programski popravek v `/tmp/patch-ruby-client.patch`, lahko uporabite popravek sledeče: [source,console] ---- @@ -47,13 +47,13 @@ $ git apply /tmp/patch-ruby-client.patch ---- To spremeni datoteke v vašem delovnem direktoriju. -Je skoraj identično pogonu ukaza `patch -p1`, da uporabite popravek, vendar je bolj paranoično in sprejema manj nejasna ujemanja kot popravek. +Je skoraj identično pogonu ukaza `patch -p1`, da uporabite programski popravek, vendar je bolj paranoično in sprejema manj nejasna ujemanja kot popravek. Upravlja tudi dodajanja datotek, brisanja in preimenovanja, če so opisana v obliki `git diff`, kar `patch` ne naredi. Na koncu `git apply` je model "`uporabi vse ali prekliči vse`", kjer je bodisi vse uporabljeno ali nič, z razliko, kjer `patch` lahko delno uporablja datoteke popravkov, kar pusti vaš delovni direktorij v čudnem stanju. `git apply` je splošno veliko bolj konzervativen kot `patch`. Ne bo ustvaril potrditve za vas - po tem, ko ga poženete, morate ročno dati v področje priprave in potrditi predstavljene spremembe. -`git apply` lahko uporabite tudi, da vidite, če se popravek lahko gladko uporabi, preden ga poskusite dejansko uporabiti - poženete lahko `git apply --check` s popravkom: +`git apply` lahko uporabite tudi, da vidite, če se programski popravek lahko gladko uporabi, preden ga poskusite dejansko uporabiti - poženete lahko `git apply --check` s popravkom: [source,console] ---- @@ -62,18 +62,18 @@ error: patch failed: ticgit.gemspec:1 error: ticgit.gemspec: patch does not apply ---- -Če ni nobenega izpisa, potem bi se moral popravek uporabiti gladko. +Če ni nobenega izpisa, potem bi se moral programski popravek uporabiti gladko. Ta ukaz se tudi konča z ne-ničelnim statusom, če preverjanje ni uspešno, tako da ga lahko uporabite v skriptah, če želite. [[_git_am]] ===== Uporaba popravka z `am` (((git commands, am))) -Če je uporabnik, ki prispeva, uporabnik Git in je bilo dovolj dobro uporabiti ukaz `format-patch` za generiranje njegovega popravka, potem je vaše delo enostavnejše, saj popravek vsebuje informacije avtorja in sporočilo potrditve za vas. +Če je uporabnik, ki prispeva, uporabnik Git in je bilo dovolj dobro uporabiti ukaz `format-patch` za generiranje njegovega popravka, potem je vaše delo enostavnejše, saj programski popravek vsebuje informacije avtorja in sporočilo potrditve za vas. Če lahko, vzpodbudite vaše prispevalce, da uporabljajo `format-patch` namesto `diff` za generiranje popravkov za vas. `git apply` bi morali uporabiti samo pri opuščenih popravkih in podobnih stvareh. -Da uporabite popravek generiran s `format-patch`, uporabite `git am` (ukaz se imenuje `am`, ker pomeni "uporabi (apply) - serijo popravkov iz mailboxa"). +Da uporabite programski popravek generiran s `format-patch`, uporabite `git am` (ukaz se imenuje `am`, ker pomeni "uporabi (apply) - serijo popravkov iz mailboxa"). Tehnično je `git am` zgrajen, da prebere datoteko mbox, ki je enostaven tekstovni format za shranjevanje enega ali več e-poštnih sporočil v eni tekstovni datoteki. Izgleda nekako sledeče: @@ -88,7 +88,7 @@ Limit log functionality to the first 20 ---- To je začetek izhodnega zapisa ukaza `git format-patch`, ki ste ga videli v prejšnjem odseku; predstavlja tudi veljaven e-poštni format mbox. -Če vam nekdo pravilno pošlje popravek z uporabo ukaza `git send-email` in ga prenesete v obliki mbox, lahko `git am` usmerite v datoteko mbox in začne uporabljati vse popravke, ki jih vidi. +Če vam nekdo pravilno pošlje programski popravek z uporabo ukaza `git send-email` in ga prenesete v obliki mbox, lahko `git am` usmerite v datoteko mbox in začne uporabljati vse popravke, ki jih vidi. Če uporabljate odjemalca pošte, ki lahko več e-poštnih sporočil shranjuje v obliki mbox, lahko celotno serijo popravkov shranite v datoteko in nato uporabite `git am`, da jih uporabite enega za drugim. Če pa je nekdo naložil datoteko s popravkom, ki je bila ustvarjena prek ukaza `git format-patch` v sistem za beleženje težav ali kaj podobnega, lahko datoteko shranite lokalno in jo nato prenesete v `git am`, da jo uporabite: @@ -99,9 +99,9 @@ $ git am 0001-limit-log-function.patch Applying: Add limit to log function ---- -Vidite lahko, da se je popravek uporabil brez težav in samodejno ustvaril novo potrditev za vas. +Vidite lahko, da se je programski popravek uporabil brez težav in samodejno ustvaril novo potrditev za vas. Informacije o avtorju so vzete iz glav `From` in `Date` v e-pošti, sporočilo potrditve pa je vzeto iz `Subject` in telesa (pred popravkom) e-pošte. -Če je bil na primer ta popravek uporabljen iz zgornjega primera mbox, bi bila ustvarjena potrditev nekaj podobnega temu: +Če je bil na primer ta programski popravek uporabljen iz zgornjega primera mbox, bi bila ustvarjena potrditev nekaj podobnega temu: [source,console] ---- @@ -117,11 +117,11 @@ CommitDate: Thu Apr 9 09:19:06 2009 -0700 Limit log functionality to the first 20 ---- -Informacije `Commit` kažejo osebo, ki je uporabila popravek, in čas uporabe. -Informacije `Author` pa kažejo na osebo, ki je prvotno ustvarila popravek in kdaj je bil prvotno ustvarjen. +Informacije `Commit` kažejo osebo, ki je uporabila programski popravek, in čas uporabe. +Informacije `Author` pa kažejo na osebo, ki je prvotno ustvarila programski popravek in kdaj je bil prvotno ustvarjen. -Vendar lahko se zgodi, da se popravek ne bo uporabil brez težav. -Morda se je vaša glavna veja preveč oddaljila od veje, iz katere je bil popravek zgrajen, ali pa je popravek odvisen od drugega popravka, ki ga še niste uporabili. +Vendar lahko se zgodi, da se programski popravek ne bo uporabil brez težav. +Morda se je vaša glavna veja preveč oddaljila od veje, iz katere je bil programski popravek zgrajen, ali pa je popravek odvisen od drugega popravka, ki ga še niste uporabili. V tem primeru bo proces `git am` spodletel in vas vprašal, kaj želite storiti: [source,console] @@ -137,7 +137,7 @@ To restore the original branch and stop patching run "git am --abort". ---- Ta ukaz vstavi označevalce konfliktov v datoteke, s katerimi ima težave, podobno kot pri operaciji združevanja ali ponovnem baziranju, ki ima konflikte. -To težavo lahko rešite na podoben način - uredite datoteko, da rešite konflikt, shranite novo datoteko in nato zaženite `git am --resolved`, da nadaljujete na naslednji popravek: +To težavo lahko rešite na podoben način - uredite datoteko, da rešite konflikt, shranite novo datoteko in nato zaženite `git am --resolved`, da nadaljujete na naslednji programski popravek: [source,console] ---- @@ -148,8 +148,8 @@ Applying: See if this helps the gem ---- Če želite, da Git poskusi bolj inteligentno rešiti konflikt, mu lahko podate možnost `-3`, kjer Git poskuša izvesti trosmerno združevanje. -Ta možnost ni privzeto vklopljena, ker ne deluje, če potrditve, ki jih navaja popravek, ni v vašem repozitoriju. -Če imate to potrditev - če je bil popravek ustvarjen na podlagi javne potrditve - je možnost `-3` na splošno veliko bolj inteligentna pri uporabi konfliktnega popravka: +Ta možnost ni privzeto vklopljena, ker ne deluje, če potrditve, ki jih navaja programski popravek, ni v vašem repozitoriju. +Če imate to potrditev - če je bil programski popravek ustvarjen na podlagi javne potrditve - je možnost `-3` na splošno veliko bolj inteligentna pri uporabi konfliktnega popravka: [source,console] ---- @@ -162,8 +162,8 @@ Falling back to patching base and 3-way merge... No changes -- Patch already applied. ---- -V tem primeru bi bil popravek brez možnosti `-3` obravnavan kot konflikt. -Ker je bila uporabljena možnost `-3`, se je popravek uporabil brez težav. +V tem primeru bi bil programski popravek brez možnosti `-3` obravnavan kot konflikt. +Ker je bila uporabljena možnost `-3`, se je programski popravek uporabil brez težav. Če uporabljate več popravkov iz mboxa, lahko ukaz `am` zaženete tudi v interaktivnem načinu, ki se ustavi pri vsakem popravku, ki ga najde, in vpraša, ali ga želite uporabiti: @@ -177,7 +177,7 @@ See if this helps the gem Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept all ---- -To je koristno, če imate shranjenih več popravkov, saj si lahko popravek najprej ogledate, če se ne spomnite, kaj predstavlja, ali pa ga ne uporabite, če ste ga že uporabili. +To je koristno, če imate shranjenih več popravkov, saj si lahko programski popravek najprej ogledate, če se ne spomnite, kaj predstavlja, ali pa ga ne uporabite, če ste ga že uporabili. Ko so vsi popravki za vašo temo uporabljeni in potrjeni v vaši razvojnem veji, lahko izberete, ali jih želite integrirati v dolgotrajno vejo in na kakšen način. @@ -199,7 +199,7 @@ $ git checkout -b rubyclient jessica/ruby-client Če vam pozneje ponovno pošlje e-pošto z drugo vejo, ki vsebuje drugo odlično funkcionalnost, jo lahko neposredno prenesete s `fetch` in `checkout` saj imate že nastavljen oddaljeni vir. To je najbolj uporabno, če redno sodelujete s to osebo. -Če nekdo prispeva le občasno kakšen popravek, je sprejemanje prek e-pošte manj časovno potratno, kot zahtevati, da vsakdo zažene svoj lastni strežnik in nenehno dodaja in odstranjuje daljave, da bi dobili nekaj sprememb. +Če nekdo prispeva le občasno kakšen programski popravek, je sprejemanje prek e-pošte manj časovno potratno, kot zahtevati, da vsakdo zažene svoj lastni strežnik in nenehno dodaja in odstranjuje daljave, da bi dobili nekaj sprememb. Verjetno tudi ne želite imeti na stotine daljav, vsake za vsako osebo, ki prispeva le eno ali dve spremembi. Vendar pa lahko skripte in gostujoče storitve to olajšajo - odvisno je predvsem od tega, kako razvijate in kako razvijajo vaši sodelavci. @@ -377,7 +377,7 @@ Ko imate delo v tematski veji in ste ugotovili, da ga želite integrirati, se pr (((git commands, cherry-pick))) Drugi način za premikanje vpeljanega dela iz ene veje v drugo je t.i. izbiranje najboljšega (ang. "cherry picking"). Izbiranje najboljšega v Gitu je podobno ponovnem baziranju za eno samo potrditev. -Vzame popravek, ki je bil uveden v eni potrditvi, in ga poskuša ponovno uporabiti na veji, na kateri se trenutno nahajate. +Vzame programski popravek, ki je bil uveden v eni potrditvi, in ga poskuša ponovno uporabiti na veji, na kateri se trenutno nahajate. To je uporabno, če imate na veji več potrditev in želite integrirati le eno od njih, ali če imate samo eno potrditev na veji in bi jo raje izbrali kot najboljšo namesto ponovnega baziranja. Na primer, recimo, da imate projekt, ki izgleda tako: @@ -408,7 +408,7 @@ Sedaj lahko odstranite vašo tematsko vejo in opustite potrditve, ki jih niste Če delate veliko združevanja in ponovnega baziranja, ali vzdržujete dolgotrajno tematsko vejo, ima Git lastnost, ki se imenuje "`rerere`", ki je lahko koristna. Rerere pomeni "`reuse recorded resolution`" - je način bližnjice ročnega reševanja konflikta. -Ko je rerere omogočen, bo Git obdržal skupek slik pred in po iz uspešnih združitev in če opazi, da gre za konflikt, ki izgleda točno tak kot nek, ki ste ga že popravili, bo enostavno samo uporabil popravek od zadnjič brez, da vas pri tem z njim moti. +Ko je rerere omogočen, bo Git obdržal skupek slik pred in po iz uspešnih združitev in če opazi, da gre za konflikt, ki izgleda točno tak kot nek, ki ste ga že popravili, bo enostavno samo uporabil programski popravek od zadnjič brez, da vas pri tem z njim moti. Ta lastnost prihaja v dveh delih: konfiguracijska nastavitev in ukaz. Konfiguracijska nastavitev je `rerere.enabled` in je dovolj priročna, da jo dodate v vaše globalne nastavitve: diff --git a/book/06-github/sections/1-setting-up-account.asc b/book/06-github/sections/1-setting-up-account.asc index 3b266d9b..580156c9 100644 --- a/book/06-github/sections/1-setting-up-account.asc +++ b/book/06-github/sections/1-setting-up-account.asc @@ -83,7 +83,7 @@ Zadnji naslov je nepreverjen, kar pomeni, da ga ne morate narediti kot primarneg ==== Dvostopenjsko overjanje -Na koncu, bi morali za dodatno varnost zagotovo nastaviti dvostopenjsko overjanje oz. "`2FA`". +Na koncu, bi morali za dodatno varnost zagotovo nastaviti dvostopenjsko overjanje ali "`2FA`". Dvostopenjsko overjanje je mehanizem overjanja, ki postaja zadnje čase bolj in bolj popularen, saj ublaži tveganje ogroženja vašega računa, če je vaše geslo kakorkoli ukradeno. Vklop bo naredil, da vas GitHub vpraša za overitev na dva različna načina, torej če je en način ogrožen, napadalec ne bo uspel dostopati do vašega računa. diff --git a/book/06-github/sections/2-contributing.asc b/book/06-github/sections/2-contributing.asc index 911f728c..a29c9a70 100644 --- a/book/06-github/sections/2-contributing.asc +++ b/book/06-github/sections/2-contributing.asc @@ -358,7 +358,7 @@ Postavitev seznama v težavo ali zahtevek potega običajno pomeni, da želite te Seznam opravil lahko ustvarite tako: -[source,text] +[source,markdown] ---- - [X] Write the code - [ ] Write all the tests @@ -393,7 +393,7 @@ Pogosto se to uporablja tudi za dodajanje primerne kode o tem, kaj ne deluje, al Da dodate delček kode, ga morate "`ograditi`" v leve črtice. -[source,text] +[source,markdown] ---- ```java for(int i=0 ; i < 5 ; i++) @@ -418,7 +418,7 @@ Dejansko je tako običajno in uporabno, da obstaja bližnjica na tipkovnici. Citati izgledajo nekako takole: -[source,text] +[source,markdown] ---- > Whether 'tis Nobler in the mind to suffer > The Slings and Arrows of outrageous Fortune, @@ -446,7 +446,7 @@ image::images/markdown-06-emoji-complete.png[Samodopolnjevalec emodžijev v delo Emojiji imajo obliko `::` kjerkoli v komentarju. Na primer, napišete lahko nekaj takega: -[source,text] +[source,markdown] ---- I :eyes: that :bug: and I :cold_sweat:. diff --git a/book/06-github/sections/5-scripting.asc b/book/06-github/sections/5-scripting.asc index 8f7077c1..5894b3fd 100644 --- a/book/06-github/sections/5-scripting.asc +++ b/book/06-github/sections/5-scripting.asc @@ -125,7 +125,7 @@ Najosnovnejša stvar, ki jo lahko naredite, je enostaven zahtevek GET na končni To je lahko uporabnik ali informacija samo za branje na odprto kodnem projektu. Na primer, če želimo vedeti več o uporabniku imenovanem "`schacon`", lahko poženemo nekaj takega: -[source,javascript] +[source,console?prompt=$] ---- $ curl https://api.github.com/users/schacon { @@ -144,7 +144,7 @@ $ curl https://api.github.com/users/schacon Na voljo je cela tona končnih točk, kakršna je ta, da se dobi informacije o organizacijah, projektih, težavah, potrditvah - skoraj karkoli, kar lahko javno vidite na GitHubu. API lahko uporabite celo za izpis poljubnega Markdowna, ali da najdete predlogo `.gitignore`. -[source,javascript] +[source,console?prompt=$] ---- $ curl https://api.github.com/gitignore/templates/Java { @@ -192,7 +192,7 @@ Torej uporabimo ga, da naredimo komentar na eni izmed vaših težav. Predpostavimo, da želite pustiti komentar na določeni težavi, Issue #6. Da to naredite, moramo narediti zahtevek HTTP POST na `repos///issues//comments` z žetonom, ki ste ga ravnokar generirali, kot glavo overitve. -[source,javascript] +[source,console?prompt=$] ---- $ curl -H "Content-Type: application/json" \ -H "Authorization: token TOKEN" \ diff --git a/book/07-git-tools/sections/interactive-staging.asc b/book/07-git-tools/sections/interactive-staging.asc index a1413977..6357b081 100644 --- a/book/07-git-tools/sections/interactive-staging.asc +++ b/book/07-git-tools/sections/interactive-staging.asc @@ -139,10 +139,10 @@ S temi osnovnimi ukazi lahko uporabite interaktivni način za dodajanje in tako Možno je narediti tudi, da Git doda v področje priprave samo posamezne dele datotek, ne pa celotnih datotek. Na primer, če naredite dve spremembi v datoteki `simplegit.rb` in želite dodati eno spremembo v področje priprave, druge pa ne, to storite v Gitu zelo enostavno. -V istem interaktivnem ukazu, kot je pojasnjeno v prejšnjem odstavku, vtipkajte `p` ali `5` (za popravek). +V istem interaktivnem ukazu, kot je pojasnjeno v prejšnjem odstavku, vtipkajte `p` ali `5` (za programski popravek). Git vas bo vprašal, katere datoteke želite delno dodati v področje priprave, nato pa vam bo za vsak odsek izbrane datoteke prikazal delček razlike datoteke in vas enega za drugim vprašal, ali ga želite dodati v področje priprave: -[source,console] +[source,diff] ---- diff --git a/lib/simplegit.rb b/lib/simplegit.rb index dd5ecc4..57399e0 100644 diff --git a/book/07-git-tools/sections/rerere.asc b/book/07-git-tools/sections/rerere.asc index 7f22dec0..55b5f992 100644 --- a/book/07-git-tools/sections/rerere.asc +++ b/book/07-git-tools/sections/rerere.asc @@ -79,7 +79,7 @@ hello.rb Z ukazom `git rerere diff` lahko prikažete trenutno stanje reševanja - s čim ste začeli, da bi rešili konflikt, in s čim ste ga rešili. -[source,console] +[source,console?prompt=$] ---- $ git rerere diff --- a/hello.rb diff --git a/book/07-git-tools/sections/reset.asc b/book/07-git-tools/sections/reset.asc index fbeb5c34..95cca244 100644 --- a/book/07-git-tools/sections/reset.asc +++ b/book/07-git-tools/sections/reset.asc @@ -12,7 +12,7 @@ Lažji način razmišljanja o `reset` in `checkout` je skozi mentalni okvir Gita S pojmom "`drevo`" tukaj dejansko mislimo na "`zbirko datotek`", ne nujno na podatkovno strukturo. Obstajajo nekateri primeri, kjer indeks ne deluje točno kot drevo, vendar je za naše namene za zdaj lažje razmišljati o njem na ta način. -Git kot sistem upravlja in manipulira s tremi drevesi v svojem normalnem delovanju: +Git v svojem normalnem delovanju kot sistem upravlja in manipulira s tremi drevesi: [cols="1,2",options="header"] |================================ @@ -52,7 +52,7 @@ Gitova ukaza `cat-file` in `ls-tree` sta ukaza "`napeljave`", ki se uporabljata ===== Indeks _Indeks_ je vaša *naslednja predlagana potrditev*. -Za ta koncept smo se sklicevali tudi kot na Gitovo "`področje priprave`", saj si ga Git ogleda, ko zaženete ukaz `git commit`. +Ta koncept smo označevali tudi kot Gitovo "`področje priprave`", saj si ga Git ogleda, ko zaženete ukaz `git commit`. Git napolni ta indeks s seznamom vsebine datotek, ki so bile nazadnje izvlečene v vaš delovni direktorij, in kako so izgledale, ko so bile prvotno izvlečene. Nato nekatere od teh datotek nadomestite z novimi različicami in `git commit` to pretvori v drevo za novo potrditev. @@ -72,7 +72,7 @@ Indeks tehnično gledano ni drevesna struktura - dejansko je implementiran kot s ===== Delovni direktorij Nazadnje imate vaš _delovni direktorij_ (ki se pogosto imenuje tudi "`delovno drevo`"). -Drugi dve drevesi shranjujeta svojo vsebino na učinkovit, vendar nepraktičen način v mapi `.git`. +Drugi dve drevesi shranjujeta svojo vsebino na učinkovit, vendar nepraktičen način v direktoriju `.git`. Delovni direktorij jih razpakira v dejanske datoteke, kar vam omogoča lažje urejanje. Delovni direktorij si lahko predstavljate kot *peskovnik*, kjer lahko preizkusite spremembe, preden jih potrdite v področje priprave (indeks) in nato v zgodovino. @@ -92,23 +92,27 @@ $ tree Običajni način dela z Gitom je zabeležiti posnetke vašega projekta v zaporedno boljša stanja z manipulacijo teh treh dreves. -image::images/reset-workflow.png[] +.Gitov običajni potek dela +image::images/reset-workflow.png[Gitov običajni potek dela] -Predstavljajmo si ta proces: recimo, da vstopite v novo mapo, ki vsebuje eno samo datoteko. +Predstavljajmo si ta proces: recimo, da vstopite v nov direktorij, ki vsebuje eno samo datoteko. To imenujemo *v1* datoteke in jo bomo označili z modro barvo. Sedaj zaženemo `git init`, kar bo ustvarilo repozitorij Git z referenco glave (HEAD), ki kaže na nerojeno vejo `master`. -image::images/reset-ex1.png[] +.Novo inicializirani repozitorij Git z datoteko izven področja priprave v delovnem direktoriju +image::images/reset-ex1.png[Novo inicializirani repozitorij Git z datoteko izven področja priprave v delovnem direktoriju] V tem trenutku ima vsebino le drevo delovnega direktorija. Zdaj želimo potrditi to datoteko, zato uporabimo `git add`, da vsebino v delovnem direktoriju kopiramo v indeks. -image::images/reset-ex2.png[] +.`git add` kopira datoteko v indeks +image::images/reset-ex2.png[`git add` kopira datoteko v indeks] Nato zaženemo `git commit`, ki sprejme vsebino indeksa in jo shrani kot trajni posnetek, ustvari objekt potrditve, ki kaže na ta posnetek, in posodobi `master`, da kaže na to potrditev. -image::images/reset-ex3.png[] +.Korak `git commit` +image::images/reset-ex3.png[Korak `git commit`] Če zaženemo `git status`, ne bomo videli sprememb, saj so vsa tri drevesa enaka. @@ -116,17 +120,20 @@ Sedaj želimo spremeniti to datoteko in jo potrditi. Gremo skozi enak postopek; najprej spremenimo datoteko v našem delovnem direktoriju. Imenujmo jo *v2* datoteke in jo označimo z rdečo barvo. -image::images/reset-ex4.png[] +.Repozitorij Git s spremenjeno datoteko v delovnem direktoriju +image::images/reset-ex4.png[Repozitorij Git s spremenjeno datoteko v delovnem direktoriju] Če zdaj zaženemo `git status`, bomo videli datoteko v rdeči barvi z napisom "`Changes not staged for commit`", ker se ta vnos razlikuje med indeksom in delovnim direktorijem. -Nato zaženemo `git add`, da jo damo v področje priprave v naš indeks. +Nato zaženemo `git add`, da jo damo v področje priprave (v naš indeks). -image::images/reset-ex5.png[] +.Dodajanje spremembe v področje priprave (indeks) +image::images/reset-ex5.png[Dodajanje spremembe v področje priprave (indeks)] Če zaženemo `git status`, bomo trenutno videli datoteko v zeleni barvi pod "`Changes to be committed`", ker se indeks in HEAD razlikujeta - to pomeni, da se naša naslednja predlagana potrditev razlikuje od naše zadnje potrditve. Na koncu zaženemo `git commit`, da zaključimo potrjevanje. -image::images/reset-ex6.png[] +.Korak `git commit` s spremenjeno datoteko +image::images/reset-ex6.png[Korak `git commit` s spremenjeno datoteko] Zdaj nam `git status` ne bo dal nobenega izpisa, saj so vsa tri drevesa spet enaka. @@ -140,9 +147,10 @@ Ukaz `reset` ima več smisla, če ga gledamo v tem kontekstu. Za namene teh primerov recimo, da smo spet spremenili datoteko `file.txt` in jo tretjič potrdili. Tako sedaj izgleda naša zgodovina: -image::images/reset-start.png[] +.Repozitorij Git s tremi potrditvami +image::images/reset-start.png[Repozitorij Git s tremi potrditvami] -Sedaj si poglejmo, kaj `reset` točno naredi, ko ga kličemo. +Sedaj si poglejmo, kaj `reset` točno naredi, ko ga pokličemo. Neposredno spreminja ta tri drevesa na preprost in predvidljiv način. Izvede do tri osnovne operacije. @@ -152,13 +160,14 @@ Prva stvar, ki jo `reset` naredi, je premik tistega, na kar kaže HEAD. To ni enako spreminjanju samega HEAD (to naredi ukaz `checkout`); `reset` premakne vejo, na katero kaže HEAD. To pomeni, da če je HEAD nastavljen na vejo `master` (torej se trenutno nahajate na veji `master`), bo izvajanje ukaza `git reset 9e5e6a4` najprej spremenilo `master`, da kaže na `9e5e6a4`. -image::images/reset-soft.png[] +.Mehka ponastavitev +image::images/reset-soft.png[Mehka ponastavitev] Ne glede na to, katero obliko `reset` z določeno potrditvijo uporabite, je to prva stvar, ki jo bo vedno poskusil narediti. Z uporabo `reset --soft` se bo postopek tam preprosto ustavil. Sedaj si vzemite trenutek in si oglejte ta diagram ter ugotovite, kaj se je zgodilo: v bistvu se je preklical zadnji ukaz `git commit`. -Ko zaženete `git commit`, Git ustvari novo potrditev in premakne na njo vejo, na katero kaže HEAD. +Ko zaženete `git commit`, Git ustvari novo potrditev in na njo premakne vejo, na katero kaže HEAD. Ko se z ukazom `reset` vrnete na `HEAD~` (na starša od `HEAD`), premaknete vejo nazaj na prejšnje mesto, pri tem pa ne spremenite indeksa ali delovnega direktorija. Sedaj lahko posodobite indeks in znova zaženete `git commit`, da dosežete to, kar bi naredil `git commit --amend` (glejte <<_git_amend>>). @@ -168,26 +177,28 @@ Opazite lahko, da boste z zagonom ukaza `git status` sedaj videli v zeleni barvi Naslednja stvar, ki jo bo `reset` naredil, je posodobitev indeksa z vsebino posnetka, na katerega sedaj kaže HEAD. -image::images/reset-mixed.png[] +.Mešana ponastavitev +image::images/reset-mixed.png[Mešana ponastavitev] Če določite možnost `--mixed`, se bo postopek ukaza `reset` ustavil na tem koraku. To je tudi privzeta možnost, zato če ne navedete nobene možnosti (v tem primeru le `git reset HEAD~`), se bo ukaz končal tukaj. -Sedaj si vzemite še eno sekundo, da si ogledate ta diagram in ugotovite, kaj se je zgodilo: še vedno ste preklicali zadnji ukaz `commit`, vendar ste tudi odstranili vse spremembe, ki niso bile v indeksu. +Sedaj si vzemite še eno sekundo, da si ogledate ta diagram in ugotovite, kaj se je zgodilo: še vedno ste preklicali zadnji ukaz `commit`, vendar ste tudi premaknili vse spremembe iz indeksa v delovni direktorij. Vrnili ste se na stanje pred zagonom ukazov `git add` in `git commit`. ===== 3. korak: Posodobitev delovnega direktorija (`--hard`) -Tretja stvar, ki jo bo `reset` naredil, je, da bo delovni imenik izgledal tako kot indeks. +Tretja stvar, ki jo bo `reset` naredil, je, da bo delovni direktorij izgledal tako kot indeks. Če uporabite možnost `--hard`, se bo nadaljeval na tej stopnji. -image::images/reset-hard.png[] +.Trda ponastavitev +image::images/reset-hard.png[Trda ponastavitev] Razmislimo o tem, kaj se je pravkar zgodilo. -Preklicali ste zadnjo potrditev, ukaza `git add` in `git commit`, *ter* vso delo, ki ste ga opravili v vašem delovnem imeniku. +Preklicali ste zadnjo potrditev, ukaza `git add` in `git commit` *ter* vso delo, ki ste ga opravili v vašem delovnem direktoriju. Pomembno je opozoriti, da je ta zastavica (`--hard`) edini način, da je ukaz `reset` nevaren, in eden izmed zelo redkih primerov, ko Git dejansko uniči podatke. -Katerakoli drugačna uporaba ukaza `reset` se lahko precej enostavno razveljavi, ne pa možnost `--hard`, saj silovito prepiše datoteke v delovnem imeniku. +Katerakoli drugačna uporaba ukaza `reset` se lahko precej enostavno razveljavi, ne pa možnost `--hard`, saj silovito prepiše datoteke v delovnem direktoriju. V tem posebnem primeru imamo še vedno različico *v3* naše datoteke v potrditvi v naši bazi podatkov Git in jo lahko dobimo nazaj s pogledom v naš reflog, vendar bi jo Git, če je ne bi potrdili, še vedno prepisal in postala bi nepopravljivo izgubljena. ===== Povzetek @@ -213,22 +224,25 @@ Ta oblika (ker niste navedli SHA-1 ali veje in niste navedli `--soft` ali `--har Tako preprosto kopira `file.txt` iz HEAD-a v indeks. -image::images/reset-path1.png[] +.Mešana ponastavitev s potjo +image::images/reset-path1.png[Mešana ponastavitev s potjo] To ima praktični učinek dajanja datoteke _izven področja priprave_. Če si ogledamo diagram za ta ukaz in razmislimo o tem, kaj naredi `git add`, sta si natančno nasprotna. -image::images/reset-path2.png[] +.Dodajanje datoteke v področje priprave (indeks) +image::images/reset-path2.png[Dodajanje datoteke v področje priprave (indeks)] To je razlog, zakaj nam izhod ukaza `git status` predlaga, naj za preklic dajanja datoteke v področje priprave uporabimo ta ukaz (za več informacij glejte <>). Enako lahko dosežemo tudi tako, da Gitu ne dovolimo, da smo mislili "`povleci podatke iz HEAD`", tako da navedemo specifično potrditev, od koder želimo povleči datoteko. Tako bi lahko zagnali nekaj podobnega `git reset eb43bf file.txt`. -image::images/reset-path3.png[] +.Mehka ponastavitev s potjo na določeno potrditev +image::images/reset-path3.png[Mehka ponastavitev s potjo na določeno potrditev] -To dejansko naredi isto kot če bi v delovnem imeniku vsebino datoteke pripeljali nazaj na *v1*, na njej uporabili `git add` in jo nato spet vrnili na *v3* (brez da bi dejansko šli skozi vse te korake). -Če zdaj poženemo `git commit`, bo zabeležil spremembo, ki vrne datoteko nazaj na *v1*, čeprav je dejansko nikoli nismo imeli v našem delovnem imeniku. +To dejansko naredi enako, kot če bi v delovnem direktoriju vsebino datoteke pripeljali nazaj na *v1*, na njej uporabili `git add` in jo nato spet vrnili na *v3* (brez da bi dejansko šli skozi vse te korake). +Če zdaj poženemo `git commit`, bo zabeležil spremembo, ki vrne datoteko nazaj na *v1*, čeprav je dejansko nikoli nismo imeli v našem delovnem direktoriju. Zanimivo je tudi omeniti, da kot pri `git add`, lahko tudi ukaz `reset` sprejme možnost `--patch`, da premakne vsebine iz področja priprave po kosih. Tako lahko izbirate katero vsebino želite pustiti izven področja priprave, ali jo obrniti. @@ -244,15 +258,18 @@ V poglavju <<_squashing>> je prikazan še en način, kako to storiti, vendar bo Recimo, da imate projekt, kjer prva potrditev vsebuje eno datoteko, druga pa je dodala novo datoteko in spremenila prvo, tretja potrditev pa je ponovno spremenila prvo datoteko. Druga potrditev je bilo delo v napredku in ga želite stisniti skupaj. -image::images/reset-squash-r1.png[] +.Repozitorij Git +image::images/reset-squash-r1.png[Repozitorij Git] Za premikanje glavne veje na starejšo potrditev (zadnjo potrditev, ki jo želite obdržati), lahko zaženete ukaz `git reset --soft HEAD~2`: -image::images/reset-squash-r2.png[] +.Premik HEAD-a pri mehki ponastavitvi +image::images/reset-squash-r2.png[Premik HEAD-a pri mehki ponastavitvi] In nato enostavno ponovno poženete `git commit`: -image::images/reset-squash-r3.png[] +.Repozitorij Git s stisnjeno potrditvijo +image::images/reset-squash-r3.png[Repozitorij Git s stisnjeno potrditvijo] Sedaj lahko vidite, da vaša dosegljiva zgodovina, zgodovina, ki bi jo potisnili, zdaj kaže, kot da imate eno potrditev s `file-a.txt` *v1*, nato drugo, ki je spremenila `file-a.txt` na *v3* in dodala `file-b.txt`. Potrditve z različico datoteke *v2* ni več v zgodovini. @@ -281,7 +298,8 @@ HEAD bo sedaj kazal na `master`. V obeh primerih premikamo HEAD, da kaže na potrditev A, vendar je način, _kako_ to storimo, zelo drugačen. `reset` premakne vejo, na katero kaže HEAD, `checkout` pa premakne sam HEAD. -image::images/reset-checkout.png[] +.`git checkout` in `git reset` +image::images/reset-checkout.png[`git checkout` in `git reset`] ===== S potmi @@ -293,7 +311,7 @@ Podobno kot pri `git reset` in `git add`, tudi `checkout` sprejme možnost `--pa ==== Povzetek -Upamo, da zdaj razumete ukaz `reset` in se z njim počutite bolj domače, vendar ste pa verjetno še vedno malo zmedeni glede tega, kako se natančno razlikuje od `checkout` in si ne morete zapomniti vseh pravil za različne klice. +Upamo, da zdaj razumete ukaz `reset` in se z njim počutite bolj domače, vendar ste pa verjetno še vedno malo zmedeni glede tega, kako se točno razlikuje od `checkout` in si ne morete zapomniti vseh pravil za različne klice. Tu je plonk listek za ukaze, ki vplivajo na drevesa. Stolpec "`HEAD`" prebere "`REF`", če ta ukaz premakne referenco (vejo), na katero kaže HEAD, in "`HEAD`", če premakne sam HEAD. diff --git a/book/07-git-tools/sections/submodules.asc b/book/07-git-tools/sections/submodules.asc index e289b6af..8e78f579 100644 --- a/book/07-git-tools/sections/submodules.asc +++ b/book/07-git-tools/sections/submodules.asc @@ -348,7 +348,7 @@ index 6fc0b3d..fd1cc29 100644 To je kar odlično, saj lahko dejansko vidimo dnevnik potrditev, ki jih bomo ravno potrdili v našem podmodulu. Ko je enkrat potrjeno, lahko vidimo te informacije tudi po tem, kot tudi, ko poženete `git log -p`. -[source,console] +[source,consle] ---- $ git log -p --submodule commit 0a24cfc121a8a3c118e0105ae4ae4c00281cf7ae diff --git a/book/08-customizing-git/sections/config.asc b/book/08-customizing-git/sections/config.asc index 55651c5e..f47a1913 100644 --- a/book/08-customizing-git/sections/config.asc +++ b/book/08-customizing-git/sections/config.asc @@ -116,7 +116,7 @@ feel free to be detailed. ".git/COMMIT_EDITMSG" 14L, 297C ---- -Če ima vaša ekipa politiko za sporočila potrditev, potem lahko namestite predlogo za to politiko na svoj sistem in nastavite Git, da ga privzeto uporablja, kar lahko pomaga povečati možnost, da se ta politika redno upošteva. +Če ima vaša ekipa pravilnik za sporočila potrditev, potem lahko namestite predlogo za ta pravilnik na svoj sistem in nastavite Git, da ga privzeto uporablja, kar lahko pomaga povečati možnost, da se ta pravilnik redno upošteva. ===== `core.pager` @@ -460,7 +460,7 @@ Ko uporabljate popravke, lahko Git zaprosite, naj vas opozori, če uporablja pop $ git apply --whitespace=warn ---- -Ali pa določite, da Git poskusi avtomatsko popraviti težavo preden uporabi popravek: +Ali pa določite, da Git poskusi avtomatsko popraviti težavo preden uporabi programski popravek: [source,console] ---- @@ -504,7 +504,7 @@ Ta pristop vam omogoča izvajanje bolj zapletenih ukazov, na primer zavračanje ===== `receive.denyDeletes` -Ena od nadomestnih rešitev za politiko `denyNonFastForwards` je, da uporabnik izbriše vejo in jo nato znova potisne z novo referenco. +Ena od nadomestnih rešitev za pravilnik `denyNonFastForwards` je, da uporabnik izbriše vejo in jo nato znova potisne z novo referenco. Da bi se temu izognili, nastavite `receive.denyDeletes` na `true`: [source,console] diff --git a/book/08-customizing-git/sections/hooks.asc b/book/08-customizing-git/sections/hooks.asc index 86b5406b..4f1d1204 100644 --- a/book/08-customizing-git/sections/hooks.asc +++ b/book/08-customizing-git/sections/hooks.asc @@ -62,7 +62,7 @@ Vse se kličejo z ukazom `git am`, zato lahko v svojem poteku dela varno presko Prva kljuka, ki se zažene, je `applypatch-msg`. Sprejme en argument: ime začasne datoteke, ki vsebuje predlagano sporočilo potrditve. -Če se ta skripta zaključi z ne-ničelnim izhodom, Git prekliče popravek. +Če se ta skripta zaključi z ne-ničelnim izhodom, Git prekliče programski popravek. Uporabite jo lahko, da se prepričate, da je sporočilo potrditve pravilno oblikovano, ali pa sporočilo normalizirate tako, da skripta uredi sporočilo na mestu. Naslednja kljuka, ki se zažene pri uporabi popravkov z ukazom `git am`, je `pre-applypatch`. @@ -101,9 +101,9 @@ Kljuka `pre-auto-gc` se sproži tik pred zbiranjem smeti in jo lahko uporabite, ==== Kljuke strežniške strani -Poleg kljuk na strani odjemalca lahko kot skrbnik sistema uporabite tudi nekaj pomembnih strežniških kljuk, da uveljavite skoraj vsako vrsto politike za vaš projekt. +Poleg kljuk na strani odjemalca lahko kot skrbnik sistema uporabite tudi nekaj pomembnih strežniških kljuk, da uveljavite skoraj vsako vrsto pravilnika za vaš projekt. Te skripte se izvajajo pred in po potiskanju na strežnik. -Pred-kljuke lahko kadar koli izstopijo z ne-ničelno vrednostjo, da zavrnete potiskanje in pošljete sporočilo o napaki nazaj na odjemalca; lahko nastavite politiko potiskanja, ki je tako zapletena, kot želite. +Pred-kljuke lahko kadar koli izstopijo z ne-ničelno vrednostjo, da zavrnete potiskanje in pošljete sporočilo o napaki nazaj na odjemalca; lahko nastavite pravilnik potiskanja, ki je tako zapletena, kot želite. ===== `pre-receive` diff --git a/book/08-customizing-git/sections/policy.asc b/book/08-customizing-git/sections/policy.asc index 0176800b..ebf271ad 100644 --- a/book/08-customizing-git/sections/policy.asc +++ b/book/08-customizing-git/sections/policy.asc @@ -3,7 +3,7 @@ (((policy example))) V tem razdelku boste uporabili to, kar ste se naučili, da vzpostavite potek dela Git, ki preveri določen format sporočila potrditve in dovoljuje samo določenim uporabnikom spreminjanje določenih poddirektorijev v projektu. -Zgradili boste skripte za odjemalce, katere pomagajo razvijalcem vedeti, ali bo njihov potisk zavrnjen, in strežniške skripte, ki dejansko izvajajo politike. +Zgradili boste skripte za odjemalce, katere pomagajo razvijalcem vedeti, ali bo njihov potisk zavrnjen, in strežniške skripte, ki dejansko izvajajo pravilnike. Skripte, ki jih bomo prikazali, so napisane v Rubyju; deloma zaradi naše intelektualne vztrajnosti, vendar tudi zato, ker je Ruby enostaven za branje, tudi če ga ne morete nujno pisati. Vendar pa bo deloval kateri koli jezik - vsi primeri skript kljuk, ki jih distribuira Git, so bodisi v Perlu ali Bashu, zato lahko s pogledom na vzorce vidite tudi veliko primerov kljuk v teh jezikih. @@ -397,7 +397,7 @@ Eno opozorilo je, da od vas pričakuje, da teče lokalno kot isti uporabnik kot Druga stvar, ki jo lahko storimo tukaj, je, da poskrbimo, da uporabnik ne potiska ne-fast-forward referenc. Za referenco, ki ni fast-forward, morate potrditve ponovno bazirati, katere ste že potisnili na strežnik, ali pa poskušate potisniti drugo lokalno vejo na isto oddaljeno vejo. -Predvidevamo, da je strežnik že nastavljen z `receive.denyDeletes` in `receive.denyNonFastForwards` za uveljavitev te politike, zato lahko poskušamo ujeti le nenamerna ponovna baziranja že potisnjenih potrditev. +Predvidevamo, da je strežnik že nastavljen z `receive.denyDeletes` in `receive.denyNonFastForwards` za uveljavitev tega pravilnika, zato lahko poskušamo ujeti le nenamerna ponovna baziranja že potisnjenih potrditev. Tu je primer skripte `pre-rebase`, ki preverja to. Dobimo seznam vseh potrditev, ki jih nameravate prepisati in preverimo, ali obstajajo v kateri od vaših oddaljenih referenc. diff --git a/book/10-git-internals/sections/refs.asc b/book/10-git-internals/sections/refs.asc index cc926c04..7020423c 100644 --- a/book/10-git-internals/sections/refs.asc +++ b/book/10-git-internals/sections/refs.asc @@ -4,7 +4,7 @@ Če vas zanima ogled zgodovine vašega repozitorija, katera je dosegljivega od potrditve `1a410e`, bi lahko zagnali nekaj podobnega kot `git log 1a410e`, da bi prikazali to zgodovino, vendar bi si še vedno morali zapomniti, da je `1a410e` tista potrditev, ki jo želite uporabiti kot začetno točko za to zgodovino. Namesto tega bi bilo lažje, če bi imeli datoteko, v kateri bi lahko shranili tisto vrednost SHA-1 pod preprostim imenom, tako da bi lahko uporabili to preprosto ime namesto surove vrednosti SHA-1. -V Gitu se ta preprosta imena imenujejo "`reference`" oz. "`refs`"; datoteke, ki vsebujejo te vrednosti SHA-1, lahko najdete v imeniku `.git/refs`. +V Gitu se ta preprosta imena imenujejo "`reference`" ali "`refs`"; datoteke, ki vsebujejo te vrednosti SHA-1, lahko najdete v imeniku `.git/refs`. V trenutnem projektu ta imenik ne vsebuje datotek, vendar vsebuje preprosto strukturo: [source,console] diff --git a/book/A-git-in-other-environments/sections/powershell.asc b/book/A-git-in-other-environments/sections/powershell.asc index 540036be..5fa06643 100644 --- a/book/A-git-in-other-environments/sections/powershell.asc +++ b/book/A-git-in-other-environments/sections/powershell.asc @@ -23,7 +23,7 @@ Z `RemoteSigned` morajo biti podpisane le skripte, ki imajo nastavljen `ZoneIden Več o obsegu PowerShell: https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_scopes[^]. -Več o izvajanju politike PowerShell: https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.security/set-executionpolicy[^]. +Več o izvajanju pravilnika PowerShell: https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.security/set-executionpolicy[^]. Za nastavitev vrednosti `ExecutionPolicy` na `RemoteSigned` za vse uporabnike uporabite naslednji ukaz: diff --git a/book/B-embedding-git/sections/dulwich.asc b/book/B-embedding-git/sections/dulwich.asc index a6b2ce9b..d36c32ec 100644 --- a/book/B-embedding-git/sections/dulwich.asc +++ b/book/B-embedding-git/sections/dulwich.asc @@ -10,7 +10,7 @@ Dulwich sledi načrtovanju Git in loči dve osnovni ravni API-ja: napeljavo in k Tukaj je primer uporabe nižje ravni API-ja za dostop do sporočila zadnje potrditve: -[source, python] +[source,python] ---- from dulwich.repo import Repo r = Repo('.') @@ -27,7 +27,7 @@ c.message Za izpis dnevnika potrditev z uporabo visoko nivojskega API-ja lahko uporabite: -[source, python] +[source,python] ---- from dulwich import porcelain porcelain.log('.', max_entries=1) diff --git a/book/B-embedding-git/sections/go-git.asc b/book/B-embedding-git/sections/go-git.asc index 1a3a3ebc..a55c5c42 100644 --- a/book/B-embedding-git/sections/go-git.asc +++ b/book/B-embedding-git/sections/go-git.asc @@ -9,7 +9,7 @@ go-git je osredotočen na razširljivost, združljivost in podpira večino API-j Tu je osnovni primer uporabe Go API-jev: -[source, go] +[source,go] ---- import "github.com/go-git/go-git/v5" @@ -21,7 +21,7 @@ r, err := git.PlainClone("/tmp/foo", false, &git.CloneOptions{ Takoj, ko imate instanco `Repository`, lahko dostopate do informacij in na njih izvajate mutacije: -[source, go] +[source,go] ---- // retrieves the branch pointed by HEAD ref, err := r.Head() @@ -43,7 +43,7 @@ for _, c := range history { go-git ima nekaj pomembnih naprednih funkcij, ena izmed njih je vtični sistem za shranjevanje, ki je podoben zaledju Libgit2. Privzeta izvedba je shranjevanje v pomnilniku, kar je zelo hitro. -[source, go] +[source,go] ---- r, err := git.Clone(memory.NewStorage(), nil, &git.CloneOptions{ URL: "https://github.com/go-git/go-git", @@ -58,7 +58,7 @@ Z uporabo https://pkg.go.dev/github.com/go-git/go-billy/v5?tab=doc#Filesystem[^] Druga napredna uporaba vključuje prilagodljiv odjemalec HTTP, kot je tisti najden na https://github.com/go-git/go-git/blob/master/_examples/custom_http/main.go[^]. -[source, go] +[source,go] ---- customClient := &http.Client{ Transport: &http.Transport{ // accept any certificate (might be useful for testing) diff --git a/book/dedication.asc b/book/dedication.asc index 2d0a5d66..14a76b43 100644 --- a/book/dedication.asc +++ b/book/dedication.asc @@ -1,8 +1,7 @@ [dedication] == Posvetila -_Moji ženi Becky brez katere se ta pustolovščina nikoli ne bi pričela. — Ben_ +_Moji ženi Becky, brez katere se ta pustolovščina nikoli ne bi pričela. — Ben_ _Ta izdaja je posvečena vsem mojim dekletom. -Moji ženi Jessici, ki me je vsa ta leta podpirala in moji hčerki Josephine, -ki me bo podpirala, ko bom prestar, da bi vedel, kaj se dogaja. — Scott_ +Moji ženi Jessici, ki me je vsa ta leta podpirala, in moji hčerki Josephine, ki me bo podpirala, ko bom prestar, da bi vedel, kaj se dogaja. — Scott_ diff --git a/book/introduction.asc b/book/introduction.asc index 9224b206..e4fccb82 100644 --- a/book/introduction.asc +++ b/book/introduction.asc @@ -6,7 +6,7 @@ Najprej vam bomo pojasnili, kaj vse vam ta knjiga prinaša. Tu je hiter povzetek desetih poglavij in treh prilog te knjige. V *poglavju 1* bomo pokrili sisteme za nadzor različic (VCS) in osnovne informacije o Gitu - brez tehničnih podrobnosti, le, kaj je Git, zakaj se je pojavil v svetu polnem VCS in kaj ga ločuje od drugih ter zakaj ga toliko ljudi uporablja. -Nato bomo pojasnili, kako prenesti Git in ga prvič nastaviti, če ga še nimate na svojem sistemu. +Nato bomo pojasnili, kako Git prenesti in ga prvič nastaviti, če ga še nimate na svojem sistemu. V *poglavju 2* bomo predstavili osnovno uporabo Gita - kako uporabljati Git v 80% primerov, s katerimi se boste najpogosteje srečali. Po branju tega poglavja bi morali znati klonirati repozitorij, videti, kaj se je zgodilo v zgodovini projekta, spreminjati datoteke in prispevati spremembe. @@ -20,38 +20,38 @@ Ko boste končali, boste morda potrebovali trenutek za razmislek, kako ste žive To poglavje je namenjeno tistim, ki želijo vzpostaviti Git znotraj svoje organizacije ali na svojem osebnem strežniku za sodelovanje. Raziskali bomo tudi različne možnosti gostovanja, če vam je ljubše, da to nekdo drug uredi za vas. -*Poglavje 5* podrobno opisuje različne porazdeljene delovne procese in kako jih doseči z Gitom. +*Poglavje 5* podrobno opisuje različne porazdeljene poteke dela in kako jih doseči z Gitom. Ko boste končali s tem poglavjem, boste lahko z večimi oddaljenimi repozitoriji delali strokovno, Git uporabljali prek e-pošte in spretno upravljali z več oddaljenimi vejami ter prispevali popravke. -*Poglavje 6* zajema storitev GitHub za gostovanje in orodja v podrobnosti. -Pokrijemo registracijo in upravljanje računa, ustvarjanje in uporabo repozitorijev Git, običajne delovne tokove za prispevanje k projektom in sprejemanje prispevkov v vašega, programski vmesnik GitHuba in veliko malih namigov, ki vam bodo na splošno olajšali življenje. +*Poglavje 6* zajema podrobnosti storitve GitHub za gostovanje in orodij. +Pokrijemo registracijo in upravljanje računa, ustvarjanje in uporabo repozitorijev Git, običajne poteke dela za prispevanje k projektom in sprejemanje prispevkov v vašega, programski vmesnik GitHuba in veliko malih namigov, ki vam bodo na splošno olajšali življenje. *Poglavje 7* govori o naprednih ukazih Git. -Tukaj boste izvedeli o temah, kot so obvladovanje strašnega ukaza 'reset', uporaba binarnega iskanja za identifikacijo napak, urejanje zgodovine, podrobna izbira revizij in še veliko več. +Tukaj boste izvedeli o temah, kot so obvladovanje strašljivega ukaza `reset`, uporaba binarnega iskanja za identifikacijo napak, urejanje zgodovine, podrobna izbira revizij in še veliko več. To poglavje bo dopolnilo vaše znanje o Gitu, da boste resnično mojster. *Poglavje 8* govori o konfiguriranju vašega prilagojenega okolja Git. -To vključuje nastavljanje skript za kavlje, da izvajajo ali spodbujajo prilagojene politike ter uporabo nastavitev konfiguracije okolja, da lahko delate na način, ki vam ustreza. -Pregledali bomo tudi izgradnjo vašega lastnega nabora skript, ki izvajajo prilagojeno politiko za izročitev sprememb. +To vključuje nastavljanje skript za kljuke, da izvajajo ali spodbujajo prilagojeni pravilnik ter uporabo nastavitev konfiguracije okolja, da lahko delate na način, ki vam ustreza. +Pregledali bomo tudi izgradnjo vašega lastnega nabora skript, ki izvajajo prilagojeni pravilnik za izročitev sprememb. *Poglavje 9* se ukvarja z Gitom in drugimi VCS-ji. To vključuje uporabo Gita v svetu Subversiona (SVN) in pretvorbo projektov iz drugih VCS-jev v Git. -Veliko organizacij še vedno uporablja SVN in se ne namerava spremeniti, toda do tega trenutka ste se že naučili neverjetne moči Gita - in to poglavje vam pokaže, kako se spopasti, če morate še vedno uporabljati SVN strežnik. +Veliko organizacij še vedno uporablja SVN in se ne nameravajo spremeniti, toda do tega trenutka ste se že naučili neverjetne moči Gita - in to poglavje vam pokaže, kako se spopasti, če morate še vedno uporabljati strežnik SVN. Pregledali bomo tudi, kako uvoziti projekte iz več različnih sistemov, v primeru, da prepričate vse, da se podate v novost. *Poglavje 10* se poglobi v temne, vendar čudovite globine notranjosti Gita. -Zdaj, ko veste vse o Gitu in ga lahko uporabljate z močjo in eleganco, lahko nadaljujete z razpravo o tem, kako Git shranjuje svoje objekte, kakšen je model objekta, podrobnosti o paketnih datotekah, protokolih strežnika in še več. +Zdaj, ko veste vse o Gitu in ga lahko uporabljate z močjo in eleganco, lahko nadaljujete na razpravo o tem, kako Git shranjuje svoje objekte, kakšen je model objekta, kakšne so podrobnosti paketnih datotekah, protokolih strežnika in še več. V celotni knjigi se bomo na odseke tega poglavja sklicevali v primeru, da se boste želeli poglobiti v to temo; toda če ste podobni nam in si želite poglobiti v tehnične podrobnosti, bi morda želeli najprej prebrati poglavje 10. -Prepuščamo vam odločitev. +Odločitev prepuščamo vam. V *dodatku A* si bomo ogledali številne primere uporabe Gita v različnih specifičnih okoljih. -Pokrili bomo več različnih grafičnih uporabniških vmesnikov (GUI) in IDE programskih okolij, v katerih želite morda uporabiti Git, ter kaj vam je na voljo. +Pokrili bomo več različnih grafičnih uporabniških vmesnikov (GUI) in programskih okolij IDE, v katerih želite morda uporabiti Git, ter kaj vam je na voljo. Če vas zanima pregled uporabe Gita v vaši lupini, vašem IDE ali urejevalniku besedil, si oglejte to poglavje. V *dodatku B* bomo raziskali skriptiranje in razširjanje Gita prek orodij, kot sta libgit2 in JGit. Če vas zanima pisanje zapletenih in hitrih prilagojenih orodij in potrebujete dostop do nizke ravni Gita, si lahko tukaj ogledate, kakšen je ta krajinski pogled. -Nazadnje, v *dodatku C*, bomo enega za drugim pregledali vse glavne ukaze Gita in pregledali, kje v knjigi smo jih pokrili in kaj smo z njimi storili. +Nazadnje, v *dodatku C*, bomo enega za drugim pregledali vse glavne ukaze Gita in pogledali, kje v knjigi smo jih pokrili in kaj smo z njimi storili. Če želite vedeti, kje v knjigi smo uporabili kateri koli poseben ukaz Gita, ga lahko poiščete tukaj. Začnimo. diff --git a/book/preface_schacon.asc b/book/preface_schacon.asc index 538a2052..2eb3139f 100644 --- a/book/preface_schacon.asc +++ b/book/preface_schacon.asc @@ -26,7 +26,7 @@ Ni mi bilo všeč, da sem pisal o tem, kar sem čutil, da je večinoma vir skupn Namesto primera gostovanja Gita sem se odločil, da bomo ta del knjige bolj podrobno opisali, kaj GitHub je in kako ga učinkovito uporabljati. Če se želite naučiti uporabljati Git, vam bo poznavanje GitHuba pomagalo, da se boste vključili v veliko skupnost, kar je pomembno ne glede na to, katero spletno mesto za gostovanje Gita se boste odločili uporabiti za svojo kodo. -Druga velika sprememba v času od zadnje objave knjige je bila razvoj in vzpon HTTP protokola za Git omrežne transakcije. +Druga velika sprememba v času od zadnje objave knjige je bila razvoj in vzpon protokola HTTP za omrežne transakcije Git. Večina primerov v knjigi je bila spremenjena iz SSH v HTTP, ker je to veliko preprosteje. Opazovati rast Gita v zadnjih nekaj letih od relativno neznanskega sistema za nadzor različic do prevladujočega komercialnega in odprtokodnega sistema za nadzor različic je bilo neverjetno. diff --git a/ch08-customizing-git.asc b/ch08-customizing-git.asc index 243e3bdc..de2b2d45 100644 --- a/ch08-customizing-git.asc +++ b/ch08-customizing-git.asc @@ -16,5 +16,5 @@ include::book/08-customizing-git/sections/policy.asc[] === Povzetek Pokrili smo večino glavnih načinov, s katerimi lahko prilagodite vašega odjemalca Git in strežnik, da se najboljše ujemata z vašim potekom dela in projekti. -Naučili ste se o vseh vrstah konfiguracijskih nastavitev, atributih datotečne osnove in kljukah dogodkov ter zgradili ste primer strežnika z vsiljevanjem politike. +Naučili ste se o vseh vrstah konfiguracijskih nastavitev, atributih datotečne osnove in kljukah dogodkov ter zgradili ste primer strežnika z vsiljevanjem pravilnika. Sedaj bi morali znati narediti, da se Git prilagaja skoraj kateremukoli poteku dela, ki si ga lahko zamislite.