1.3 Pagsisimula - Pangunahing Kaalaman sa Git

Ang pangunahing kaibahan ng Git sa kahit anong VCS (Subversion at kalakip ang mga kaibigan nito) ay ang pag-iisip ng Git tungkol sa mga datos nito. Kung iisipin, karamihan sa ibang mga sistema ay naglakip na mga impormasyon sa isang lista ng mga pagbabago ayon sa file. Ang ibang mga sistemang ito (CVS, Subversion, Perforce, Bazaar, at iba pa) ay nag-iisip sa mga impormasyon na kanilang inilakip bilang isang grupo ng mga file at ang mga pagbabagong nagawa sa bawat file sa paglipas ng panahon (ito ay karaniwang inilarawang bilang nakabase sa delta na bersyon kontrol).

Ang Git ay hindi nag-iisip o nagtago ng mga datos nito sa ganitong paraan. Sa halip, inisip ng Git ang mga datos nito bilang isang serye ng mga larawan sa isang pinaliit na sistema ng mga file. Sa Git, bawat beses na mag-commit ka, o mag-save ng estado ng iyong proyekto, ang Git ay para lang kumukuha ng larawan kung ano ang hitsura ng lahat ng iyong mga file sa oras na iyon at nagtago ng isang reperensya sa larawan na ito. Para mas mabisa, kung ang mga file ay hindi nababago, ang Git ay hindi ulit magtago ng file, isang link lang sa dating kaparehong file na ang itatago nito. Ang Git ay nag-iisip sa mga datos nito gaya ng isang daloy ng mga larawan.

Ito ay isang importanteng kaibahan ng Git at sa halos lahat ng ibang mga VCSs. Ito ang naging dahilin na nakapag-isip ang Git sa halos bawat aspeto ng bersyon kontrol na kadalasang kinopya ng karamihan sa ibang mga sistema mula sa nakaraang henerasyon. Ito ang dahilan kung bakit ang Git ay parang isang maliit na sistema ng mga file na may mga lubhang malalakas na mga kagamitan na nabuo sa taas nito, sa halip na isang simpleng VCS lang. Tutuklasin natin ang iilang sa mga benepisyo na makukuha mo sa pag-iisip ng iyong mga datos sa ganitong paraan kapag nadaanan na natin ang Git branching sa Pag-branch ng Git.

Karamihan sa mga operasyon sa Git ay nangangailangan lang ng mga lokal na mga files at mga kasangkapan para makapagpatakbo --- sa pangkalahatan, walang impormasyon ang kinakailangan mula sa ibang kompyuter na nasa iyong network. Kung ikaw ay nasanay na sa isang CVCS kung saan karamihan sa mga operasyon ay mayroong network latency na overhead, ang aspetong ito ng Git ay magpapaisip sa iyo na ang Git ay pinalanginan ng mga diyos ng bilis ng kapangyarihan na wala sa mundong ito. Dahil mayroon kang buong kasaysayan ng proyekto sa iyong lokal na disk, karamihan sa mga operasyon ay nagagawa agad.

Halimbawa, para maghanap ng kasasayan ng proyekto, hindi kinakailangan ng Git na pumunta pa sa server para makuha ang kasaysayan at para ipakita ito para sa iyo — simpleng binabasa lang nito mula sa iyong lokal na database. Ibig sabihin nito na makikita mo ang kasaysayan ng proyekto kaagad. Kung gusto mong makita ang mga pagbabago na dinagdag sa kasalukuyang bersyon ng isang file at ang file sa nakaraang buwan, ang Git ay maaring maghanap sa file sa nakaraang buwan at gumawa ng kalkulasyon sa lokal na kaibahan, sa halip na magtanong pa sa isang remote na server para gawin ito o kumuha pa ng lumang bersyon ng file mula sa malayong server para magawa ito sa lokal.

Ibig sabihin din nito na mayroong maliit lang na na mga bagay ang hindi mo magagawa kung ikaw ay offline o naka-off ang VPN. Kung ikaw ay sumakay ng eroplano o ng tren at gusto mong magtrabaho ng kaunti, maaari kang masayang mag-commit (sa iyong local na kopya, naalala mo?) hanggang sa magkakaroon ka ng network na koneksyon para makapag-upload. Kung nakauwi ka na at hindi mo mapatakbo ng mahusay ang iyong VPN client, makakatrabaho ka pa rin. Sa karamihan sa mga ibang sistema, ang paggagawa nito ay imposible o mahirap. Sa Perforce, halimbawa, wala kang masyadong magawa kung ikaw ay hindi konektado sa server; at sa Subversion at CVS, maaari kang mag-edit ng mga files, ngunit hindi mo maaaring i-commit ang iyong mga binago sa iyong database (dahil ang iyong database ay offline). Parang maliit lang ito na bagay, ngunit masusurpresa ka sa malaking pagbabago na magawa nito.

Lahat nang nasa Git ay naka check-sum bago ito itinago at pagkatapos ay binigyan na naman ng check-sum. Ibig sabihin nito, imposibleng mabago ang mga nilalaman ng kahit anong file o directory nang hindi malalaman ng Git. Ang gawaing na ito ay ginawa ng Git sa pinakamababang antas at isang mahalagang bahagi ng pilosopiya nito. Hindi ka maaaring mawalan ng impormasyon agad-agad o makaranas ng pagkabulok ng file nang hindi nalalaman ng Git.

Ang mekanismo na ginagamit ng Git para sa pag-checksum ay tinatawag na SHA-1 na hash.SHA-1) Ito ay isang 40-karakter na string na binubuo ng mga hexadecimal na mga karakter (0-9 at a-f) at nakuha ayon sa mga nilalaman ng isang file o directory na istraktura sa Git. Ang SHA-1 na hash ay parang ganito:

Makikita mo na ang mga halaga ng hash na ito ay nasa iba’t ibang lugar sa Git dahil ito ay palaging gumagamit sa mga ito. Sa katunayan, ang Git ay nagtago nito sa lahat ng nasa database nito hindi ayon sa pangalan ng file ngunit sa pamamagitan ng hash_value ng nilalaman nito.

Kung ikaw ay gumagawa ng mga aksyon sa Git, halos lahat ng mga ito ay nagdagdag lang ng mga datos sa Git na database. Mahirap na ipagawa sa sistema ang kahit na ano na hindi maaaring gawin nito o para ipabura ang mga datos sa kahit anong pamamaraan. Sa kahit anong VCS, maaaring mawala o magkagulo ang iyong mga binago na hindi mo pa nai-commit, ngunit pagkatapos mong mag-commit ng isang larawan sa Git, sobrang mahirap na itong mawala, lalo na kung parati kang nag-push sa iyong repositoryo sa ibang repositoryo.

Ito ang nagpapasaya sa Git dahil alam natin na maaari tayong mag-eksperimento ng hindi natatakot na lubhang makasira sa mga bagay-bagay. Para sa mas malalim pa na pag-uunawa kung paano ang Git nag-imbak ng mga datos nito at kung paano maka-recover ng mga datos na parang nawawala, tingnan ang Pag-Undo ng mga Bagay.

Bigyang pansin ito — ito ang pangunahing bagay na dapat mong tandaan tungkol sa Git kung gusto mong maging madali ang proseso ng iyong pag-aaral. Ang git ay may tatlong pangunahing estado kung saan maaaring malakip ang iyong mga file: naka-commit, binago, at naka-staged:

Ito ay nagdala sa atin sa tatlong pangunahing mga bahagi ng isang Git na proyekto: ang Git na direktoryo, ang working tree, at ang staging na lugar.

Ang Git na direktoryo ay kung saan ang Git nagtago ng metadata at ng object na database para sa iyong proyekto. Ito ang pinakaimportanteng bahagi ng Git, at ito ang nakopya kapag nagkopya ka ng repositoryo mula sa ibang kompyuter.

Ang working tree ay isang pag-checkout sa isang bersyon ng iyong proyekto. Ang mga files ay hinila mula sa isang naka-compress na database sa Git na direktoryo at nilagay sa disk para magamit o mabago mo.

Ang staging na lugar ay isang file, na karaniwang nakaloob sa iyong Git na direktoryo, na nag-imbak ng mga impormasyon tungkol sa ano ang masasama sa iyong susunod na commit. Ang teknikal na pangalan nito Git na wika ay “index”, ngunit ang pahayag na “staging na lugar” ay pede na rin.

Ang panguhahing proseso ng Git ay parang ganito:

Kung ang isang partikular na bersyon ng isang file ay nasa Git na direktoryo na, matuturing na itong commited. Kung ito ay binago at nadagdag na sa staging area, ito ay staged. At kung ito ay nabago simula noong na checkout ito ngunit hindi pa naka-stage, ito ay binago. Sa Mga Pangunahing Kaalaman sa Git, matutunan mo pa ang tungkol sa mga estadong ito at kung paano mo ito samantalahin o tuluyang laktawan ang naka-stage na parte.