-
1. Pagsisimula
-
2. Mga Pangunahing Kaalaman sa Git
-
3. Pag-branch ng Git
-
4. Git sa Server
- 4.1 Ang Mga Protokol
- 4.2 Pagkuha ng Git sa isang Server
- 4.3 Ang paglikha ng iyong Pampublikong Susi ng SSH
- 4.4 Pag-Setup ng Server
- 4.5 Git Daemon
- 4.6 Smart HTTP
- 4.7 GitWeb
- 4.8 GitLab
- 4.9 Mga Opsyon ng Naka-host sa Third Party
- 4.10 Buod
-
5. Distributed Git
- 5.1 Distributed Workflows
- 5.2 Contributing to a Project
- 5.3 Maintaining a Project
- 5.4 Summary
-
6. GitHub
-
7. Mga Git na Kasangkapan
- 7.1 Pagpipili ng Rebisyon
- 7.2 Staging na Interactive
- 7.3 Pag-stash at Paglilinis
- 7.4 Pag-sign sa Iyong Trabaho
- 7.5 Paghahanap
- 7.6 Pagsulat muli ng Kasaysayan
- 7.7 Ang Reset Demystified
- 7.8 Advanced na Pag-merge
- 7.9 Ang Rerere
- 7.10 Pagdebug gamit ang Git
- 7.11 Mga Submodule
- 7.12 Pagbibigkis
- 7.13 Pagpapalit
- 7.14 Kredensyal na ImbakanCredential Storage
- 7.15 Buod
-
8. Pag-aangkop sa Sariling Pangangailagan ng Git
- 8.1 Kompigurasyon ng Git
- 8.2 Mga Katangian ng Git
- 8.3 Mga Hook ng Git
- 8.4 An Example Git-Enforced Policy
- 8.5 Buod
-
9. Ang Git at iba pang mga Sistema
- 9.1 Git bilang isang Kliyente
- 9.2 Paglilipat sa Git
- 9.3 Buod
-
10. Mga Panloob ng GIT
- 10.1 Plumbing and Porcelain
- 10.2 Git Objects
- 10.3 Git References
- 10.4 Packfiles
- 10.5 Ang Refspec
- 10.6 Transfer Protocols
- 10.7 Pagpapanatili At Pagbalik ng Datos
- 10.8 Mga Variable sa Kapaligiran
- 10.9 Buod
-
A1. Appendix A: Git in Other Environments
- A1.1 Grapikal Interfaces
- A1.2 Git in Visual Studio
- A1.3 Git sa Eclipse
- A1.4 Git in Bash
- A1.5 Git in Zsh
- A1.6 Git sa Powershell
- A1.7 Summary
-
A2. Appendix B: Pag-embed ng Git sa iyong Mga Aplikasyon
- A2.1 Command-line Git
- A2.2 Libgit2
- A2.3 JGit
-
A3. Appendix C: Mga Kautusan ng Git
- A3.1 Setup at Config
- A3.2 Pagkuha at Paglikha ng Mga Proyekto
- A3.3 Pangunahing Snapshotting
- A3.4 Branching at Merging
- A3.5 Pagbabahagi at Pagbabago ng mga Proyekto
- A3.6 Pagsisiyasat at Paghahambing
- A3.7 Debugging
- A3.8 Patching
- A3.9 Email
- A3.10 External Systems
- A3.11 Administration
- A3.12 Pagtutuberong mga Utos
8.3 Pag-aangkop sa Sariling Pangangailagan ng Git - Mga Hook ng Git
Mga Hook ng Git
Kagaya ng ibang maraming mga Sistema ng Pagkontrol sa Bersyon, ang Git ay may paraan para patakbuhin ang pasadyang mga script kung ang tiyak na importanteng mga aksyon ay nagyari. Mayroong dalawang grupo sa mga hook na ito: kliyente na panig at server na panig. Ang kliyenteng panig na mga hook ay gumagana sa pamamagitan ng mga operasyong kagaya ng pag-commit and pagsasama, habang ang server na panig na mga hook ay tumatakbo sa operasyon ng network kagaya ng pagtanggap sa na-push na mga commit. Maari mong gamitin ang mga hook na ito para sa lahat ng uri ng mga dahilan.
Pag-install ng Hook
Ang lahat ng mga hook ay nakalagay sa hooks
na subdirectory ng direktoryo ng Git.
Karamihan sa mga proyekto, ito ay .git/hooks
.
Kung ikaw ay nagpasimula ng bagong repositoryo sa pamamagitan ng git init
, ang Git ay naglalagay ng mga halimbawang script sa direktoryo ng mga hook, karamihan sa mga ito ay nakakatulong sa kanilang sarili; ngunit sila ay nagdokumento sa mga halagang pinapasok sa bawat script.
Lahat ng mga halimbawa ay sinusulat bilang shell na mga script, na may iilang Perl na binato papasok, ngunit kahit na anong maayos na pinangalanang gumaganang mga script ay tatakbo ng mabuti - maari mong isulat sila sa Ruby o Python o kahit na anong lengguwahe na pamilyar ka.
Kung gusto mong gamitin ang mga hook na nakabigkis na script, kailangan mong baguhin ang pangalan nila; ang lahat ng mga pangalan ng kanilang file ay nagtatapos na may .sample
.
Para paganahin ang script na hook, maglagay ng file sa hooks
na subdirectory sa iyong .git na direktoryo na nakapangalan ng maayos (na walang kahit na anong ekstensiyon) at ito ay maipapatupad.
Mula sa puntong iyon, ito ay dapat tinatawag.
Tatalakayin namin ang karamihan sa mga pangunahing hook na mga filename dito.
Mga Hook na Kliyenteng Panig
Mayroong maraming mga hook na kliyenteng panig. Ang seksyon na ito ay naghahati sa kanila bilang mga hook na committing-workflow, mga script na email-workflow, at iba pa.
Ito ay mahalagang tandaan na ang mga hook na kliyenteng panig ay hindi kinokopya kapag ikaw ay nag-clone ng isang repositoryo. Kung ang iyong ninanais ay ipapatupad ang isang patakaran sa pamamagitan ng mga script na ito, marahil gusto mong gawin ito sa bahagi ng server; tingnan ang halimbawa sa An Example Git-Enforced Policy.
Mga Hook na Committing-Workflow
Ang unang apat na mga hook ay may kinalaman sa prosesong pag-commit.
Ang pre-commit
na hook ay unang pinatakbo, bago paman mai-type mo ang mensahe ng commit.
Ito ay ginamit para suriin ang snapshot na malapit ng i-commit, para makita kung meron kang nakalimutan na isang bagay, para siguraduhin na tumatakbo ang mga pagsusulit, o siyasatin kung ano ang gusto mong suriin sa code.
Pagpapalabas sa di-sero mula sa hook na ito ay magbibigo sa commit, subalit maaari mong iiwasan ito sa pamamagitan ng git commit --no-verify
.
Maaari mong gawin ang mga bagay kagaya ng pagsuri sa estilo ng code (magpatakbo ng lint
o katumbas nito), magsusuri ng whitespace sa hulihan (ang default na hook ay eksaktong gumagawa nito), o suriin ang angkop na dokumentasyon sa mga bagong paraan.
Ang prepare-commit-msg
na hook ay pinatakbo bago ang editor ng mensahe ng commit ay napatakbo ngunit pagkatapos na nagawa ang default na mensahe.
Nagpapahintulot ito na ma-edit mo ang mensaheng default bago paman makita ng may-akda ng commit.
Ang hook na ito ay kumukuha ng iilang mga sadyansukat: ang path ng file na humahawak sa mensahe ng commit sa ngayon, ang uri ng commit, at ang commit na SHA-1 kung ito ay binagong commit.
Ang hook na ito ay hindi nakakatulong sa pangkalahatan para sa normal na commit; sa halip, ito ay maganda para sa mga commit kung saan ang default na mensahe ay awtomatikong nabuo, kagaya ng mga mensaheng naka-template na commit, mga merge na commit, na-squash na mga commit, at mga commit na nabago.
Maaari mong gamitin ito kasabay ang template na commit para naka-programa ang pagpasok sa impormasyon.
Ang commit-msg
na hook ay kumukuha ng isang sadyansukat, kung saan ito ulit ang path ng pansamantalang file na nilalaman ang mensahe ng commit na sinulat ng developer.
Kung ang script na ito ay lalabas sa di-sero, ang Git ay bibigo sa proseso ng commit, kaya maaari mong gamitin ito para patunayan ang estado ng iyong proyekto o mensahe ng commit bago pahintulotan makadaan ang isang commit.
Sa huling seksyon ng kabanatang ito, ipapakita namin ang paggamit sa hook para suriin kong ang iyong mensahe ng commit ay magkatugma sa kailangang pattern.
Pagkatapos makompleto ang kabuoan ng proseso sa commit, ang post-commit
na hook ay tatakbo.
Ito ay hindi kumukuha ng sadyansukat, ngunit maari kang madaling makakuha ng pinakahuling commit sa pamamagitan ng pagpapatakbo ng git log -1 HEAD
.
Sa pangkalahatan, ang script na ito ay ginamit para sa pag-abiso o katumbas nito.
Mga Hook ng Email Workflow
Maaari kang mag-setup ng tatlong kliyenteng panig na mga hook para sa isang email-based na workflow.
Silang lahat ay nananawagan sa pamamagitan ng git am
na utos, kaya kung ikaw ay hindi pa gumagamit sa utos na iyon sa iyong workflow, maaari mong laktawan ng ligtas ang susunod na seksyon.
Kung ikaw ay kumukuha ng mga patch sa pamamagitan ng email na hinanda ng git format-patch
, kung gayon iilan sa mga ito ay makakatulong sa iyo.
Ang unang hook na pinatakbo ay ang applypatch-msg
.
Ito ay kumukuha ng isang argumento: ang pangalan ng pansamantalang file na naglalaman ng iminungkahing mensahe.
Ang Git ay nagpapabigo sa patch kung ang script na ito ay nagpapalabas ng di-sero.
Maari mong gamitin ito para siguraduhin ang isang mensaheng commit ay maayos na nai-format, o para maging normal ang mensahe sa pamamagitan ng pagbago sa script sa kanyang lugar.
Ang susunod na patatakbuhing hook ay tatakbo kapag naglalagay ng mga patch sa pamamagitan ng git am
ay ang pre-applypatch
.
Ito ay medyo nakakalito, ito ay pinapatakbo pagktapos nailagay ang patch ngunit bago paman naisagawa ang pag-commit, kaya maari mong gamitin ito para siyasatin ang snapshot bago isagawa ang commit.
Maaari kang magpasulit o kung hindi man ay magsiyasat sa gumaganang tree sa pamamagitan ng script na ito.
Kung may isang bagay na nawawala o ang pagsusulit ay hindi naipasa, ang pagpapalabas sa di-sero ay magpapabigo ng git am
na script na hindi na i-commit ang patch.
Ang huling pinatakbong hook sa panahon ng git am
na operasyun ay post-applypatch
, kung saan ay tumatakbo pakatapos naisagawa ang commit.
Maari mong gamitin ito para abisuhan ang grupo o ang nag-akda sa patch na nai-pull mo na nagawa muna ito.
Hindi mo mapigilan ang proseso ng pag-patch gamit ang script na ito.
Ibang mga Hook ng Kliyente
Ang pre-rebase
na hook ay tumatakbo bago ka maka-rebase ng kahit na ano at maaaring magpahinto ng proseso sa pamamagitan ng pagpalabas sa di-sero.
Maari mong gamitin ang hook na ito para di-payagan ang pag-rebase ng kahit na anong mga commit na nai-push na.
Ang halimbawa ng pre-rebase
na hook na nainstall ng Git ay gumagawa nito, subalit ito ay nakagagawa ng iilang palagay na maaaring hindi parehas sa iyong workflow.
Ang post-rewrite
na hook ay pinatakbo sa pamamagitan ng mga utos na pumalit sa mga commit, kagaya ng git commit --amend
at git rebase
(bagaman hindi sa pamamagitan ng git filter-branch
)
Ang iisang argumento nito ay kung ano ang utos na nagpatakbo sa pagsulat ulit, at nakakatanggap ito ng mga muling pagsulat sa stdin
.
Ang hook na ito ay may maraming kaparehas na paggamit gaya ng post-checkout
at post-merge
na mga hook.
Pagkatapos mong magpatakbo ng isang matagumpay na git checkout
, ang post-checkout
na hook ay tatakbo; maari mong gamitin ito para i-setup ang iyong gumaganang direktoryo ng maaayos para sa environment ng iyong proyekto.
Ito ay maaring mangahulugan sa paglipat ng malaking binary na mga file na hindi mo gustong i-kontrol ang pinanggagalingan, awtomatikong paglikha ng dokumento, o isang bagay sa mga linyang iyon.
The post-merge
hook runs after a successful merge
command.
Ang post-merge
na hook ay tatakbo pagkatapos ng isang matagumpay na merge
na utos.
Maaari mong gamitin ito para ibalik ang data sa gumaganang tree na hindi masubaybayan ng Git, kagaya ng mga pahintulot na data.
Ang hook na ito ay maaaring magpapatunay din sa pagkakaroon ng mga file na panlabas na pagkontrol ng Git na maaaring gusto mong kopyahin kung ang gumaganang tree ay nagpapalit.
Ang pre-push
na hook ay tumatakbo sa panahon ng git push
, pagkatops nabago ang remote na mga ref ngunit bago paman na lipat ang kahit na anong bagay.
Ito ay nakakatanggap ng pangalan at lokasyon ng remote bilang mga sadyansukat, at isang listahan ng mga ibabagong mga ref sa pamamagitan ng stdin
.
Maari mong gamitin ito para patunayan ang mga pagbabago sa isang pangkat ng ref bago paman ang isang push ay maisagawa (ang isang di-sero na panlabas na code ay magpapabigo sa push).
Paminsa-minsan ang Git ay nagsasagawa ng koleksyon ng basura bilang bahagi ng kanyang normal na operasyun, sa pamamagitan ng pagtawag sa git gc --auto
.
Ang pre-auto-gc
na hook ay tinatawag bago ang koleksyon ng basura ay nagaganap, at maaaring gamitin para abisuhan ka na ito ay nangyayari, o para biguin ang koleksyun kung hindi pa tama ang oras.
Mga Hook na Bahagi ng Server
Bilang karagdagan ng mga hook ng kliyenteng panig, maari kang gumamit ng iilang mga importateng mga hook na bahagi ng server bilang isang tagapamahala ng sistema para ipatupad ang halos anumang uri ng patakaran para sa iyong proyekto Ang mga script na ito ay tumatakbo bago at pagkatapos ng mga push sa server. Ang mga pre hook ay maaring magpapalabas ng di-sero sa kahit na anong oras para di-tanggapin ang push pati na rin ang pag-print sa isang maling mensahe pabalik sa kliyente; maaari kang mag-setup ng patakaran sa pag-push na kumplikado hangga’t gusto mo.
pre-receive
The first script to run when handling a push from a client is pre-receive
.
It takes a list of references that are being pushed from stdin; if it exits non-zero, none of them are accepted.
You can use this hook to do things like make sure none of the updated references are non-fast-forwards, or to do access control for all the refs and files they’re modifying with the push.
update
The update
script is very similar to the pre-receive
script, except that it’s run once for each branch the pusher is trying to update.
If the pusher is trying to push to multiple branches, pre-receive
runs only once, whereas update runs once per branch they’re pushing to.
Instead of reading from stdin, this script takes three arguments: the name of the reference (branch), the SHA-1 that reference pointed to before the push, and the SHA-1 the user is trying to push.
If the update script exits non-zero, only that reference is rejected; other references can still be updated.
post-receive
The post-receive
hook runs after the entire process is completed and can be used to update other services or notify users.
It takes the same stdin data as the pre-receive
hook.
Examples include emailing a list, notifying a continuous integration server, or updating a ticket-tracking system – you can even parse the commit messages to see if any tickets need to be opened, modified, or closed.
This script can’t stop the push process, but the client doesn’t disconnect until it has completed, so be careful if you try to do anything that may take a long time.