-
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
1.1 Pagsisimula - Tungkol sa Bersyon Kontrol
Ang kabanatang ito ay tungkol sa pagsisimula sa paggamit ng Git. Magsisimula tayo sa pamamagitan ng pagpapaliwanag sa iilang kasaysayan sa pinagmulan ng mga taga-kontrol ng bersyon na mga kagamitan, pagkatapos ay pupunta tayo sa kung paano mapatakbo ang Git sa iyong sistema at sa wakas ay kung paano ito i-setup para magamit mo na. Sa bandang huli ng kabanatang ito dapat mauunawaan mo kung bakit nandito ang Git, bakit mo ito gagamitin at dapat ikaw ay handa na para gamitin ito.
Tungkol sa Bersyon Kontrol
Ano ang “bersyon kontrol”, at bakit mo dapat itong malaman? Ang bersyon kontrol ay isang sistema na nag-tatala sa mga pagbabago sa isang file o grupo ng mga files sa paglipas ng panahon para mabalikan mo ang partikular na mga bersyon mamaya. Para sa mga halimbawa sa aklat na ito, ikaw ay gagamit ng isang software na source code bilang mga files na nilagyan ng bersyon kontrol, sa totoo lang maaari mo itong gawin sa kahit anong tipo ng file sa isang kompyuter.
Kung ikaw ay isang graphic o web designer at gusto mong itago ang bawat bersyon ng isang larawan o layout (kung saan kadalasan ay gusto mo talaga), ang Version Control System (VCS) ay isang mainam na bagay para gagamitin. Ito ay nagbibigay-daan din para maibalik mo sa dating estado ang mga napiling mga files, i-revert ang buong proyekto pabalik sa nakaraang estado, ikumpara ang mga pagbabago paglipas ng panahon, tingnan kung sino ang nagbago ng mga files na maaaring nagdulot ng problema, sino ang nagdala ng problema at kailan at iba pa. Ang paggamit ng VCS din ay ibig sabihin na kung pumalpak ka sa mga bagay-bagay o nawalan ng mga files, madali ka lang maka-recover. Higit pa dito, makukuha mo ang lahat ng mga ito sa napakaliit na gawain lang.
Lokal na mga Sistema sa Bersyon Kontrol
Karamihan sa mga napiling bersyon-kontrol na pamamaraan ng mga tao ay ang pagkopya ng mga files sa ibang directory (marahil ay isang directory na naka-timestamp, kung sila ay bihasa). Ang pamamaraan na ito napakaraniwan dahil ito ay napakasimple lang, ngunit ito rin ay malamang magkakaroon ng mga kamalian. Madali lang makalimot kung saang directory ka naroon at aksidenteng magsulat sa mali na file o palitan ang mga files na hindi mo talaga ginusto.
Para malutas ang problemang ito, ang mga programmer noon pa ay gumawa ng lokal na mga VCS na mayroong isang simpleng database na nagsusubaybay sa lahat ng mga pagbabago sa mga files sa loob ng isang rebisyon kontrol.
Isa sa mga mas kilalang VCS na mga kagamitan ay isang sistema na tinatawag na RCS, kung saan ginagamit pa sa maraming mga kompyuter ngayon. Ang RCS ay gumagana sa pamamagitan ng paglagay ng mga grupo ng mga tagpi (ito ay, ang kaibahan ng mga files) sa isang espesyal na format sa disk; maaari nitong ilikha ulit kung ano ang dating laman ng mga file sa kahit anong oras sa pamamagitan ng pagdagdag sa lahat ng mga tagpi.
Mga Sentralisadong Bersyon Kontrol na mga Sistema
Ang susunod na pangunahing problema na nararanasan ng mga tao ay ang pangangailangang makipagtulungan sa ibang mga developer na nasa ibang mga sistema. Para malutas ang problemang ito, nagawa ang Sentralisadong Bersyon Kontrol na mga Sistema (CVCSs). Ang mga sistemang ito, gaya ng CVS, Subversion, at Perforce, ay mayroong isang server na naglalaman ng lahat ng mga nakabersyon na mga files, at mga iilang bilang ng mga kliyente na nagsusuri sa mga files mula sa sentrong lugar na ito. Sa maraming mga taon, ito ang naging pamatayan para sa bersyon kontrol.
Ang setup na ito ay nagbubunga ng napakaraming pakinabang, lalong lano kapag nasa lokal na mga VCS. Halimbawa, kahit na sino ay may nalalaman kung ano ang ginagawa ng kahit na sinong nasa proyekto. Ang mga tagapangasiwa ay mayroong pinong-grano na kontrol sa kung sino ang makakagawa nito, at ito ay sobra ka napakadaling pangasiwaan kung ihambing sa pag-susuri sa mga lokal na mga database ng bawat kliyente.
Gayunman, ang setup na ito ay mayroon ding mga seryosong negatibong epekto. Ang pinakahalata ay ang isang punto ng pagpalya na kinakatawan ng mga sentralisadong server. Kung ang server na iyan ay hindi magagamit sa loob ng isang oras, sa oras na iyan walang sinuman ang maaaring makipag-tulungan o mag-save ng mga nakabersyon na mga pagbabago sa kahit anong tinatrabaho nila. Kung ang hard disk ng sentrong database ay naging bulok, at walang itinago na mga tamang backup, mawawala sa iyo ang lahat — ang buong kasaysayan ng proyekto maliban na lang sa mga nag-iisang mga larawan na meron ang iba sa kanilang mga lokal na makina. Ang Lokal na VCS na mga sistema ay mayroon ding parehong problema — kung nasa isang lugar ang buong kasaysayan ng proyekto, maaari mong mawala ang lahat.
Nakabahagi na Bersyon Kontrol na mga Sistema
Ito ay kung saan dumating ang mga sistema ng Nakabahaging Bersyon Kontrol (DVCSs). Sa isang DVCS (gaya ng Git, Mercurial, Bazaar o Darcs), ang mga kliyente ay hindi lang basta mag-checkout sa pinakabagong kuha ng mga files; sa halip, tuluyan nilang kinopya ang buong repository, kalakip na ang buong kasaysayan nito. Kaya naman, kung may mamamatay na server, at ang mga sistemang ito ay nakikipag-tulungan sa pamamagitan ng server na iyon, ang kahit alin sa mga repository ng mga kliyente ay maaaring kopyahin papunta sa server para ma-restore ito. Bawat kopya ay talagang isang buong backup ng lahat ng mga datos.
Higit pa dito, karamihan sa mga sistemang ito ay mahusay sa pagkaroon ng iilang mga malayong mga repository na magagamit nila, kaya maaari kang makipag-tulungan sa iba’t ibang mga grupo ng tao sa iba’t ibang pamamaraan ng sabay-sabay sa isang parehong proyekto. Nagbibigay daan ito para maitakdo mo ang iilang tipo ng mga proseso na hindi posible sa isang sentralisadong mga sistema, gaya ng nakaherarkiyang na mga modelo.
