Git 🌙
Chapters ▾ 2nd Edition

8.1 Pag-aangkop sa Sariling Pangangailagan ng Git - Kompigurasyon ng Git

Sa ngayon, natalakay natin ang mga pangunahing kaalaman kung paano gumagana ang Git at kung paano gamitin ito, at ipinakilala namin ang ilang mga kasangkapan na ibinibigay ng Git upang matulungan kang gamitin ito nang madali at mahusay. Sa kabanatang ito, makikita natin kung paano mo gawin ang Git na gumana sa isang mas pinasadyang paraan, sa pamamagitan ng pagpapakilala ng ilang mahalagang mga setting ng pagsasaayos at ang sistema ng mga hook. Gamit ang mga kasangkapan na ito, madali mong makukuha ang Git para gumana nang eksakto sa iyong paraan, sa iyong kumpanya, o sa pangangailangan ng iyong grupo.

Kompigurasyon ng Git

Habang binabasa mo agad sa Pagsisimula, matutukoy mo ang Kompigurasyon ng Git sa git config na utos. Isa sa mga unang bagay na dapat mong gawin ay i-set up ang iyong pangalan at email address:

$ git config --global user.name "John Doe"
$ git config --global user.email johndoe@example.com

Ngayon matututunan mo ang ilan sa mga mas interesanteng mga pagpipilian na maaari mong itakda sa ganitong paraan upang i-customize ang iyong paggamit sa Git.

Una, isang mabilis na pagsusuri: Gumagamit ang Git ng isang serye ng mga kompigurasyon na file upang matukoy ang non-default behavior na maaaring gusto mo. Ang unang titingnan ng Git para sa mga halagang ito ay ang buong sistema ng /etc/gitconfig na file, na naglalaman ng mga setting na inilapat sa bawat user sa sistema at lahat ng kanilang mga repositoryo. Kung dadaanan mo ang --system na opsyon sa git config, binabasa at sinulat nito mula sa partikular na file na ito.

Ang susunod na lugar na titingnan ng Git ay ang ~/.gitconfig (o ~/.config/git/config) na file, kung saan ay tiyak sa bawat gumagamit. Maaaring gawin ng Git na bumasa at sumulat sa file na ito sa pamamagitan ng pagpapasa ng --global na opsyon.

Panghuli, hinahanap ng Git ang mga halaga ng kompigurasyon sa file ng kompigurasyon sa direktoryo ng Git (.git/config) na anumang repositoryo na kasalukuyang ginagamit mo.

Ang mga halagang ito ay tiyak sa isang solong repositoryo, at kumakatawan sa pagpasa ng --local na opsyon hanggang git config. (Kung hindi mo matukoy kung aling antas ang gusto mong magtrabaho, ito ang default.)

Ang bawat isa sa mga “antas” (sistema, pandaigdigan, lokal) ay nagpapalit ng mga halaga sa nakaraang antas, halimbawa, kaya ang mga halaga sa .git / config trump sa mga nasa /etc/gitconfig.

Ang mga file ng kompigurasyon ng Git ay plain-text, kaya maaari mo ring itakda ang mga halagang ito sa pamamagitan ng pag-edit ng file nang manu-mano at pagpasok ng tamang syntax. Bagaman, karaniwang mas madaling patakbuhin ang git config na utos.

Basic Client Kompigurasyon

Ang mga pagpipilian sa kompigurasyon na kinikilala ng Git ay may dalawang kategorya: client-side at server-side. Ang karamihan sa mga pagpipilian ay client-side — i-kompigura ang mga personal na kagustuhan sa iyong ginagawa. Karamihan, ang maraming mga opsyon sa kompigurasyon ay sinusuportahan, ngunit ang isang malaking bahagi nito ay magagamit sa piling mga pagkakataon lamang; sinasaklaw lamang namin ang pinaka-karaniwan at kapaki-pakinabang na mga pagpipilian dito. Kung nais mong makita ang listahan ng lahat ng mga opsyon na kinikilala ng iyong bersyon ng Git, maaari mong patakbuhin

$ man git-config

Ang lahat ng magagamit na mga opsyon sa mga listahan ng utos ay mas detalyado Maaari mo ring mahanap ang materyal ng reperensya sa http://git-scm.com/docs/git-config.html.

core.editor

Bilang default, ginagamit ng Git ang kahit anong itinakda mo bilang iyong default na editor ng teksto sa pamamagitan ng isa sa mga shell enviroment variable VISUAL o` EDITOR`, o kaya ay bumabalik sa editor ng vi upang lumikha at mag-edit ng iyong na i-commit at na tag na mga mensahe. Upang baguhin ang default sa ibang bagay, maaari mong gamitin ang core.editor na setting:

$ git config --global core.editor emacs

Sa ngayon, hindi mahalaga kung ano ang itinakda bilang iyong default na editor ng shell, ang Git ay gagamitin ang Emacs upang mag-edit ng mga mensahe.

commit.template

Kung itinakda mo ito sa path ng file sa iyong sistema, ang Git ay gagamitin ang file bilang unang mensahe na default kapag ikaw ay nag-commit. Ang halaga sa paglikha ng pasadyang commit template ay maaari itong gamitin upang paalalahanan ang iyong sarili (o ang iba) ng tamang pormat at istilo kapag lumilikha ng mensahe na i-commit.

Halimbawa, tignan ang template file sa ~/.Gitmessage.txt na mukhang ganito:

Linya ng paksa (subukan na panatilihin sa ilalim ng 50 character)

Maraming linya sa paglalarawan ng commit,
Huwag mag-atubiling i-detalyado.

[Ticket: X]

Pansinin kung paano nagpapaalala ang template na ito sa taga-commit upang panatilihing maikli ang linya ng paksa (para sa kapakanan ng git log --oneline na output), upang magdagdag ng karagdagang detalye sa ilalim nito, at upang sumangguni sa isang isyu o numero ng tiket ng tracker ng bug kung umiiral ito. To tell Git to use it as the default message that appears in your editor when you run git commit, set the commit.template configuration value:

Upang sabihin sa Git na gamitin ito bilang default na mensahe na lumilitaw sa iyong editor kapag nagpatakbo ka ng git commit, i-set ang commit.template na halaga ng kompigurasyon:

$ git config --global commit.template ~/.gitmessage.txt
$ git commit

Pagkatapos, magbubukas ang iyong editor sa isang bagay na tulad nito para sa iyong paglalagyan ng mensahe ng commit kapag nag-commit ka:

Linya ng paksa (subukan na panatilihin sa ilalim ng 60 character)

Maraming linya sa paglalarawan ng commit,
Huwag mag-atubiling i-detalyado.

[Ticket: X]
# Mangyaring ipasok ang mensahe ng commit para sa iyong mga pagbabago. Mga linyang nagsisimula
# sa '#' ay hindi papansinin, at ang isang walang laman na mensahe ay magbibigo sa commit.
# Sa master ng branch
# Mga pagbabago na i-commit:
#   (use "git reset HEAD <file>..." to unstage)
#
# modified:   lib/test.rb
#
~
~
".git/COMMIT_EDITMSG" 14L, 297C

Kung ang iyong pangkat ay may patakaran sa mensahe ng commit, ang paglalagay ng isang template para sa patakarang iyon sa iyong sistema at pagkompigura sa Git na gamitin ito na default ay maaaring makatulong sa pagtaas ng pagkakataon ng patakarang iyon na regular na sinusunod.

core.pager

Tinutukoy ng setting na ito kung alin sa pager ang ginamit kung ang mga pahina ng output ng Git ay log at diff. Maaari mo itong itakda sa more o sa iyong paboritong pager (bilang default, ito ay less), o maaari mong isara ito sa pamamagitan ng pagtatakda nito sa isang blangko na string:

$ git config --global core.pager ''

Kung patatakbuhin mo yan, ang Git ay magpe-page sa buong output sa lahat ng mga utos, gaano man kahaba sila.

user.signingkey

Kung gumagawa ka ng naka-sign na anotado na mga tag (tulad ng tinalakay sa Pag-sign sa Iyong Trabaho), pagtatakda sa iyong GPG na susi sa pag-sign bilang isang setting na kompigurasyon ay mas pinadali ang mga bagay. Itakda ang iyong ID na susi katulad nito:

$ git config --global user.signingkey <gpg-key-id>

Ngayon, maaari kang mag-sign ng mga tag nang hindi na kailangang tukuyin ang iyong susi sa bawat oras sa paggamit ng git tag na utos:

$ git tag -s <tag-name>

core.excludesfile

Maaari kang maglagay ng mga pattern sa iyong proyektong .gitignore na file upang hindi makita ang mga ito ng Git bilang mga untracked na file o subukang i-stage sila kung patatakbuhin mo ang git add sa kanila, tulad ng tinalakay sa Pagbalewala ng mga File.

Ngunit kung minsan gusto mong huwag pansinin ang ilang mga file para sa lahat ng mga repositoryo na nagtatrabaho ka. Kung ang iyong kompyuter ay tumatakbo sa macOS, marahil ikaw ay pamilyar sa .DS_Store na mga file. Kung ang iyong ginustong editor ay Emacs or Vim, alam mo ang tungkol sa mga filename na nagtatapos sa isang ~ o .swp.

Ang setting na ito ay nagpapahintulot sa iyo na magsulat ng isang uri ng pandaigdigang .gitignore na file Kung gumawa ka ng ~/.gitignore_global na file sa pamamagitan ng mga nilalaman na ito:

*~
.*.swp
.DS_Store

…at pinatakbo ang git config --global core.excludesfile ~/.gitignore_global, ang Git ay hindi na kailanman mag-abala sa iyo tungkol sa mga file na iyon.

help.autocorrect

If you mistype a command, it shows you something like this: Kung nagkamali ka sa pag-type ng utos, ito ay magpapakita sa iyo kagaya nito:

$ git chekcout master
git: 'chekcout' is not a git command. See 'git --help'.

Did you mean this?
    checkout

Git helpfully tries to figure out what you meant, but it still refuses to do it. Sinusubukan na matulongan ka ng Git na malaman kung ano ang ibig mong sabihin, ngunit tumatanggi pa rin itong gawin ito. Kung iyong i-set ang help.autocorrect sa 1, ang Git ay talagang patatakbuhin ang utos na ito para sayo:

$ 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...

Tandaan na ang “0.1 seconds” na negosyo. Ang help.autocorrect ay talagang isang integer na kumakatawan sa ikasampu ng isang segundo Kaya kung itinakda mo ito sa 50, ang Git ay magbibigay sa iyo ng 5 segundo para baguhin ang iyong isip bago isinasagawa ang awtomatikong pagwasto sa utos.

Colors in Git

Lubos na sinusuportahan ng Git ang pagkulay sa output ng terminal, na kung saan ay lubos na nakakatulong sa paningin sa pag-parse ng output ng utos na mabilis at madali May iilang mga pagpipilian na maaaring makatulong sa iyo na itakda ang pagkukulay sa iyong kagustuhan.

color.ui

Ang Git ay awtomatikong nagkukulay sa karamihan ng output nito, ngunit may suwits na master kung hindi mo gusto ang pag-uugali na ito. Upang patayin ang lahat ng kulay na output ng Git, gawin ito:

$ git config --global color.ui false

Ang default na setting ay auto, kung saan magkukulay sa output kapag ito ay patungo ng deretso sa isang terminal, ngunit nililimitahan ang pagkontrol sa kulay ng mga code kapag ang output ay patungo sa isang tubo o isang file.

Maaari mo ring itakda ito sa always upang huwag pansinin ang pagkakaiba sa pagitan ng mga terminal at mga tubo. Bihira mong gusto ito; sa karamihan ng mga sitwasyon, kung nais mo ang makulay na mga code sa iyong na-redirect na output, maaari mong ipasa sa isang --color na flag sa Git na utos upang pilitin itong gamitin ang kulay ng mga code.

Ang default na setting ay halos palagi ang iyong kagustuhan.

color.*

Kung nais mong maging mas tiyak tungkol sa kung aling kulay ang mga utos at kung paano, ang Git ay nagbibigay ng pandiwang tukoy na mga setting sa pagkukulay. Ang bawat isa ay maaaring itakda sa true, false, o always:

color.branch
color.diff
color.interactive
color.status

Bilang karagdagan, ang bawat isa sa mga ito ay may mga subsetting na maaari mong gamitin upang magtakda ng mga tiyak na kulay para sa mga bahagi ng output, kung gusto mong palitan ang bawat kulay. Halimbawa, upang itakda ang meta ng impormasyon sa iyong diff ng output sa asul na foreground, itim na background, at naka-bold na teksto, maaari mong patakbuhin ang:

$ git config --global color.diff.meta "blue black bold"

Maaari mong itakda ang kulay sa alinman sa mga sumusunod na halaga: normal, black, red, green, yellow, blue, magenta, cyan, o white. Kung nais mo ang isang katangian tulad ng naka-bold sa nakaraang halimbawa, maaari kang pumili mula sa bold, dim, ul (underline), blink, at reverse (pagpapalit ng foreground at background).

Panlabas na Merge at mga Kasangkapan ng Diff

Kahit na ang Git ay may panloob na pagpapatupad ng diff, na kung saan ay ipinapakita namin sa aklat na ito, sa halip maaari kang magtakda ng isang panlabas na kasangkapan.

Maari kang mag-setup ng isang graphical na merge-conflict-resolution na kasangkapan sa halip na mano-manong pagresolba sa mga pagkasalungat.

Ipapakita namin ang pag-set-up ng Perforce Visual Merge na Kasangkapan (P4Merge) upang gawin ang iyong mga diff at pagsasama na mga panukala, dahil ito ay mahusay na grapikong kasangkapan at ito ay libre.

Kung gusto mong subukan ito, ang P4Merge ay gumagana sa lahat ng pangunahing mga plataporma, kaya dapat lang na magawa mo ito. Gagamit kami ng mga pangalan ng path sa mga halimbawa na gumagana sa Mac at Linux na mga sistema; para sa Windows, kailangan mong palitan ang /usr/local/bin sa isang nagpapatupad na path sa iyong kapaligiran ng paggawa.

Para simulan, i-download ang P4Merge galing sa Perforce. Susunod, mag-setup ka ng panlabas na pambalot na mga script upang patakbuhin ang iyong mga utos. Gagamitin natin ang path ng Mac para sa pagpapatupad; sa ibang mga sistema, ito ay kung saan ang iyong p4merge na binary naka-install. I-setup ang pambalot na script sa pagsasama na nakapangalan na extMerge na tumatawag sa iyong binary kasama na ang lahat ng mga nakalaan na argumento:

$ cat /usr/local/bin/extMerge
#!/bin/sh
/Applications/p4merge.app/Contents/MacOS/p4merge $*

Ang pambalot na diff ay magsusuri upang siguraduhin na pitong mga argumento ang naibigay at ang dalawa ay nagpapasa sa iyong pagsasama na script. Bilang default, ang Git ay nagpapasa ng mga sumusunod na argumento sa diff na programa:

path old-file old-hex old-mode new-file new-hex new-mode

Dahil ang gusto mo lamang ay ang old-file at new-file na mga argumento, gamitin mo ang script na pangbalot para ipasa ang bagay na iyong kailangan.

$ cat /usr/local/bin/extDiff
#!/bin/sh
[ $# -eq 7 ] && /usr/local/bin/extMerge "$2" "$5"

Kailangan ding siguraduhin na ang mga kasangkapan ay maipapatupad:

$ sudo chmod +x /usr/local/bin/extMerge
$ sudo chmod +x /usr/local/bin/extDiff

Sa ngayon maari mo ng i-setup ang iyong config na file upang magamit mo ang pasadyang pagsasamang resolusyon at diff na mga kasangkapan. Ito ang humahantong sa iilang mga pasadyang setting: merge.tool upang sabihin sa Git kung ano ang estratehiya na gagamitin, mergetool.<tool>.cmd upang tukuyin kung paano ipapatakbo ang utos, mergetool.<tool>.trustExitCode upang sabihin sa Git kung ang panglabas na code sa programa ay nagpapahiwatig na tagumpay ang pagsasamang resolusyon o hindi, at diff.external upang sabihin sa Git kung ano ang utos na patatakbuhin para sa mga diff. Kaya, maari kang magpatakbo alinman sa apat na config na mga utos

$ 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

o maari mong baguhin ang iyong ~/.gitconfig na file para idagdag ang mga linyang ito:

[merge]
  tool = extMerge
[mergetool "extMerge"]
  cmd = extMerge "$BASE" "$LOCAL" "$REMOTE" "$MERGED"
  trustExitCode = false
[diff]
  external = extDiff

Pagkatapos maitakda ang lahat ng ito, kung patatakbuhin mo ang diff na utos kagaya nito:

$ git diff 32d1776b1^ 32d1776b1

Sa halip na kunin ang diff na output sa linya ng utos, ang Git ay magpapatakbo ng P4Merge, na ang hitsura ay parang ganito:

P4Merge.
Figure 143. P4Merge.

Kung susubukan mong pagsamahin ang dalawang mga branch at sa dakong huli ay may mga pagkasalungat sa pagsasama, maari mong patakbuhin ang utos na git mergetool; ito ay magsisimula ng P4Merge para hayaan kang i-resolba ang mga pagkasalungat sa pamamagitan ng GUI na kasangkapan.

Ang magandang bagay tungkol sa setup ng pagbabalot na ito ay pwede mong baguhin ang iyong diff at ang mga kasangkapang pagsasama ng madali. Halimbawa, para baguhin ang iyong extDiff at extMerge na mga kasangkapan para patakbuhin ang KDiff3 na kasangkapan, ang gagawin mo lamang ay baguhin ang iyong extMerge` na file:

$ cat /usr/local/bin/extMerge
#!/bin/sh
/Applications/kdiff3.app/Contents/MacOS/kdiff3 $*

Ngayon, ang Git ay gagamit sa KDiff3 na kasangkapan para sa pagtingin ng diff at sa resolusyon ng pagsasama sa magkasalungat.

Ang Git ay may preset para gamitin ang iba’t-ibang mga kasangkapan ng resolusyong pagsasama na hindi na kailangang i-setup ang cmd na kompigurasyon. Para makita ang listahan ng mga kasangkapang sinuportahan, subukan ito:

$ git mergetool --tool-help
'git mergetool --tool=<tool>' pwedeng i-set sa isa sa mga sumusunod:
        emerge
        gvimdiff
        gvimdiff2
        opendiff
        p4merge
        vimdiff
        vimdiff2

Ang mga sumusunod na mga kasangkapan ay balido, ngunit sa kasalukuyan ay hindi pa magagamit:
        araxis
        bc3
        codecompare
        deltawalker
        diffmerge
        diffuse
        ecmerge
        kdiff3
        meld
        tkdiff
        tortoisemerge
        xxdiff

Iilan sa mga kasangkapang nakalista sa itaas ay gumagana lamang sa mga naka-window na
environment. Kung tumatakbo sa isang sesyong terminal lamang, sila ay mabibigo.

Kung ikaw ay hindi interesado sa paggamit ng KDiff3 sa diff ngunit gusto mo lamang gamitin ito para sa pagresolba sa pagsasama, at ang kdiff3 na utos ay nasa iyong path, pagkatapos ay maaari mo itong patakbuhin

$ git config --global merge.tool kdiff3

Kung patatakbuhin mo ito sa halip ng pag-setup ng extMerge at extDiff na mga file, ang Git ay gagamit ng KDiff3 para sa resolusyon ng pagsasama at ang normal na Git diff na kasangkapan para sa mga diff.

Pag-format at Whitespace

Pag-format at whitespace na mga isyu ay ilan sa mga mas nakakabigo at banayad na mga problema na maraming mga developers ay nakatagpo kapag nakikipagtulungan, lalo na ang cross-platform. Napakadali para sa mga patch o iba pang pinagtutulungang trabaho upang ipakilala ang mga banayad na mga pagbabago sa whitespace dahil ang mga editor ay tahimik na ipinakilala ang mga ito, at kung ang iyong mga file ay nagalaw ng isang Windows na sistema, ang kanilang mga katapusan ng linya ay maaaring napalitan. Ang Git ay may kaunting kompigurasyon na mga pagpipilian para tulungan ang mga isyung ito.

core.autocrlf

Kung ikaw ay nagpo-program sa Windows at nakipagtrabaho sa mga taong hindi gumagamit nito (o kabaligaran), malamang madadaanan mo ang patapos na linyang isyu sa isang punto. Ito ay dahil ginagamit ng Windows ang parehong titik na pag-carriage-return at isang titik ng linefeed para sa mga bagong linya sa mga file nito, samantalang ginagamit lamang ng Mac at Linux na sistema ang titik na linefeed. Ito ay isang banayad ngunit hindi kapani-paniwalang nakakainis na katotohanan ng cross-platform na trabaho; tahimik na pinapalitan ng maraming mga editor sa Windows ang mga umiiral na patapos na linyang LF sa CRLF, o ipasok ang parehong mga patapos na linyang titik kapag pinindot ng gumagamit ang enter na key.

Kaya ng Git na pangasiwaan ito sa pamamagitan ng pag-awtomatikong pagpalit sa CRLF ng pagtatapos ng linya sa LF kung iyong idagdag ang isang file sa index, at kabaliktaran kung ito ay mag checkout ng code sa iyong sistema ng file.

Maari mong paganahin ang pag-aandar na ito sa pamamagitan ng core.autocrlf na setting. Kung ikaw ay nasa Windows na makina, i-set ito sa true — papalitan nito ang LF na pagtatapos sa CRLF kung iyong i-check out ang code:

$ git config --global core.autocrlf true

Kung ikaw ay nasa Linux o Mac na sistema na gumagamit ng LF na pagtatapos sa linya, hindi muna kailangan ang Git na awtomatikong pagpalit sa kanila kung iyong i-check out ang mga file; subalit, kung ang file na may CRLF na pagtatapos ay aksidenting naipakilala, nararapat lang na gustohin mong ayusin ito ng Git. Maari mong sabihin sa Git na palitan ang CRLF sa LF sa pag-commit ngunit hindi ang kabaliktaran nito sa pagtakda ng core.autocrlf para sa pag-input:

$ git config --global core.autocrlf input

Ang setup na ito ay dapat nag-iiwan sa iyo ng CRLF na pagtatapos sa mga checkout sa Windows, ngunit ang LF na pagtatapos sa Mac at Linux na mga sistema at sa repositoryo.

Kung ikaw ay isang Windows na programmer na gumagawa ng Windows na proyekto lamang, maaari mong patayin ang pag-aandar na ito, pagtatala sa mga carriage return sa repositoryo sa pamamagitan ng pagtakda ng false sa halaga ng config:

$ git config --global core.autocrlf false

core.whitespace

Ang Git ay may preset para tuklasin at ayusin ang iilang whitespace na mga isyu. Ito ay tumitingin sa anim na pangunahing whitespace na mga isyu — tatlo ay pinagana sa pamamagitan ng default at maaaring patayin, at tatlo ay di-pinagana sa pamamagitan ng default ngunit pwedeng aktibahin.

Ang tatlong nakapatay sa pamamagitang ng default ay ang blank-at-eol, kung saan ay humahanap ng mga patlang sa pagtatapos ng linya; blank-at-eof, kung saan ay napapansin ang mga linyang blangko sa dulo ng file; at space-before-tab, kung saan ay naghahanap ng mga puwang bago ang mga tab sa simula ng linya.

Ang tatlong di-pinagana sa pamamagitan ng default ngunit pwedeng paganahin ay ang indent-with-non-tab, kung saan ay naghahanap ng mga linyang nagsisimula sa puwang imbes na sa mga tab (at kinokontrol sa pamamagitan ng tabwidth na opsyon); tab-in-indent, kung saan ay nagmamasid sa mga tab sa bahagi ng isang linya; at cr-at-eol, kung saan ay nagsasabi sa Git na OK ang carriage return sa dulo ng linya.

Maari mong sabihin sa Git kung saan sa mga ito ang gusto mong paganahin sa pamamagitan ng pagtakda sa core.whitespace sa mga halagang gusto mo maaaring on o off, nakahiwalay sa kuwit

Maari mong di-paganahin ang isang opsyun sa pamamagitan ng pag-prepend ng - sa harapan ng pangalan nito, o gamitin ang default na halaga sa pamamagitan ng pag-iwan nito sa pangkabuoang pagtakda sa string.

Halimbawa, kung gusto mo ang lahat maliban nalang sa space-before-tab ay i-set, maaari mong gawin ito (may trailing-space sa pagiging short-hand upang masakop ng pareho ang blank-at-eol at blank-at-eof):

$ git config --global core.whitespace \
    trailing-space,-space-before-tab,indent-with-non-tab,tab-in-indent,cr-at-eol

O maaari mong tukuyin ang bahagi ng pag-angkop sa sariling pangangailagan lamang:

$ git config --global core.whitespace \
    -space-before-tab,indent-with-non-tab,tab-in-indent,cr-at-eol

Matutuklasan ng Git ang mga isyung ito kapag pinatakbo mo ang git diff na utos at susubukan na kulayan ang mga ito upang maaari mong ayusin ang mga ito bago ka mag-commit.

It will also use these values to help you when you apply patches with git apply. Gagamitin din nito ang mga halagang ito upang makatulong sa iyo kapag nag-aplay ka ng mga patch sa pamamagitan ng git apply. Kapag nag-aaplay ka ng mga patch, maaari mong hilingin sa Git na balaan ka kung nag-aaplay ito ng mga patch sa mga tinukoy na mga isyu sa whitespace:

$ git apply --whitespace=warn <patch>

O maaari mong ipasubok sa Git na awtomatikong ayusin ang isyu bago ilapat ang patch:

$ git apply --whitespace=fix <patch>

Ang mga opsyun na ito ay inilapat din sa git rebase na utos. Kung ikaw ay nakagawa ng whitespace na mga isyu ngunit hindi mo na i-push na pasalungat sa agos, maaari kang magpatakbo ng git rebase --whitespace=fix para automatikong ayusin ng Git ang whitespace na mga isyu gaya ng muling pagsusulat sa mga patch.

Server Configuration

Hindi masyadong marami ang mga pagpipilian ng kompigurasyon na magagamit para sa server na bahagi sa Git, ngunit may kakaunting kawili-wili na gugustuhin mong tandaan.

receive.fsckObjects

Ang Git ay may kakayahang tiyakin na ang bawat bagay na natanggap sa panahon ng isang push ay tumutugma pa rin sa kanyang SHA-1 na checksum at mga puntos para sa balidong mga bagay. Gayunpaman, hindi ito ginagawa bilang default; ito ay medyo napakagastos na operasyon, at maaring pabagalin ang operasyon, lalo na sa mga malalaking repositoryo o mga push. Kung gusto mong suriin ng Git ang bagay na pare-pareho sa bawat push, maaari mong sapilitang gawin ito sa pamamagitan ng pagtakda sa receive.fsckObjects bilang true:

$ git config --system receive.fsckObjects true

Ngayon, ang Git ay susuri sa integridad ng iyong repositoryo bago ang bawat push ay tinanggap para siguraduhin na ang may sira (o malisiyoso) na mga kliyente ay hindi nagpapakilala ng masamang data.

receive.denyNonFastForwards

Kung gusto mong i-rebase ang mga commit na nai-push mo na at pagkatapos ay subukang i-push ulit, o kung hindi man ay subukang i-push ang commit sa isang remote na branch na walang laman ng commit kung saan ang kasalukuyang nakaturo sa remote na branch, ikaw ay tatanggihan.

Sa pangkalahatan ito ay magandang patakaran; ngunit sa kaso ng rebase, maaari mong malaman na alam mo kung ano ang iyong ginagawa at maaring sapilitang baguhin ang remote na branch na mayroong isang -f na flag sa iyong push na utos.

Para sabihin sa Git na tanggihan ang mga sapilitang pag-push, itakda ang receive.denyNonFastForwards:

$ git config --system receive.denyNonFastForwards true

Ang ibang paraan na maaari mong gawin ito ay sa pamamagitan ng pagtanggap sa server na bahagi na mga hook, kung saan ay tatalakayin natin maya-maya. Ang diskarteng iyon ay hinahayaan kang gawin ang mas kumplikadong mga bagay kagaya ng pagtanggi sa mga non-fast-forward hanggang sa tiyak na subset na mga manggagamit.

receive.denyDeletes

Isa sa mga ibang paraan na maaring gawin sa denyNonFastForwards na patakaran ay para sa manggagamit upang tanggalin ang branch at pagkatapos ay i-push ito pabalik na may bagong kaugnayan. To avoid this, set receive.denyDeletes to true: Para maiwasan ito, itakda ang receive.denyDeletes sa true:

$ git config --system receive.denyDeletes true

Tinanggihan nito ang anumang pagtanggal ng mga branch o mga tag — walang manggagamit ang makagawa nito. Para matanggal ang remote na mga branch, kailangan mong mano-manong tanggalin ang ref na mga file galing sa server. Mayroon ding mas kawili-wiling mga paraan para gawin ito sa isang pangmanggagamit na basihan sa pamamagitan ng mga ACL, na matutunan mo sa An Example Git-Enforced Policy.

scroll-to-top