Proofread chapters 3, 4, 5 and 6

Author: petk

C-git-commands.asc

@@ -447,7 +447,7 @@ Ti ukazi vam pomagajo upravljati veje na ta način.
 Ukaz `git cherry-pick` se uporablja za jemanje spremembe, uvedene v eni potrditvi Gita, in poskuša ponovno uvesti kot novo potrditev na veji, na kateri trenutno delate.
 To je lahko koristno, če želite vzeti samo eno ali dve potrditvi iz veje posamezno, namesto da bi združili celotno vejo, ki vključuje vse spremembe.
 
-Postopek izbire najboljšega (ang. "cherry picking") je opisan in prikazan v <<ch05-distributed-git#_rebase_cherry_pick>>.
+Postopek izbire najboljšega (angl. "cherry picking") je opisan in prikazan v <<ch05-distributed-git#_rebase_cherry_pick>>.
 
 ==== git rebase
 

book/01-introduction/sections/installing.asc

@@ -36,7 +36,7 @@ Za več možnosti so na voljo navodila za namestitev na nekaj različnih okusih
 (((macOS, installing)))
 Na voljo je nekaj načinov za namestitev Gita na macOS.
 Najenostavnejše je verjetno namestiti orodja ukazne vrstice Xcode.(((Xcode)))
-Na Mavericks (10.9) ali višjih verzijah lahko to naredite enostavno s poskusom pogona 'git' v Terminalu takoj na začetku.
+Na Mavericks (10.9) ali višjih verzijah lahko to naredite enostavno s poskusom pogona `git` v Terminalu takoj na začetku.
 
 [source,console]
 ----

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

@@ -49,9 +49,9 @@ To mogoče ni velik problem, vendar boste morda presenečeni, kakšno veliko raz
 ==== Git ima integriteto
 
 Vse v Gitu je kontrolirano preko vsot, predno je shranjeno in nato je sklicano glede na to kontrolno vsoto.
-To pomeni, da je nemogoče spremeniti vsebino katerekoli datoteke ali direktorija brez, da bi Git to vedel.
+To pomeni, da je nemogoče spremeniti vsebino katerekoli datoteke ali direktorija, brez da bi Git to vedel.
 Ta funkcionalnost je vgrajena v Git na najnižjem nivoju in je sestavni del njegove filozofije.
-Ne morete izgubiti podatkov med prevozom ali dobiti pokvarjene datoteke brez, da bi Git to zaznal.
+Ne morete izgubiti podatkov med prevozom ali dobiti pokvarjene datoteke, brez da bi Git to zaznal.
 
 Mehanizem, ki ga Git uporablja za to kontroliranje vsot, se imenuje zgoščena vrednost SHA-1.(((SHA-1)))
 To je 40-znakovni niz sestavljen iz znakov šestnajstiškega zapisa (0-9 in a-f) in preračunan na osnovi vsebine datoteke ali strukture direktorijev v Gitu.

book/02-git-basics/sections/aliases.asc

@@ -17,7 +17,7 @@ $ git config --global alias.ci commit
 $ git config --global alias.st status
 ----
 
-To pomeni, da na primer namesto, da vpisujete `git commit`, lahko vpišete zgolj `git ci`.
+To pomeni, da na primer, namesto da vpisujete `git commit`, lahko vpišete zgolj `git ci`.
 Ko nadaljujete uporabo Gita, boste verjetno pogosto uporabljali tudi ostale ukaze; ne odlašajte z izdelavo novih aliasov.
 
 Ta tehnika je lahko zelo uporabna pri izdelavi ukazov, za katere menite, da bi morali obstajati.

book/02-git-basics/sections/recording-changes.asc

@@ -120,7 +120,7 @@ Changes not staged for commit:
 
 ----
 
-Datoteka `CONTRIBUTING.md` se pojavi pod razdelkom imenovan "`Changes not staged for commit`" - kar pomeni, da je bila sledena datoteka spremenjena v delujočem direktoriju, vendar še ni bila dana v področje priprave.
+Datoteka `CONTRIBUTING.md` se pojavi pod razdelkom imenovan "`Changes not staged for commit`" - kar pomeni, da je bila sledena datoteka spremenjena v delovnem direktoriju, vendar še ni bila dana v področje priprave.
 Za dodajanje v področje priprave, poženite ukaz `git add`.
 `git add` je ukaz z več pomeni - uporabite ga za začetek sledenja novih datotek, da daste datoteke v področje priprave in naredite druge stvari, kot je označevanje datotek konfliktov združevanja za rešene.
 Lahko je v pomoč razmišljati o tem bolj v smislu "`dodaj točno to vsebino naslednji potrditvi`", kot pa "`dodaj to datoteko projektu`".(((git commands, add)))
@@ -284,7 +284,7 @@ Iti v podrobnosti večih datotek `.gitignore` je izven obsega te knjige; za več
 In kaj ste dali v področje priprave, da boste potrdili?
 Čeprav `git status` odgovori ta vprašanja zelo splošno z izpisom seznama imen datotek, vam `git diff` prikaže točne vrstice, ki so bile dodane in odstranjene - programski popravek, kakršne so bile.
 
-Recimo, da urejate in ponovno daste v področje priprave datoteko `README` ter nato uredite datoteko `CONTRIBUTING.md` brez, da jo daste v področje priprave.
+Recimo, da urejate in ponovno daste v področje priprave datoteko `README` ter nato uredite datoteko `CONTRIBUTING.md`, brez da jo daste v področje priprave.
 Če poženete vaš ukaz `git status`, vidite ponovno nekaj takega:
 
 [source,console?prompt=$]

book/02-git-basics/sections/viewing-history.asc

@@ -180,7 +180,7 @@ a11bef0 - Scott Chacon, 6 years ago : Initial commit
 |================================
 
 Lahko se sprašujete, kaj je razlika med _avtorjem_ in _potrjevalcem_.
-Avtor (ang. author) je oseba, ki je prvotno napisala delo, potrjevalec (ang. commiter) je pa oseba, ki je zadnja dodala delo.
+Avtor (angl. author) je oseba, ki je prvotno napisala delo, potrjevalec (angl. commiter) je pa oseba, ki je zadnja dodala delo.
 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 <<ch05-distributed-git#ch05-distributed-git>>.
 

book/03-git-branching/sections/basic-branching-and-merging.asc

@@ -10,21 +10,21 @@ Sledili boste tem korakom:
 V tej fazi boste prejeli klic, da je kritična neka druga težava in potrebujete hitri popravek.
 Naredili boste naslednje:
 
-. Preklopite na vašo produkcijsko vejo.
+. Preklopite na svojo produkcijsko vejo.
 . Ustvarite vejo, da dodate hitri popravek.
 . Ko je testiran, združite vejo hitrega popravka in potisnete v produkcijo.
-. Preklopite nazaj na vašo prvotno uporabniško zgodbo in nadaljujete delo.
+. Preklopite nazaj na svojo prvotno uporabniško zgodbo in nadaljujete delo.
 
 [[_basic_branching]]
 ==== Osnove vej
 
 (((branches, basic workflow)))
-Za začetek recimo, da delate na vašem projektu in imate že nekaj potrditev na veji `master`.
+Za začetek recimo, da delate na svojem projektu in imate že nekaj potrditev na veji `master`.
 
 .Enostavna zgodovina potrditev
 image::images/basic-branching-1.png[Enostavna zgodovina potrditev]
 
-Odločili ste se, da boste delali na težavi #53 v kateremkoli sistemu sledenja težav, ki ga vaše podjetje uporablja.
+Odločili ste se, da boste delali na težavi #53 kateregakoli sistema sledenja težav, ki ga vaše podjetje uporablja.
 Da ustvarite vejo in istočasno nanjo preklopite, lahko poženete ukaz `git checkout` s stikalom `-b`:
 
 [source,console]
@@ -44,7 +44,7 @@ $ git checkout iss53
 .Ustvarjanje novega kazalca na vejo
 image::images/basic-branching-2.png[Ustvarjanje novega kazalca na vejo]
 
-Delate na vaši spletni strani in naredite nekaj potrditev.
+Delate na svoji spletni strani in naredite nekaj potrditev.
 S tem se veja `iss53` premakne naprej, ker ste jo izvlekli (to pomeni, da vaš `HEAD` kaže nanjo):
 
 [source,console]
@@ -56,24 +56,24 @@ $ git commit -a -m 'Create new footer [issue 53]'
 .Veja `iss53` se je premaknila naprej z vašim delom
 image::images/basic-branching-3.png[Veja `iss53` se je premaknila naprej z vašim delom]
 
-Sedaj dobite klic, da je težava s spletno stranjo in jo potrebujete takoj popraviti.
-Z Gitom vam ni treba postaviti vašega popravka skupaj s spremembami `iss53`, ki ste jih naredili, in ni vam treba vložiti veliko napora v povračanje teh sprememb, preden lahko delate na nameščanju vašega popravka na to, kar je v produkciji.
+Sedaj dobite klic, da je težava s spletno stranjo in jo morate takoj popraviti.
+Z Gitom vam ni treba postaviti vašega popravka skupaj s spremembami `iss53`, ki ste jih naredili, in ni vam treba vložiti veliko napora v povračanje teh sprememb, preden lahko delate na nameščanju svojega popravka na to, kar je v produkciji.
 Vse kar morate narediti, je preklopiti nazaj na vašo vejo `master`.
 
 Vendar preden to naredite, pomnite, da če ima vaš delovni direktorij ali področje priprave nepotrjene spremembe, ki so v konfliktu z vejo, ki jo izvlečete, vam Git ne bo dovolil preklopiti vej.
 Ko preklapljate veje, je najbolje imeti čisto delovno stanje.
 Obstajajo načini, da se temu izognete (v glavnem, shranjevanje na varno in potrjevanje sprememb), kar bomo pokrili kasneje v <<ch07-git-tools#_git_stashing>>.
-Za sedaj predpostavimo, da ste potrdili vse vaše spremembe, tako da lahko preklopite nazaj na vašo vejo `master`:
+Za sedaj predpostavimo, da ste potrdili vse svoje spremembe, tako da lahko preklopite nazaj na vašo vejo `master`:
 
 [source,console]
 ----
 $ git checkout master
 Switched to branch 'master'
 ----
 
-Na tej točki je vaš delovni direktorij projekta točno tak, kakor je bil preden, ste pričeli delati na težavi #53 in sedaj se lahko skoncentrirate na vaš hitri popravek.
-To je pomembna točka za zapomniti: ko preklapljate veje, Git ponastavi vaš delovni direktorij, da izgleda tako, kot je, ko ste zadnjič naredili potrditev na tej veji.
-Avtomatično doda, odstrani in spremeni datoteke, da zagotovi, da je vaša delovna kopija taka, kot je izgledala veja na vaši zadnji potrditvi na njej.
+Na tej točki je vaš delovni direktorij projekta točno tak, kakor je bil preden, ste začeli delati na težavi #53 in sedaj se lahko osredotočite na svoj hitri popravek.
+To je pomembna točka za zapomniti: ko preklapljate veje, Git ponastavi vaš delovni direktorij, da je videti tako, kot je, ko ste zadnjič naredili potrditev na tej veji.
+Avtomatično doda, odstrani in spremeni datoteke, da zagotovi, da je vaša delovna kopija taka, kot je bila veja na vaši zadnji potrditvi na njej.
 
 Naslednje morate narediti hitri popravek.
 Ustvarimo vejo hitrega popravka `hotfix`, na kateri delate, dokler ni končan:
@@ -91,7 +91,7 @@ $ git commit -a -m 'Fix broken email address'
 .Veja hitrega popravka osnovana na `master`
 image::images/basic-branching-4.png[Veja hitrega popravka osnovana na `master`]
 
-Poženete lahko vaše teste, zagotovite, da je hitri popravek, kakršen ga želite, in na koncu združite vejo `hotfix` nazaj v vašo vejo `master`, da postavite na produkcijo.
+Poženete lahko svoje teste, zagotovite, da je hitri popravek, kakršen ga želite, in na koncu združite vejo `hotfix` nazaj v vašo vejo `master`, da postavite na produkcijo.
 To naredite z ukazom `git merge`:(((git commands, merge)))
 
 [source,console]
@@ -106,14 +106,14 @@ Fast-forward
 
 V tej združitvi boste opazili frazo "`fast-forward`".
 Ker je potrjevanje `C4`, kamor kaže veja `hotfix`, ki ste jo združili, neposredno 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.`"
+Povedano drugače, ko poskušate združiti eno potrditev z drugo, ki je lahko dosegljiva 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 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 programski popravek postavljen, ste pripravljeni preklopiti nazaj k delu, ki ste ga delali, predenso vas zmotili.
+Ko je vaš zelo pomemben hitri programski popravek postavljen, ste pripravljeni preklopiti nazaj k delu, ki ste ga delali, preden so 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`:
 
@@ -123,7 +123,7 @@ $ git branch -d hotfix
 Deleted branch hotfix (3a0874c).
 ----
 
-Sedaj lahko vaše delo preklopite nazaj na vašo vejo dela v teku na težavi #53 in nadaljujete z delom na njej.
+Sedaj lahko vaše delo preklopite nazaj na vašo vejo dela v teku na težavi #53 in nadaljujete delo na njej.
 
 [source,console]
 ----
@@ -139,7 +139,7 @@ $ git commit -a -m 'Finish the new footer [issue 53]'
 image::images/basic-branching-6.png[Delo se nadaljuje na `iss53`]
 
 Tu je vredno omeniti, da delo, ki ste ga naredili na vaši veji `hotfix`, ni vsebovano v datotekah vaše veje `iss53`.
-Če ga potrebujete povleči notri, lahko združite vašo vejo `master` v vašo vejo `iss53` s pogonom `git merge master` ali pa lahko počakate, da integrirate te spremembe, dokler se kasneje ne odločite povleči veje `iss53` nazaj v `master`.
+Če ga morate povleči notri, lahko združite vašo vejo `master` v vašo vejo `iss53` s pogonom `git merge master` ali pa lahko počakate, da integrirate te spremembe, dokler se kasneje ne odločite povleči veje `iss53` nazaj v `master`.
 
 [[_basic_merging]]
 ==== Osnovno združevanje
@@ -159,22 +159,22 @@ index.html |    1 +
 1 file changed, 1 insertion(+)
 ----
 
-To izgleda nekoliko drugače kot združitev `hotfix`, kar ste naredili prej.
+To je nekoliko drugače kot združitev `hotfix`, kar ste naredili prej.
 V tem primeru se je vaša zgodovina razvoja oddaljila od neke starejše točke.
-Ker potrditev na veji, na kateri se nahajate, ni neposredni prednik veje, ki jo združujete, mora Git narediti nekaj dela.
+Ker potrditev na veji, na kateri ste, ni neposredni prednik veje, ki jo združujete, mora Git narediti nekaj dela.
 V tem primeru Git naredi enostavno tri-načinsko združitev z uporabo dveh posnetkov, ki kažeta na vrhove vej in skupnega prednika od teh dveh.
 
 .Trije posnetki uporabljeni pri običajni združitvi
 image::images/basic-merging-1.png[Trije posnetki uporabljeni pri običajni združitvi]
 
-Namesto samo premikanja kazalca veje naprej, Git ustvari nov posnetek, ki rezultira iz te tri-načinske združitve in avtomatično ustvari novo potrditev, ki kaže nanjo.
+Namesto samo premikanja kazalca veje naprej, Git ustvari nov posnetek, ki izhaja iz te tri-načinske združitve in avtomatično ustvari novo potrditev, ki kaže nanjo.
 To se imenuje kot potrditev združitve in je posebno v tem, da ima več kot samo enega starša.
 
 .Potrditev združitve
 image::images/basic-merging-2.png[Potrditev združitve]
 
 Sedaj, ko je vaše delo združeno, nimate več potrebe po veji `iss53`.
-Problem lahko zaprete v vašem sistemu sledenja problemov in vejo izbrišete:
+Problem lahko zaprete v svojem sistemu sledenja problemov in vejo izbrišete:
 
 [source,console]
 ----
@@ -187,7 +187,7 @@ $ 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š programski 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 je videti nekako takole:
 
 [source,console?prompt=$]
 ----
@@ -218,7 +218,7 @@ no changes added to commit (use "git add" and/or "git commit -a")
 
 Karkoli, kar ima konflikte združevanja in niso bili rešeni, je izpisano kot nezdruženo.
 Git doda standardne označevalce reševanja konfliktov v datoteke, ki imajo konflikte, tako da jih lahko odprete ročno in rešite te konflikte.
-Vaša datoteka vsebuje razdelek, ki izgleda nekako takole:
+Vaša datoteka vsebuje razdelek, ki je videti nekako takole:
 
 [source,html]
 ----
@@ -231,8 +231,8 @@ Vaša datoteka vsebuje razdelek, ki izgleda nekako takole:
 >>>>>>> iss53:index.html
 ----
 
-To pomeni, da je različica v `HEAD` (vaše veje `master`, ker ta je bila, kar ste izvlekli, ko ste pognali vaš ukaz združevanja) vrhnji del tega bloka (vse nad `=======`), medtem ko različica v vaši veji `iss53` izgleda kot vse v spodnjem delu.
-Da rešite konflikt, morate bodisi izbrati eno ali drugo stran ali pa združiti vsebino sami.
+To pomeni, da je različica v `HEAD` (vaše veje `master`, ker ta je bila, kar ste izvlekli, ko ste pognali svoj ukaz združevanja) vrhnji del tega bloka (vse nad `=======`), medtem ko je različica v vaši veji `iss53` videti kot ves spodnji del.
+Da rešite konflikt, morate izbrati eno ali drugo stran ali pa združiti vsebino sami.
 Na primer ta konflikt lahko rešite z zamenjavo celotnega bloka s tem:
 
 [source,html]
@@ -246,7 +246,7 @@ Ta rešitev ima malo vsake od obeh razdelkov in vrstice `<<<<<<<`, `=======` in
 Ko ste rešili vsakega od teh razdelkov v vsaki konfliktni datoteki, poženite `git add` na vsaki datoteki, da jo označite kot rešeno.
 Dajanje datoteke v področje priprave jo v Gitu označi kot rešeno.
 
-Če želite uporabiti grafično orodje, da rešite te težave, lahko poženete `git mergetool`, ki zažene ustrezno vizualno združevalno orodje in vas sprehodi skozi konflikte:(((git commands, mergetool)))
+Če želite uporabiti grafično orodje, da rešite te težave, lahko poženete `git mergetool`, ki zažene ustrezno vizualno združevalno orodje in vas pelje na sprehod skozi konflikte:(((git commands, mergetool)))
 
 [source,console]
 ----
@@ -273,9 +273,9 @@ Samo vpišite ime orodja, ki bi ga raje uporabljali.
 Če potrebujete naprednejša orodja za reševanje zapletenih konfliktov združevanja, bomo pokrili več o združevanju v <<ch07-git-tools#_advanced_merging>>.
 ====
 
-Ko zapustite orodje združevanja, vas Git vpraša, če je bila združitev uspešna.
+Ko zapustite orodje združevanja, vas Git vpraša, ali je bila združitev uspešna.
 Če poveste skripti, da je bila, da datoteko v področje priprave, da jo za vas označi kot rešeno.
-Ponovno lahko poženete `git status`, da potrdite, če so bili vsi konflikti rešeni:
+Ponovno lahko poženete `git status`, da potrdite, ali so bili vsi konflikti rešeni:
 
 [source,console]
 ----
@@ -289,8 +289,8 @@ Changes to be committed:
     modified:   index.html
 ----
 
-Č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:
+Č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 je videti nekako takole:
 
 [source,console?prompt=$]
 ----
@@ -315,4 +315,4 @@ Conflicts:
 #
 ----
 
-Če mislite, da bi bilo koristno za ostale, ki bodo nekoč gledali to združevanje, lahko to sporočilo potrditve spremenite s podrobnostmi o tem, kako ste rešili združevanje in razložite, zakaj ste naredili te spremembe, če te niso očitne.
+Če mislite, da bi bilo koristno za druge, ki bodo nekoč gledali to združevanje, lahko to sporočilo potrditve spremenite s podrobnostmi o tem, kako ste rešili združevanje in razložite, zakaj ste naredili te spremembe, če te niso očitne.