Merge pull request #2 from severinolorillajr/master

ProGit 2nd Edition - Filipino Translation

Author: severinolorillajr

book/01-introduction/sections/about-version-control.asc

@@ -27,33 +27,33 @@ Ang RCS ay gumagana sa pamamagitan ng paglagay ng mga grupo ng mga tagpi (ito ay
 ==== Mga Sentralisadong Bersyon Kontrol na mga Sistema
 
 (((version control,centralized)))
-Ang sunod na pangunahing problema na nararanasan ng mga tao ay ang pangangailangan na makipagtulungan sa ibang mga developer na nasa ibang mga sistema.
-Para malutas ang problemang ito, nagawa ang Centralized Version Control na mga Sistema (CVCSs).
+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. (((CVS)))(((Subversion)))(((Perforce)))
-Sa maraming mga taon, ito ang naging pamatayan para sa version control.
+Sa maraming mga taon, ito ang naging pamatayan para sa bersyon kontrol.
 
 .Centralized na version control.
-image::images/centralized.png[Centralized version control diagram]
+image::images/centralized.png[Diagram sa Sentralisadong bersyon kontrol]
 
-Ang setup na ito ay nagbubunga ng napakaraming pakinabang, lalong lano kapag lokal na mga VCS.
+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 fine-grained 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 sa bawat kliyente.
+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 single point of failure 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-collaborate o mag-save ng mga nakabersyon na mga pagbabago sa kahit anong tinatrabaho nila.
-Kung ang hard disk ng sentrong database ay naging corrupted, at walang itinago na mga tamang backup, mawawala sa iyo ang lahat -- ang buong kasaysayan ng proyekso maliban na lang sa mga single snapshops na meron ang iba sa kanilang mga lokal na makina.
+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.
 
-==== Distributed na Version Control na mga Sistema
+==== Nakabahagi na Bersyon Kontrol na mga Sistema
 
 (((version control,distributed)))
-Ito ay kung saan dumating ang Distributed Version Control Systems (DVCSs).
-Sa isang DVCS (gaya ng Git, Mercurial, Bazaar o Darcs), ang mga kliyente ay hindi lang basta mag-checkout sa pinakabagong snapshot ng mga files; sa halip, tuluyan nilang kinopya ang repository, kalakip na ang buong kasaysayan nito. Kaya naman, kung may mamamatay na server, at ang mga sistemang ito ay nakikipag-collaborate sa pamamagitan ng server na iyo, ang kahit alin sa mga repository ng mga kliyente ay maaaring kopyahin papunta sa server para ma-restore ito.
+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.
 
 .Distributed na version control.
-image::images/distributed.png[Distributed version control diagram]
+image::images/distributed.png[Diagram ng nakabahaging Bersyon Kontrol]
 
-Higit pa dito, karamihan sa mga sistemang ito ay mahusay sa pagkaroon ng iilang mga remote repository na magagamit nila, kaya maaari kang makipag-collaborate sa iba't ibang mga grupo ng tao sa iba't ibang pamamaraan ng sabay-sabay sa isang parehong proyekto.
-Nagbibigay daan ito para ma-setup mo ang iilang tipo ng mga workflow na hindi posible sa isang sentralisadong mga sistema, gaya ng hierarchical na mga modelo.
+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.

book/01-introduction/sections/basics.asc

@@ -1,55 +1,55 @@
 === Pangunahing Kaalaman sa Git
 
-Kaya, ano ang Git sa madaling salita?
-Ito ay isang importanteng bahagi na kailangang makuha mo, dahil kung nauunawaan mo kung ano ang Git at ang mga pangunahing kaalaman kung paano ito gumagana, mas madali para sa iyo ang epektibong paggamit ng Git. Habang natututo ka ng Git, subukang linisin ang iyong isipan tungkol sa mga bagay na nalalaman mo tungkol sa ibang VCSs, gaya ng CVS, Subversion o Perforce -- sa ganitong paraan makakatulong itong maiwasan ang maliliit na kalituhan sa paggamit ng kagamitan.
-Kahit na ang user interface ng Git ay kapareho lang sa ibang VCSs, ang Git ay nag-store at nag-iisip tungkol sa mga impormasyon sa isang kakaibang pamamaraan, at ang pag-uunawa sa mga kaibahang ito ay makakatulong sa iyo na maiwaasan ang ang pagkalito bahang gumagamit nito.(((Subversion)))(((Perforce)))
+Kaya, ano ang Git sa madaliang salita?
+Ito ay isang importanteng bahagi na kailangan mong makuha, dahil kung nauunawaan mo kung ano ang Git at ang mga pangunahing kaalaman kung paano ito gumagana, mas madali na para sa iyo ang epektibong paggamit ng Git. Habang natututo ka ng Git, subukang linisin ang iyong isipan tungkol sa mga bagay na nalalaman mo tungkol sa ibang VCSs, gaya ng CVS, Subversion o Perforce -- sa ganitong paraan makakatulong itong maiwasan ang maliliit na kalituhan sa paggamit ng kagamitang ito.
+Kahit na ang user interface ng Git ay kapareho lang sa ibang VCSs, ang Git ay nag-store at nag-iisip tungkol sa mga impormasyon sa isang kakaibang pamamaraan, at ang pag-uunawa sa mga kaibahang ito ay makakatulong sa iyo na maiwaasan ang ang pagkalito habang gumagamit nito.(((Subversion)))(((Perforce)))
 
-==== Mga Snapshot, Hindi Mga Kaibahan
+==== Mga Kuha, Hindi Mga Kaibahan
 
 Ang pangunahing kaibahan ng Git sa kahit anong VCS (Subversion at kalakip ang mga kaabigan nito) ay ang pag-iisip ng Git tungkol sa mga datos nito.
-Kung iisipin, karamihan sa ibang mga sistema ay nag-store 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 ini-store bilang isang grupo ng mga file at ang mga pagbabagong nagawa sa bawat file sa paglibas ng panahon (ito ay karaniwang inilarawang bilang _delta-based_ na version control).
+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 pag-store na mga datos bilang pagbabago sa base na bersyon ng bawat file.
-image::images/deltas.png[Ang pag-store na mga datos bilang pagbabago sa base na bersyon ng bawat file.]
+.Ang pag-tago na mga datos bilang pagbabago sa pangunahing bersyon ng bawat file.
+image::images/deltas.png[Ang pag-store na mga datos bilang pagbabago sa pangunahing bersyon ng bawat file.]
 
-Ang Git ay hindi nag-iisip o nag-store na mga datos nito sa ganitong paraan.
-Sa halip, inisip ng Git ang mga datos nito bilang isang serye ng mga snapshot sa isang miniature na filesystem.
-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 nag-store ng isang reference sa snapshot na ito.
-Para mas mabisa, kung ang mga file ay hindi naabago, ang Git ay hindi ulit mag-store ng file, isang link lang sa dating kaparehong file na nai-store na nito.
-Ang Git ay nag-iisip sa mga datos nito gaya ng isang *daloy ng mga snapshots*.
+Ang Git ay hindi nag-iisip o nagtago na 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 nai-store nito.
+Ang Git ay nag-iisip sa mga datos nito gaya ng isang *daloy ng mga larawan*.
 
-.Ang pag-store ng mga datos bilang mga snapshot sa paglipas ng panahon.
-image::images/snapshots.png[Ang Git ay nag-store ng mga datos bilang mga snapshot sa paglipas ng panahon.]
+.Ang pag-store ng mga datos bilang mga larawan sa paglipas ng panahon.
+image::images/snapshots.png[Ang Git ay nag-store ng mga datos bilang mga larawan sa paglipas ng panahon.]
 
 Ito ay isang importanteng kaibahan ng Git at sa halos lahat ng ibang mga VCSs.
-Nagpapa-reconsider ito sa Git sa halos bawat aspeto ng version control na kadalasang kinopya ng karamihan sa ibang mga sistema mula sa nakaraang henerasyon.
-Ito ang dahilan kung bakit ang Git ay parang isang mini filesystem na may mga lubhang malalakas na mga kagamitan na nabuo sa taas nito, sa halip na isang simpleng VCS lang.
+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 <<_git_branching#_git_branching>>.
 
-==== Halos Bawat Operasyon ay Lokal
+==== Halos Bawat Operasyon ay Nasa Lokal
 
-Karamihan sa mga operasyon sa Git ay nangangailangan lang ng mga lokal na mga files at mga resources para makapag-operate --- 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 na 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 local disk, karamihan sa mga operasyon ay nagagawa agad.
+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 mag-browse 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 ito mula sa iyong local na database.
+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 remote server para magawa ito sa lokal.
+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 connection para makapag-upload.
+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 masurpresa ka sa malaking pagbabago na magawa nito.
+Parang maliit lang ito na bagay, ngunit masusurpresa ka sa malaking pagbabago na magawa nito.
 
 ==== Ang Git ay Mayroong Integridad
 
-Lahat nang nasa Git ay naka check-sum bago ito i-store at pagkatapos ay ini-refer naman ng checksum na iyon.
+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 functionality na ito ay ginawa sa Git sa pinakamababang antas at isang mahalagang bahagi ng pilosopiya nito.
-Hindi ka maaaring mawalan ng imprrmasyon agad-agad o makaranas ng file corruption nang hindi nadedetect 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.
@@ -60,8 +60,8 @@ Ang SHA-1 na hash ay parang ganito:
 24b9da6552252987aa493b52f8696cd6d3b00373
 ----
 
-Makikita mo na ang mga hash values na ito ay nasa iba't ibang lugar sa Git dahil ito ay palaging gumagamit sa mga ito.
-Sa katunayan, ang Git ay nagstore sa lahat ng nasa database nito hindi ayon sa file name ngunit sa pamamagitan ng hash_value ng nilalaman nito.
+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.
 
 ==== Ang Git ay Nagdadagdag lang ng mga Datos