-
1. Začetek
- 1.1 O nadzoru različic
- 1.2 Kratka zgodovina Gita
- 1.3 Kaj je Git?
- 1.4 Ukazna vrstica
- 1.5 Namestitev Gita
- 1.6 Prva nastavitev Gita
- 1.7 Pridobivanje pomoči
- 1.8 Povzetek
-
2. Osnove Git
- 2.1 Pridobivanje repozitorija Git
- 2.2 Snemanje sprememb v repozitorij
- 2.3 Pregled zgodovine potrditev
- 2.4 Razveljavljanje stvari
- 2.5 Delo z daljavami
- 2.6 Označevanje
- 2.7 Aliasi Git
- 2.8 Povzetek
-
3. Veje Git
- 3.1 Veje na kratko
- 3.2 Osnove vej in združevanja
- 3.3 Upravljanje vej
- 3.4 Poteki dela z vejami
- 3.5 Oddaljene veje
- 3.6 Ponovno baziranje
- 3.7 Povzetek
-
4. Git na strežniku
- 4.1 Protokoli
- 4.2 Pridobitev Gita na strežniku
- 4.3 Generiranje vaših javnih ključev SSH
- 4.4 Nastavitev strežnika
- 4.5 Prikriti proces Git
- 4.6 Pametni HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Možnosti gostovanja pri tretjih ponudnikih
- 4.10 Povzetek
-
5. Porazdeljeni Git
- 5.1 Porazdeljeni poteki dela
- 5.2 Prispevek k projektu
- 5.3 Vzdrževanje projekta
- 5.4 Povzetek
-
6. GitHub
-
7. Orodja Git
- 7.1 Izbira revizije
- 7.2 Interaktivno pripravljanje
- 7.3 Shranjevanje na varno (angl. stashing) in čiščenje
- 7.4 Podpisovanje vašega dela
- 7.5 Iskanje
- 7.6 Prepisovanje zgodovine
- 7.7 Demistifikacija ponastavitve
- 7.8 Napredno združevanje
- 7.9 Rerere
- 7.10 Razhroščevanje z Gitom
- 7.11 Podmoduli
- 7.12 Povezovanje v pakete
- 7.13 Zamenjava
- 7.14 Shramba poverilnic
- 7.15 Povzetek
-
8. Prilagoditev Gita
- 8.1 Konfiguracija Git
- 8.2 Atributi Git
- 8.3 Kljuke Git
- 8.4 Primer pravilnika, ki ga uveljavlja Git
- 8.5 Povzetek
-
9. Git in ostali sistemi
- 9.1 Git kot odjemalec
- 9.2 Migracija na Git
- 9.3 Povzetek
-
10. Notranjost Gita
- 10.1 Napeljava in keramika
- 10.2 Objekti Git
- 10.3 Reference Git
- 10.4 Packfiles (datoteke zmanjšanih podatkov)
- 10.5 Refspec
- 10.6 Protokoli prenosa
- 10.7 Vzdrževanje in obnovitev podatkov
- 10.8 Spremenljivke okolja
- 10.9 Povzetek
-
A1. Dodatek A: Git v drugih okoljih
- A1.1 Grafični vmesniki
- A1.2 Git v Visual Studio
- A1.3 Git v Visual Studio Code
- A1.4 Git v IntelliJ / PyCharm / WebStorm / PhpStorm / RubyMine
- A1.5 Git v Sublime Text
- A1.6 Git v Bashu
- A1.7 Git v Zsh
- A1.8 Git v Powershellu
- A1.9 Povzetek
-
A2. Dodatek B: Vdelava Gita v vašo aplikacijo
- A2.1 Git v ukazni vrstici
- A2.2 Libgit2
- A2.3 JGit
- A2.4 go-git
- A2.5 Dulwich
-
A3. Dodatek C: Ukazi Git
- A3.1 Nastavitev in konfiguracija
- A3.2 Pridobivanje in ustvarjanje projektov
- A3.3 Osnove posnetkov
- A3.4 Veje in združevanje
- A3.5 Deljenje in posodabljanje projektov
- A3.6 Pregled in primerjava
- A3.7 Razhroščevanje
- A3.8 Popravljanje
- A3.9 E-pošta
- A3.10 Zunanji sistemi
- A3.11 Administracija
- A3.12 Orodja za sisteme napeljave
8.1 Prilagoditev Gita - Konfiguracija Git
Do sedaj smo pokrili osnove, kako Git deluje, kako ga uporabljati in predstavili smo vrsto orodij, ki jih Git ponuja, da vam pomaga pri enostavni in učinkoviti uporabi. V tem poglavju bomo pogledali, kaj lahko naredite, da Git deluje na bolj prilagojeni način s predstavitvijo nekaj pomembnih konfiguracijskih nastavitev in sistema kljuk. S temi orodji je enostavno narediti, da Git dela točno na način, ki ga vi, vaše podjetje, ali vaša skupina potrebuje.
Konfiguracija Git
Kot ste na kratko prebrali v poglavju Začetek, lahko s pomočjo ukaza git config
nastavite konfiguracijske nastavitve Git.
Eden izmed prvih korakov je bil, da ste nastavili svoje ime in e-poštni naslov:
$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com
Sedaj boste spoznali nekaj bolj zanimivih možnosti, ki jih lahko na ta način nastavite, da prilagodite uporabo Gita.
Najprej hiter povzetek: Git uporablja niz konfiguracijskih datotek, da določi obnašanje, ki ni privzeto.
Prvo mesto, kjer Git išče te vrednosti, je sistemska datoteka [path]/etc/gitconfig
, ki vsebuje nastavitve, ki se uporabljajo za vsakega uporabnika v sistemu in za vse njihove repozitorije.
Če pri git config
podate možnost --system
, se prebere in piše izključno iz te datoteke.
Naslednje mesto, kjer Git išče, je datoteka ~/.gitconfig
(ali ~/.config/git/config
), ki je specifična za vsakega uporabnika.
Do te datoteke lahko Git bere in piše z uporabo možnosti --global
.
Nazadnje Git išče vrednosti konfiguracije v datoteki konfiguracije v direktoriju Git (.git/config
) tega repozitorija, s katerim trenutno delate.
Te vrednosti so specifične za ta posamezni repozitorij in predstavljajo podajanje možnosti --local
pri git config
.
Če ne navedete, s katero ravnjo želite delati, je to privzeto.
Vsaka od teh »ravni« (sistem, globalno, lokalno) prepisuje vrednosti v prejšnji ravni, zato na primer vrednosti v .git/config
prevladujejo nad tistimi v [path]/etc/gitconfig
.
Opomba
|
Gitove konfiguracijske datoteke so navadne besedilne datoteke, zato lahko te vrednosti nastavite tudi z ročnim urejanjem datoteke in vstavljanjem pravilne sintakse.
Vendar je običajno lažje uporabiti ukaz |
Osnovna konfiguracija odjemalca
Konfiguracijske možnosti, ki jih prepozna Git, se delijo na dve kategoriji: tiste na strani odjemalca in tiste na strani strežnika. Večina možnosti je namenjenih odjemalcu — konfiguriranju vaših osebnih delovnih nastavitev. Podprte so številne konfiguracijske možnosti, vendar je velik delež uporaben samo v določenih robnih primerih; tukaj bomo obravnavali le najpogostejše in najbolj uporabne možnosti. Če želite videti seznam vseh možnosti, ki jih prepozna vaša različica Gita, lahko zaženete:
$ man git-config
Ta ukaz izpiše vse možnosti, ki so na voljo, skupaj s podrobnostmi. Referenčno dokumentacijo najdete lahko tudi na https://git-scm.com/docs/git-config.
Opomba
|
Za naprednejše primere uporabe boste morda želeli pogledati »Conditional includes« v dokumentaciji zgoraj. |
core.editor
Za ustvarjanje in urejanje vaših sporočil potrditev in oznak Git privzeto uporabi privzeti urejevalnik besedila, ki ste ga nastavili prek ene od spremenljivk okolja lupine VISUAL
ali EDITOR
, ali pa privzeto uporabi urejevalnik vi
.
Da spremenite privzeti urejevalnik na nekaj drugega, lahko uporabite nastavitev core.editor
:
$ git config --global core.editor emacs
Sedaj, ne glede na to, kaj je nastavljeno kot privzeti urejevalnik lupine, bo Git zagnal Emacs za urejanje sporočil.
commit.template
Če to nastavite na pot do datoteke na svojem sistemu, bo Git to datoteko uporabil kot privzeto začetno sporočilo, ko izvedete potrditev. Prednost uporabe prilagojene predloge za potrditev je, da si s tem lahko pomagate, da se spomnite (ali da se drugi spomnijo) pravilne oblike in sloga pri ustvarjanju sporočila o potrditvi.
Na primer, razmislite o datoteki predloge na ~/.gitmessage.txt
, ki je videti takole:
Subject line (try to keep under 50 characters)
Multi-line description of commit,
feel free to be detailed.
[Ticket: X]
Opazite, kako ta predloga za potrditev spomni potrjevalca, naj obdrži kratko vrstico z naslovom (zaradi izhoda git log --oneline
), da doda podrobnejše informacije pod tem naslovom in da se sklicuje na številko sledilnika težav ali napak, če ta obstaja.
Da Gitu poveste, naj ga uporabi kot privzeto sporočilo, ki se prikaže v vašem urejevalniku, ko zaženete git commit
, nastavite vrednost konfiguracije commit.template
:
$ git config --global commit.template ~/.gitmessage.txt
$ git commit
Nato bo vaš urejevalnik odprl nekaj takega za vaše rezervirano mesto sporočila potrditve, ko potrdite:
Subject line (try to keep under 50 characters)
Multi-line description of commit,
feel free to be detailed.
[Ticket: X]
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: lib/test.rb
#
~
~
".git/COMMIT_EDITMSG" 14L, 297C
Č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 verjetnost, da se ta pravilnik redno upošteva.
core.pager
Ta nastavitev določa, katero številčenje strani se uporabi, ko Git prikazuje izpis, kot je log
ali diff
.
Nastavite ga lahko na more
ali na svoj najljubši pager (privzeto je less
), lahko pa ga izklopite, tako da ga nastavite na prazen niz:
$ git config --global core.pager ''
Če to poženete, bo Git prikazoval izpis vseh ukazov po straneh, ne glede na to, kako so dolge.
user.signingkey
Če ustvarjate podpisane anotirane oznake (kot je opisano v razdelku Podpisovanje vašega dela), nastavitev vašega ključa GPG kot konfiguracijske nastavitve olajša stvari. Nastavite svoj ID ključa na naslednji način:
$ git config --global user.signingkey <gpg-key-id>
Sedaj lahko podpišete oznake, brez da morate vsakič določiti vaš ključ z ukazom git tag
:
$ git tag -s <tag-name>
core.excludesfile
V datoteko .gitignore
vašega projekta lahko dodate vzorce, da Git teh datotek ne vidi kot nedodane ali da jih ne poskuša dodati v področje priprave, ko jih dodate z git add
, kot je opisano v razdelku Ignoriranje datotek.
Včasih pa želite prezreti določene datoteke za vse repozitorije, s katerimi delate.
Če uporabljate računalnik z operacijskim sistemom macOS, verjetno poznate datoteke .DS_Store
.
Če je vaš priljubljeni urejevalnik Emacs ali Vim, poznate imena datotek, ki se končajo s ~
ali .swp
.
Ta nastavitev vam omogoča pisanje neke vrste globalne datoteke .gitignore
.
Če ustvarite datoteko ~/.gitignore_global
s to vsebino:
*~
.*.swp
.DS_Store
… in nato poženete git config --global core.excludesfile ~/.gitignore_global
, vas Git ne bo več motil o teh datotekah.
help.autocorrect
Če napačno vpišete ukaz, vam bo pokazal nekaj takega:
$ git chekcout master
git: 'chekcout' is not a git command. See 'git --help'.
The most similar command is
checkout
Git poskuša ugotoviti, kaj ste mislili, vendar še vedno zavrne ukaz.
Če nastavite help.autocorrect
na 1, bo Git dejansko zagnal ta ukaz za vas:
$ git chekcout master
WARNING: You called a Git command named 'chekcout', which does not exist.
Continuing under the assumption that you meant 'checkout'
in 0.1 seconds automatically...
Upoštevajte to stvar z »0,1 sekunde«.
help.autocorrect
je dejansko celo število, ki predstavlja desetinke sekunde.
Če ga nastavite na 50, vam bo Git dal 5 sekund časa, da spremenite svoje mnenje, preden izvede samopopravljajoči se ukaz.
Barve v Gitu
Git popolnoma podpira obarvano terminalno izhodno sporočilo, kar močno pomaga pri vizualnem razčlenjevanju izhodov ukazov hitro in enostavno. Precej možnosti vam lahko pomaga nastaviti barvanje po željah.
color.ui
Git samodejno obarva večino svojega izhoda, vendar obstaja glavno stikalo, če vam ta funkcionalnost ni všeč. Če želite izklopiti vse barvne terminalne izhode Gita, to storite tako:
$ git config --global color.ui false
Privzeta nastavitev je auto
, ki obarva izhod, ko gre neposredno v terminal, vendar izpusti nadzorne kode za barve, ko se izhod preusmeri v cev ali datoteko.
Lahko ga nastavite tudi na always
, da prezrete razliko med terminali in cevmi.
To boste redko želeli; v večini scenarijev, če želite barvne kode v svojem preusmerjenem izhodu, lahko namesto tega uporabite zastavico --color
za ukaz Git, da ga prisilite k uporabi barvnih kod.
Privzeta nastavitev je skoraj vedno tisto, kar želite.
color.*
Če želite biti bolj natančni glede tega, kateri ukazi so obarvani in kako, Git ponuja nastavitve barvanja, specifične za glagole.
Vsako od teh lahko nastavite na true
, false
ali always
:
color.branch color.diff color.interactive color.status
Poleg tega ima vsaka od teh tudi podnastavitve, ki jih lahko uporabite za nastavitev posebnih barv za dele izhoda, če želite preglasiti vsako barvo. Na primer, da nastavite meta informacije v svojem diferenčnem izpisu na modro ozadje in krepko besedilo, lahko zaženete:
$ git config --global color.diff.meta "blue black bold"
Barvo lahko nastavite na katero koli od naslednjih vrednosti: normal
, black
, red
, green
, yellow
, blue
, magenta
, cyan
, ali white
.
Če želite atribut, kot je krepko besedilo v prejšnjem primeru, lahko izbirate med bold
, dim
, ul
(podčrtano), blink
in reverse
(zamenjava sprednjega in zadnjega zaslona).
Zunanja orodja za združevanja in razlike
Git ima vgrajeno implementacijo orodja diff, ki smo ga prikazovali v tej knjigi, vendar lahko namesto tega nastavite zunanje orodje. Namesto ročnega reševanja konfliktov lahko nastavite tudi grafično orodje za reševanje konfliktov. Pokazali bomo, kako nastaviti orodje za grafično združevanje in ločevanje datotek Perforce Visual Merge Tool (P4Merge), ker je lepo grafično orodje in je brezplačno.
Če želite to preizkusiti, lahko P4Merge uporabite na vseh glavnih platformah.
V primerih bomo uporabljali imena poti, ki delujejo v sistemih macOS in Linux; za Windows boste morali spremeniti /usr/local/bin
v izvršljivo pot v vašem okolju.
Najprej prenesite P4Merge iz Perforce.
Nato boste nastavili zunanje vgradne skripte za zagon ukazov.
V primeru uporabljamo pot macOS za izvršljiv program; v drugih sistemih bo tam, kjer je nameščena vaša binarna datoteka p4merge
.
Nastavite vgradni skript za združevanje z imenom extMerge
, ki kliče vašo binarno datoteko z vsemi podanimi argumenti:
$ cat /usr/local/bin/extMerge
#!/bin/sh
/Applications/p4merge.app/Contents/MacOS/p4merge $*
Ovojnica diff preveri, da je bilo zagotovljenih sedem argumentov in dva od njih prenese vaš združitveni skript. Git privzeto prenaša naslednje argumente programu diff:
path old-file old-hex old-mode new-file new-hex new-mode
Ker želite samo argumenta old-file
in new-file
, uporabite ovojni skript, da podate tiste, ki jih potrebujete.
$ cat /usr/local/bin/extDiff
#!/bin/sh
[ $# -eq 7 ] && /usr/local/bin/extMerge "$2" "$5"
Zagotoviti morate tudi, da so ta orodja izvršljiva:
$ sudo chmod +x /usr/local/bin/extMerge
$ sudo chmod +x /usr/local/bin/extDiff
Zdaj lahko nastavite konfiguracijsko datoteko, da uporablja vaše prilagojeno orodje za združevanje in orodja za razlike.
To zahteva številne prilagojene nastavitve: merge.tool
, da Gitu pove, katero strategijo naj uporabi, mergetool.<tool>.cmd
, da določi, kako naj se ukaz izvede, mergetool.<tool>.trustExitCode
, da pove Gitu, ali izhodna koda tega programa označuje uspešno združitev ali ne, in diff.external
, da pove Gitu, kateri ukaz naj se uporabi za razlike.
Tako lahko izvedete štiri ukazne konfiguracije:
$ git config --global merge.tool extMerge
$ git config --global mergetool.extMerge.cmd \
'extMerge "$BASE" "$LOCAL" "$REMOTE" "$MERGED"'
$ git config --global mergetool.extMerge.trustExitCode false
$ git config --global diff.external extDiff
ali pa uredite vašo datoteko ~/.gitconfig
, da dodate te vrstice:
[merge]
tool = extMerge
[mergetool "extMerge"]
cmd = extMerge "$BASE" "$LOCAL" "$REMOTE" "$MERGED"
trustExitCode = false
[diff]
external = extDiff
Ko je vse to nastavljeno in če poženete ukaze diff
, kot je:
$ git diff 32d1776b1^ 32d1776b1
Namesto da dobite izpis razlike v ukazni vrstici, bo Git zagnal P4Merge, ki je videti nekako takole:
![P4Merge](png/p4merge.png)
Če poskušate združiti dve veji in imate nato konflikte med združevanjem, lahko za reševanje konfliktov uporabite ukaz git mergetool
, ki začne program P4Merge in vam omogoča reševanje konfliktov preko grafičnega uporabniškega vmesnika tega orodja.
Lepa stvar pri tem sistemu ovijanja je, da lahko svoja orodja za primerjavo in združevanje preprosto spremenite.
Na primer, če želite svoja orodja extDiff
in extMerge
zamenjati z orodjem KDiff3, morate le urediti svojo datoteko extMerge
:
$ cat /usr/local/bin/extMerge
#!/bin/sh
/Applications/kdiff3.app/Contents/MacOS/kdiff3 $*
Git bo sedaj uporabljal orodje KDiff3 za prikazovanje razlik in razreševanje konfliktov združevanja.
Git je nastavljen tako, da uporablja vrsto drugih orodij za razreševanje združevanja, ne da bi morali nastaviti konfiguracijo cmd. Za ogled seznama podprtih orodij poskusite to:
$ git mergetool --tool-help
'git mergetool --tool=<tool>' may be set to one of the following:
emerge
gvimdiff
gvimdiff2
opendiff
p4merge
vimdiff
vimdiff2
The following tools are valid, but not currently available:
araxis
bc3
codecompare
deltawalker
diffmerge
diffuse
ecmerge
kdiff3
meld
tkdiff
tortoisemerge
xxdiff
Some of the tools listed above only work in a windowed
environment. If run in a terminal-only session, they will fail.
Če vas ne zanima uporaba KDiff3 za primerjavo, ampak ga želite uporabiti le za razreševanje združitev in je kdiff3 ukaz v vaši poti, potem lahko zaženete:
$ git config --global merge.tool kdiff3
Če to izvedete namesto nastavljanja datotek extMerge
in extDiff
, bo Git za reševanje konfliktov uporabil KDiff3, za primerjavo pa normalno orodje za primerjavo Git.
Oblikovanje in prazni znaki
Oblikovne težave in težave praznih znakov so nekatere najbolj frustrirajočih in subtilnih težav, s katerimi se srečujejo številni razvijalci pri sodelovanju, še posebej če gre za sodelovanje na različnih platformah. Zelo lahko se zgodi, da oblika zapisa datoteke spreminja subtilne spremembe praznih znakov, saj urejevalniki teh sprememb ne oglašujejo in če se datoteke kdaj dotaknejo sistema Windows, se lahko spremenijo razmiki med vrsticami datotek. Git ima nekaj možnosti konfiguracije, ki pomagajo pri teh težavah.
core.autocrlf
Če programirate v operacijskem sistemu Windows in delate z ljudmi, ki tega ne uporabljajo (ali obratno), boste verjetno prej ali slej naleteli na težave z zaporedji konca vrstice. To je zato, ker Windows za nove vrstice v datotekah uporablja tako znak CR (angl. carriage return) kot tudi znak za prelom vrstice LF (angl. linefeed), medtem ko macOS in sistemi Linux uporabljajo samo znak za prelom vrstice LF. To je subtilen, a izjemno nadležen vidik dela na različnih platformah; mnogi urejevalniki na Windowsu tiho zamenjajo obstoječe LF-zaporedje konca vrstice s CRLF ali pa uporabniku pri pritisku na tipko enter vstavijo oba znaka zaporedja konca vrstice.
Git se s tem spopada tako, da samodejno pretvori zaporedja CRLF v LF, ko datoteko dodate v indeks, in obratno, ko izvleče kodo na vaš datotečni sistem.
To funkcionalnost lahko vklopite s pomočjo nastavitve core.autocrlf
.
Če uporabljate računalnik z operacijskim sistemom Windows, ga nastavite na true
— ta nastavitev pretvori LF v CRLF ob izvleku kode.
$ git config --global core.autocrlf true
Če delate na sistemu Linux ali macOS, ki uporablja konce vrstic LF, potem ne želite, da Git samodejno pretvarja konce vrstic, ko izvlečete datoteke; vendar, če se datoteka s konci CRLF nenamerno uvede, potem morda želite, da Git to popravi.
Gitu lahko poveste, naj pretvori CRLF v LF ob potrditvi, vendar ne obratno, tako da nastavite core.autocrlf
na input
:
$ git config --global core.autocrlf input
Ta nastavitev bi morala pustiti konce CRLF v izvlekih kode na sistemu Windows, vendar konce LF v macOS in sistemih Linux ter v repozitoriju.
Če ste programer v okolju Windows in delate na projektu, ki je namenjen samo Windowsu, potem lahko to funkcionalnost zajemanja znakov CR v repozitoriju izklopite tako, da nastavitveno vrednost nastavite na false
:
$ git config --global core.autocrlf false
core.whitespace
Git je privzeto nastavljen za odkrivanje in odpravljanje nekaterih težav s praznimi znaki. Lahko išče šest osnovnih težav s praznimi znaki — tri so privzeto omogočene in jih je mogoče izklopiti, tri pa so privzeto onemogočene, vendar jih je mogoče aktivirati.
Privzeto so omogočene tri: blank-at-eol
, ki išče presledke na koncu vrstice; blank-at-eof
, ki opazi prazne vrstice na koncu datoteke; in space-before-tab
, ki išče presledke pred tabulatorji na začetku vrstice.
Tri, ki so privzeto onemogočene, jih je mogoče vklopiti: indent-with-non-tab
, ki išče vrstice, ki se začnejo s presledki namesto tabulatorji (in ga nadzoruje možnost tabwidth
); tab-in-indent
, ki opazuje tabulatorje v delu zamika vrstice; in cr-at-eol
, ki Gitu sporoči, da so na koncu vrstic sprejemljivi prehodi v novo vrstico znaki CR (angl. carriage return).
Gitu lahko sporočite, katere izmed teh možnosti želite omogočiti, tako da nastavite core.whitespace
na vrednosti, ki jih želite vklopiti ali izklopiti, ločenimi z vejicami.
Možnost lahko izklopite tako, da pred njenim imenom dodate -
, ali pa uporabite privzeto vrednost tako, da jo pustite izven nastavitvene vrstice.
Na primer, če želite nastaviti vse razen space-before-tab
, lahko to storite tako (pri čemer je trailing-space
bližnjica, ki zajema tako blank-at-eol
kot tudi blank-at-eof
):
$ git config --global core.whitespace \
trailing-space,-space-before-tab,indent-with-non-tab,tab-in-indent,cr-at-eol
Ali pa določite samo del prilagoditve:
$ git config --global core.whitespace \
-space-before-tab,indent-with-non-tab,tab-in-indent,cr-at-eol
Git bo zaznal te težave, ko zaženete ukaz git diff
, in jih poskusil obarvati, tako da jih lahko morda popravite pred potrditvijo.
Prav tako bo uporabil te vrednosti, da vam pomaga, ko uporabljate popravke z git apply
.
Ko uporabljate popravke, lahko Git zaprosite, naj vas opozori, ali uporablja popravke s posebnimi težavami s praznimi znaki z naslednjim ukazom:
$ git apply --whitespace=warn <patch>
Ali pa določite, da Git poskusi avtomatsko popraviti težavo preden uporabi programski popravek:
$ git apply --whitespace=fix <patch>
Te možnosti veljajo tudi za ukaz git rebase
.
Če ste zabeležili težave s praznimi znaki, vendar jih še niste potisnili navzgor, lahko za popravljanje samodejno uporabite git rebase --whitespace=fix
, ko prepiše popravke.
Konfiguracija strežnika
Ni na voljo veliko konfiguracijskih možnosti za strežniško stran Gita, vendar obstaja nekaj zanimivih, na katere bi se morda želeli osredotočiti.
receive.fsckObjects
Git lahko poskrbi, da se vsak objekt, prejet med potiskanjem, še vedno ujema s svojo kontrolno vsoto SHA-1 in kaže na veljavne objekte.
Vendar pa tega privzeto ne stori; to je precej draga operacija in lahko upočasni postopek, še posebej pri velikih repozitorijih ali potiskanjih.
Če želite, da Git preveri skladnost objektov ob vsakem potiskanju, ga lahko prisilite, da to stori z nastavitvijo receive.fsckObjects
na true
:
$ git config --system receive.fsckObjects true
Zdaj bo Git preveril celovitost vašega repozitorija, preden sprejme kakršnokoli potiskanje, da se prepriča, da napačni (ali zlonamerni) odjemalci ne uvajajo pokvarjenih podatkov.
receive.denyNonFastForwards
Če boste ponovno bazirali že potisnjene potrditve in poskušali ponovno potisniti, ali poskušali potisniti potrditev na oddaljeno vejo, ki ne vsebuje potrditve, na katero trenutno kaže oddaljena veja, boste zavrnjeni.
To je na splošno dobra praksa, vendar v primeru ponovnega baziranja morda veste, kaj počnete, in tako lahko prisilite posodobitev oddaljene veje z zastavico -f
v ukazu potiskanja.
Da Gitu sporočite, naj zavrne prisilna potiskanja, nastavite receive.denyNonFastForwards
:
$ git config --system receive.denyNonFastForwards true
Drug način, kako to storite, je prek prejemnih kljuk na strežniku, o čemer bomo podrobneje razpravljali malo kasneje. Ta pristop vam omogoča izvajanje bolj zapletenih ukazov, na primer zavračanje nehitrih previjanj naprej za določeno skupino uporabnikov.
receive.denyDeletes
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
:
$ git config --system receive.denyDeletes true
To prepove vsako brisanje vej ali oznak — noben uporabnik tega ne more storiti. Za odstranitev oddaljenih vej morate datoteke ref na strežniku odstraniti ročno. Za to obstajajo tudi bolj zanimivi načini na uporabniški ravni prek ACL, kot se boste naučili v Primer pravilnika, ki ga uveljavlja Git.