Proofread remaining chapters

Author: petk

book/01-introduction/sections/first-time-setup.asc

@@ -1,5 +1,5 @@
 [[_first_time]]
-=== Prva namestitev Gita
+=== Prva nastavitev Gita
 
 Sedaj, ko imate Git na vašem sistemu, boste želeli postoriti nekaj stvari, da prilagodite svoje okolje Git.
 Te stvari bi morali narediti samo enkrat na katerem koli danem računalniku; ohranile se bodo med nadgradnjami.
@@ -21,7 +21,7 @@ Vsak nivo prepiše vrednosti iz prejšnjega nivoja, tako, da so vrednosti v `.gi
 
 Na sistemih Windows Git poišče datoteko `.gitconfig` v direktoriju `$HOME` (`C:\Users\$USER` za večino ljudi).
 Še vedno tudi pogleda v `[path]/etc/gitconfig`, čeprav je ta pot relativna glede na vrhovni direktorij MSys, ki se nahaja, kjerkoli se odločite namestiti Git na vašem sistemu Windows, ko poženete namestitveni program.
-Če poganjate verzijo Git 2.x ali novejšo za Windows, je na voljo tudi nastavitvena datoteka sistemskega nivoja v `C:\Documents and Settings\All Users\Application Data\Git\config` na Windows XP oz. `C:\ProgramData\Git\config` na Windows Vista in novejših.
+Če poganjate verzijo Git 2.x ali novejšo za Windows, je na voljo tudi nastavitvena datoteka sistemskega nivoja v `C:\Documents and Settings\All Users\Application Data\Git\config` na sistemu Windows XP oz. `C:\ProgramData\Git\config` na sistemu Windows Vista in novejših različicah.
 To nastavitveno datoteko se lahko spremeni samo z `git config -f <file>` kot administrator.
 
 Vse vaše nastavitve in od kod prihajajo, lahko pogledate z uporabo:
@@ -73,7 +73,7 @@ $ git config --global core.editor "'C:/Program Files/Notepad++/notepad++.exe' -m
 
 [NOTE]
 ====
-Vim, Emacs in Notepad++ so popularni urejevalniki besedil pogosto uporabljeni s strani razvijalcev na sistemih osnovanih na Unixu, kot sta Linux in macOS ali na Windows sistemu.
+Vim, Emacs in Notepad++ so popularni urejevalniki besedil pogosto uporabljeni s strani razvijalcev na sistemih osnovanih na Unixu, kot sta Linux in macOS ali na sistemu Windows.
 Če uporabljate drug urejevalnik ali 32-bitno različico, prosimo, poiščite specifična navodila, kako nastaviti vaš priljubljeni urejevalnik z Gitom v <<C-git-commands#ch_core_editor>>.
 ====
 

book/01-introduction/sections/installing.asc

@@ -1,4 +1,4 @@
-=== Git namestitev
+=== Namestitev Gita
 
 Preden začnete uporabljati Git, ga morate narediti na voljo na svojem računalniku.
 Četudi je že nameščen, ga je verjetno dobra ideja posodobiti na zadnjo verzijo.

book/01-introduction/sections/what-is-git.asc

@@ -92,12 +92,12 @@ Delovni direktorij je en sam izvlek ene verzije projekta.
 Te datoteke so povlečene iz stisnjene podatkovne baze v direktoriju Git in dane na disk za vas, da jih uporabite ali spremenite.
 
 Področje priprave je datoteka, v splošnem vsebovana v vašem direktoriju Git, ki shranjuje informacije o tem, kaj bo šlo v vašo naslednjo potrditev.
-Njegovo tehnično ime v jeziku Git je "`index`", vendar se pogosto imenuje tudi področje priprave podatkov ("`staging area`").
+Njegovo tehnično ime v jeziku Git je "`index`", vendar se pogosto imenuje tudi področje priprave podatkov (angl. "`staging area`").
 
 Direktorij Git je, kjer Git shranjuje meta podatke in objektno podatkovno bazo za vaš projekt.
 To je najpomembnejši del Gita in je, kar se kopira, ko _klonirate_ repozitorij iz drugega računalnika.
 
-Osnovni Git potek dela gre nekako takole:
+Osnovni potek dela Git gre nekako takole:
 
 1. Spremenite datoteke v svojem delovnem direktoriju.
 2. Selektivno daste v pripravo samo spremembe, ki jih želite v naslednji potrditvi, kar doda _samo_ tiste spremembe v področje priprave.

book/04-git-server/sections/protocols.asc

@@ -137,7 +137,7 @@ Git je lahko bolj zahtevno nastaviti preko HTTPS v primerjavi s SSH na nekaterih
 Razen tega je zelo malo prednosti, ki jih imajo ostali protokoli preko pametnega protokola HTTP za strežbo Gita.
 
 Če uporabljate HTTP za overjeno potiskanje, je zagotavljanje vaših poverilnic včasih bolj komplicirano kot uporaba ključev preko SSH.
-Vendar na voljo je kar nekaj orodij predpomnjenja poverilnic, ki jih lahko uporabite, vključno s Keychain na macOS in Credential Manager na Windows, kar naredi to precej neboleče.
+Vendar na voljo je kar nekaj orodij predpomnjenja poverilnic, ki jih lahko uporabite, vključno s Keychain na sistemu macOS in Credential Manager na sistemu Windows, kar naredi to precej neboleče.
 Preberite <<ch07-git-tools#_credential_caching>>, da si pogledate, kako nastaviti varno predpomnjenje gesel HTTP na vašem sistemu.
 
 ==== Protokol SSH

book/07-git-tools/sections/advanced-merging.asc

@@ -17,8 +17,8 @@ Pokrili bomo tudi nekatere različne, nestandardne vrste združevanja ter videli
 Medtem ko smo v poglavju <<ch03-git-branching#_basic_merge_conflicts>> predstavili nekaj osnov reševanja konfliktov med združevanjem, Git ponuja nekaj orodij za pomoč pri reševanju bolj zapletenih konfliktov.
 
 Preden opravite združevanje, ki bi lahko povzročilo konflikte, poskusite najprej poskrbeti, da je delovni imenik čist.
-Če imate delo v teku, ga bodisi shranite v začasno vejo, ali pa ga dajte v shrambo na varno (angl. stash).
-Tako lahko kadar koli razveljavite *karkoli*, kar poskušate tukaj.
+Če imate delo v teku, ga shranite v začasno vejo, ali pa ga dajte v shrambo na varno (angl. stash).
+Tako lahko razveljavite *karkoli*, kar tukaj poskušate.
 Če imate v delovnem imeniku neshranjene spremembe, ko poskusite združevati, vam lahko nekaj teh nasvetov pomaga pri ohranjanju tega dela.
 
 Pojdimo skozi zelo preprost primer.
@@ -35,7 +35,7 @@ end
 hello()
 ----
 
-V našem repozitoriju ustvarimo novo vejo, imenovano `whitespace` in nadaljujemo s spreminjanjem vseh končnic vrstic Unix v končnice vrstic DOS, torej dejansko spremenimo vsako vrstico datoteke, vendar le s praznimi znaki.
+V svojem repozitoriju ustvarimo novo vejo, imenovano `whitespace` in nadaljujemo s spreminjanjem vseh končnic vrstic Unix v končnice vrstic DOS, torej dejansko spremenimo vsako vrstico datoteke, vendar le s praznimi znaki.
 Nato spremenimo vrstico "`hello world`" v "`hello mundo`".
 
 [source,console]
@@ -164,8 +164,8 @@ Tisto, kar resnično potrebujemo, je, da datoteko, ki jo želimo združiti, pož
 Kako bi to storili?
 
 Najprej se znajdemo v stanju konflikta združevanja.
-Nato želimo dobiti kopije naše različice datoteke, njihove različice (iz veje, ki jo združujemo) in skupne različice (od kjer sta se obe strani odcepili).
-Nato želimo popraviti bodisi njihovo stran ali našo stran in ponovno poskusimo združiti samo to eno datoteko.
+Nato želimo dobiti kopije svoje različice datoteke, njihove različice (iz veje, ki jo združujemo) in skupne različice (od koder sta se obe strani odcepili).
+Nato želimo popraviti bodisi njihovo stran bodisi svojo stran in ponovno poskusimo združiti samo to eno datoteko.
 
 Dobivanje treh različic datoteke je dejansko precej enostavno.
 Git vse te različice shrani v indeksu pod "`stopnjami`", kjer ima vsaka številko povezano z njo.
@@ -192,7 +192,7 @@ $ git ls-files -u
 
 `:1:hello.rb` je samo bližnjica za iskanje tega bloba SHA-1.
 
-Sedaj, ko imamo vsebine vseh treh stopenj v našem delovnem imeniku, lahko njihovo težavo praznih znakov ročno popravimo in poskusimo ponovno združiti datoteko z manj znanim ukazom `git merge-file`, ki počne ravno to.
+Sedaj, ko imamo vsebine vseh treh stopenj v svojem delovnem imeniku, lahko njihovo težavo praznih znakov ročno popravimo in poskusimo ponovno združiti datoteko z manj znanim ukazom `git merge-file`, ki počne ravno to.
 
 [source,console]
 ----
@@ -333,7 +333,7 @@ CONFLICT (content): Merge conflict in hello.rb
 Automatic merge failed; fix conflicts and then commit the result.
 ----
 
-Videti bi želeli za kateri konflikt združevanja gre.
+Videti bi želeli, za kateri konflikt združevanja gre.
 Če odpremo datoteko, bomo videli nekaj takega:
 
 [source,ruby]
@@ -369,7 +369,7 @@ Možnost `--conflict` lahko podate `diff3` ali `merge` (kar je privzeto).
 $ git checkout --conflict=diff3 hello.rb
 ----
 
-Ko enkrat to poženemo, bo datoteka izgledala takole:
+Ko enkrat to poženemo, bo datoteka videti takole:
 
 [source,ruby]
 ----
@@ -388,7 +388,7 @@ end
 hello()
 ----
 
-Če vam je ta oblika ustrezna, jo lahko nastavite kot privzeto za bodoče konflikte združevanja z nastavitvijo `merge.conflictstyle` pri `diff3`.
+Če vam je ta oblika ustrezna, jo lahko nastavite kot privzeto za prihodnje konflikte združevanja z nastavitvijo `merge.conflictstyle` pri `diff3`.
 
 [source,console]
 ----
@@ -532,7 +532,7 @@ Ko sedaj znate ustvariti potrditev združitve, jih boste verjetno naredili nekaj
 Ena izmed dobrih stvari pri delu z Gitom je, da je v redu narediti napake, saj jih je mogoče (in v mnogih primerih enostavno) popraviti.
 
 Potrditve združitev niso nič drugačne.
-Recimo, da ste začeli delati na tematski veji, jo po nesreči združili v `master` in zdaj vaša zgodovina potrditev izgleda takole:
+Recimo, da ste začeli delati na tematski veji, jo po nesreči združili v `master` in zdaj je vaša zgodovina potrditev videti takole:
 
 .Nenamerna potrditev združitve
 image::images/undomerge-start.png[Nenamerna potrditev združitve]
@@ -552,8 +552,8 @@ Tukaj je hitra osvežitev: `reset --hard` običajno opravi tri korake:
 
 . Premakne kazalec HEAD veje.
   V tem primeru želimo premakniti `master` tja, kjer je bila pred potrditvijo združitve (`C6`).
-. Naredi, da indeks izgleda kot HEAD.
-. Naredi, da delovni imenik izgleda kot indeks.
+. Naredi, da je indeks videti kot HEAD.
+. Naredi, da je delovni imenik videti kot indeks.
 
 Slaba stran tega pristopa je, da se prepisuje zgodovina, kar lahko predstavlja težave z deljenim repozitorijem.
 Preverite <<ch03-git-branching#_rebase_peril>> za več o tem, kaj se lahko zgodi; na kratko, če imajo druge osebe potrditve, ki jih prepisujete, se je treba izogibati uporabi `reset`.
@@ -571,16 +571,16 @@ $ git revert -m 1 HEAD
 [master b1d8379] Revert "Merge branch 'topic'"
 ----
 
-Zastavica `-m 1` kaže na to, da je "`mainline`" starš in bi se ga moralo obdržati.
+Zastavica `-m 1` kaže na to, da je "`mainline`" starš in bi se moral obdržati.
 Ko kličete združitev v `HEAD` (`git merge topic`), ima nova potrditev dva starša: prvi je `HEAD` (`C6`), drugi pa vrh veje, ki se združuje (`C4`).
 V tem primeru želimo razveljaviti vse spremembe, ki jih je uvedla združitev drugega starša (`C4`), hkrati pa ohraniti vsebino starša #1 (`C6`).
 
-Zgodovina s preklicano potrditvijo združitve izgleda tako:
+Zgodovina s preklicano potrditvijo združitve je videti tako:
 
 .Zgodovina po `git revert -m 1`
 image::images/undomerge-revert.png[Zgodovina po `git revert -m 1`]
 
-Nova potrditev `^M` ima enake vsebine kot `C6`, zato je od tu dalje, kot da se združitev ni nikoli zgodila, razen da so zdaj nezdružene potrditve še vedno v zgodovini `HEAD`.
+Nova potrditev `^M` ima enake vsebine kot `C6`, zato je od tu dalje, kot da se združitev ni nikoli zgodila, razen, da so zdaj nezdružene potrditve še vedno v zgodovini `HEAD`.
 Git bo zmeden, če boste poskusili znova združiti `topic` v `master`:
 
 [source,console]

book/07-git-tools/sections/bundling.asc

@@ -8,7 +8,7 @@ To je lahko uporabno v različnih scenarijih.
 Morda je vaše omrežje nedostopno, vendar želite poslati spremembe svojim sodelavcem.
 Morda delate nekje izven pisarne in nimate dostopa do lokalnega omrežja iz varnostnih razlogov.
 Morda se vam je pokvarila brezžična/ethernet kartica.
-Morda zaenkrat nimate dostopa do skupnega strežnika, želite pa nekomu poslati posodobitve po e-pošti in ne želite prenesti 40 potrditev prek `format-patch`.
+Morda za zdaj nimate dostopa do skupnega strežnika, želite pa nekomu poslati posodobitve po e-pošti in ne želite prenesti 40 potrditev prek `format-patch`.
 
 Tukaj je lahko koristen ukaz `git bundle`.
 Ukaz `bundle` bo vse, kar bi sicer bilo poslano po žici z ukazom `git push`, zapakiral v binarno datoteko, ki jo lahko pošljete po e-pošti, ali jo shranite na pomnilniški ključ, nato pa jo razpakirate v drugem repozitoriju.
@@ -84,7 +84,7 @@ Seveda lahko naredite enako stvar in v zbirko vključite celoten repozitorij, ka
 
 Za to morate izračunati razliko.
 Kot smo opisali v <<ch07-git-tools#_commit_ranges>>, lahko obseg potrditev določimo na več načinov.
-Da dobimo tri potrditve, ki jih imamo v naši veji `master` in ki jih ni bilo v veji, ki smo jo prvotno klonirali, lahko uporabimo nekaj takega kot je `origin/master..master` ali `master ^origin/master`.
+Da dobimo tri potrditve, ki jih imamo v naši veji `master` in ki jih ni bilo v veji, ki smo jo prvotno klonirali, lahko uporabimo nekaj takega, kot je `origin/master..master` ali `master ^origin/master`.
 To lahko preizkusite s pomočjo ukaza `log`.
 
 [source,console]
@@ -125,7 +125,7 @@ The bundle requires these 1 ref
 ----
 
 Če bi ustvarjalec zbirke ustvaril zbirko samo zadnjih dveh potrditev, ki jih je naredil, namesto vseh treh, prvotni repozitorij ne bi mogel uvoziti te zbirke, saj manjka potrebna zgodovina.
-Ukaz `verify` bi izgledal takole namesto tistega v prejšnjem primeru:
+Ukaz `verify` bi bil videti takole namesto tistega v prejšnjem primeru:
 
 [source,console]
 ----

book/07-git-tools/sections/credentials.asc

@@ -15,7 +15,7 @@ Git ima vgrajenih nekaj možnosti:
 * Način "`cache`" shrani poverilnice v pomnilnik za določen čas.
   Gesla nikoli niso shranjena na disku in iz predpomnilnika se izbrišejo po 15 minutah.
 * Način "`store`" shrani poverilnice v besedilno datoteko na disku in nikoli ne potečejo.
-  To pomeni, da gesla ne boste več morali vnašati, dokler ne spremenite gesla za gostitelja Git.
+  To pomeni, da gesla ne boste več mogli vnesti, dokler ne spremenite gesla za gostitelja Git.
   Slabost tega pristopa je, da so vaša gesla shranjena v čisti besedilni datoteki v vaši domači mapi.
 * Če uporabljate macOS, ima Git način "`osxkeychain`", ki poverilnice shrani v varni ključavnici, povezani z vašim sistemskim računom.
   Ta metoda poverilnice shrani na disk in ne potečejo, vendar so šifrirane s sistemom, ki shranjuje certifikate HTTPS, ter Safari jih samodejno izpolnjuje.
@@ -152,7 +152,7 @@ Pomočnika `osxkeychain` in `wincred` uporabljata domači format svojih shramb,
 
 Ker so `git-credential-store` in njegovi prijatelji ločeni programi od Gita, ni veliko skokov do spoznanja, da _kateri koli_ program lahko deluje kot pomočnik pri preverjanju pristnosti v Gitu.
 Pomočniki, ki jih Git ponuja, pokrivajo veliko pogostih primerov uporabe, vendar ne vseh.
-Recimo, da ima vaša ekipa nekaj poverilnic, katere si deli vsa ekipa, morda za postavitev.
+Recimo, da ima vaša ekipa nekaj poverilnic, ki si jih deli vsa ekipa, morda za postavitev.
 Ti so shranjeni v skupni mapi, vendar jih ne želite kopirati v lastno shrambo poverilnic, ker se pogosto spreminjajo.
 Nobeden od obstoječih pomočnikov ne pokriva tega primera; poglejmo, kaj bi bilo potrebno, da napišemo svojega.
 Obstaja več ključnih funkcij, ki jih mora ta program imeti:
@@ -178,7 +178,7 @@ include::../git-credential-read-only[]
     Če se protokol, gostitelj in uporabniško ime iz `known` ujemajo s to vrstico, program natisne rezultate na stdout in se zaključi.
 
 Pomožni pripomoček bomo shranili kot `git-credential-read-only`, ga postavili kamor koli v naš `PATH` in označili kot izvršljivega.
-Takole izgleda interaktivna seja:
+Takole je videti interaktivna seja:
 
 [source,console]
 ----

book/07-git-tools/sections/debugging.asc

@@ -33,7 +33,7 @@ b8b0618cf6fab (Cheng Renquan  2009-05-26 16:03:07 +0800 70)   KBUILD_VERBOSE = $
 
 Opazite, da je prvo polje delni zapis SHA-1 potrditve, ki je zadnja spremenila to vrstico.
 Naslednji dve polji sta vrednosti, ki sta izvlečeni iz te potrditve - ime avtorja in časovno obdobje, ko je bila ta potrditev spremenjena - tako da lahko enostavno vidite, kdo in kdaj je spremenil to vrstico.
-Nato sledijo številka vrstice in vsebina datoteke.
+Nato sledita številka vrstice in vsebina datoteke.
 Opazite tudi vrstice, ki se začnejo z `^1da177e4c3f4` - predpona `^` označuje vrstice, ki so bile uvedene v prvotni potrditvi repozitorija in so ostale nespremenjene vse od takrat.
 To je nekoliko zmedeno, saj ste zdaj videli vsaj tri različne načine, kako Git uporablja `^` za spreminjanje SHA-1 potrditev, vendar to tukaj to pomeni.
 
@@ -69,11 +69,11 @@ Git vam pove, katera potrditev je izvorno vsebovala te vrstice, tudi če je bilo
 [[_binary_search]]
 ==== Dvojiško iskanje
 
-Anotiranje datoteke koristi, če veste, kje je sploh težava.
+Anotiranje datoteke je uporabno, če veste, kje je sploh težava.
 Če ne veste, kaj se je pokvarilo, in je bilo narejenih na desetine ali stotine potrditev od zadnjega stanja, kjer ste vedeli, da vaša koda deluje, se boste za pomoč verjetno obrnili na `git bisect`.
 Ukaz `bisect` opravi dvojiško iskanje skozi vašo zgodovino potrditev, da vam pomaga čim hitreje ugotoviti, katera potrditev je uvedla težavo.
 
-Recimo, da ste pravkar izdali različico vaše kode v produkcijsko okolje, prejemate pa poročila o napaki, ki se ni pojavljala v razvojnem okolju, in ne morete ugotoviti, zakaj se koda obnaša tako.
+Recimo, da ste pravkar izdali različico svoje kode v produkcijsko okolje, prejemate pa poročila o napaki, ki se ni pojavljala v razvojnem okolju, in ne morete ugotoviti, zakaj se koda obnaša tako.
 Vrnili ste se k svoji kodi in ugotovite, da lahko reproducirate težavo, vendar ne morete ugotoviti, kaj gre narobe.
 Za ugotavljanje vzroka težave lahko uporabite _razpolovitev_.
 Najprej zaženete `git bisect start`, da začnete postopek, nato pa uporabite `git bisect bad`, da sistemu sporočite, da je trenutna potrditev pokvarjena.
@@ -100,7 +100,7 @@ Bisecting: 3 revisions left to test after this
 [b047b02ea83310a70fd603dc8cd7a6cd13d15c04] Secure this thing
 ----
 
-Zdaj ste na drugi potrditvi, na pol poti med tisto, ki ste jo pravkar preverili, in vašo slabo potrditvijo.
+Zdaj ste na drugi potrditvi, na pol poti med tisto, ki ste jo pravkar preverili, in svojo slabo potrditvijo.
 Znova zaženete svoj test in ugotovite, da je ta potrditev pokvarjena, zato to sporočite Gitu s pomočjo `git bisect bad`:
 
 [source,console]
@@ -137,7 +137,7 @@ $ git bisect reset
 To je močno orodje, ki vam lahko v nekaj minutah pomaga preveriti na stotine potrditev za napako, ki je bila vnesena.
 Pravzaprav, če imate skripto, ki se bo zaključila z 0, če je projekt v redu, ali neničelno vrednostjo, če je projekt slab, lahko `git bisect` v celoti izvedete samodejno.
 Najprej mu spet sporočite obseg ukaza `bisect` tako, da zagotovite znane slabe in dobre potrditve.
-To lahko storite tako, da jih navedete z ukazom `bisect start`, če želite, tako da prvo navedete znano slabo potrditev, drugo znano dobro potrditev pa drugo:
+To lahko storite tako, da jih navedete z ukazom `bisect start`, če želite, tako da najprej navedete znano slabo potrditev, drugo znano dobro potrditev pa drugo:
 
 [source,console]
 ----