Sync with upstream and enhance translations and source code

C-git-commands.asc

@@ -35,7 +35,7 @@ V razdelku <<ch02-git-basics-chapter#_git_aliases>> smo pokazali, kako ga lahko
 
 V razdelku <<ch03-git-branching#_rebasing>> smo ga uporabili, da smo določili privzeto vedenje `--rebase`, ko zaženemo ukaz `git pull`.
 
-V razdelku <<ch07-git-tools#_credential_caching>> smo ga uporabili, da smo nastavili privzeti repozitorij za vaša HTTP gesla.
+V razdelku <<ch07-git-tools#_credential_caching>> smo ga uporabili, da smo nastavili privzeti repozitorij za vaša gesla HTTP.
 
 V razdelku <<ch08-customizing-git#_keyword_expansion>> 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 <<ch02-git-basics-chapter#_git_diff_staged>>.
 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 <<ch02-git-basics-chapter#_committing_changes>>.
-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 <<ch02-git-basics-chapter#_undoing>> smo predstavili uporabo možnosti `--amend`, s katero lahko ponovno opravite zadnjo potrditev.
 
@@ -357,7 +357,7 @@ V poglavju <<ch02-git-basics-chapter#_sharing_tags>> smo videli, kako ga uporabi
 
 V poglavju <<ch07-git-tools#_publishing_submodules>> 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 <<ch08-customizing-git#_other_client_hooks>> 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 <<ch08-customizing-git#_other_client_hooks>> 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 <<ch10-git-internals#_pushing_refspecs>> 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 <<ch05-distributed-git#_patches_from_email>> smo predstavili uporabo in okoliščine, v katerih ga lahko uporabimo.
@@ -486,9 +486,9 @@ V poglavju <<ch05-distributed-git#_patches_from_email>> 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 <<ch05-distributed-git#_git_am>>, vključno z uporabo možnosti `--resolved`, `-i` in `-3`.
+Pokrili smo uporabo in potek dela okoli `git am` v <<ch05-distributed-git#_git_am>>, 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 <<ch08-customizing-git#_email_hooks>>.
+Obstaja tudi veliko število kljuk, ki jih lahko uporabite za pomoč pri poteku dela okoli `git am` in vsi so opisani v poglavju <<ch08-customizing-git#_email_hooks>>.
 
 Uporabimo ga tudi za uporabo sprememb oblikovanih kot popravki za zahteve potegov na GitHubu v poglavju <<ch06-github#_email_notifications>>.
 

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 [<options>] [--] <pathspec>...

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

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

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.

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 <tagname>`.
 
-[source,console]
+[source,console?prompt=$]
 ----
 $ git push origin v1.5
 Counting objects: 14, done.
@@ -204,7 +204,7 @@ To [email protected]: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 <tagname>
 ----
 
-==== 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'.

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 <file>...` 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 <file>..." 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 <file>...` 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 <file>..." 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