Translation #12

book/08-customizing-git/sections/hooks.asc

@@ -110,20 +110,20 @@ Ang mga pre hook ay maaring magpapalabas ng di-sero sa kahit na anong oras para
 
 ===== `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.
+Ang unang script na patatakbuhin kapag naghawak ng push mula sa isang kliyente ay ang `pre-receive`.
+Ito ay kumukuha ng listahan sa mga sanggunian na pinu-push mula sa stdin; kung ito ay magpapalabas ng di-sero, wala sa kanila ang tatanggapin.
+Maaari mong gamitin ang hook na ito para gawin ang mga bagay kagaya ng siguraduhin na walang mga non-fast-forward sa mga na-update na mga sanggunian, o gagawin ang pagkontrol sa access sa lahat ng mga ref at mga file na binabago nila sa pamamagitan ng 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.
+Ang `update` na script ay masyadong kapareho sa `pre-receive` na script, maliban nalang na ito ay tumatakbo sa bawat branch na sinubakang i-push ng pusher para i-update.
+Kung ang pusher ay sinusubukang i-push ang maraming mga branch, ang `pre-receive` ay tumaktabo ng isang beses lamang, samantalang ang pag-update ay tumatakbo nang isang beses sa bawat branch na pinu-push nila.
+Sa halip na pagbabasa mula sa stdin, ang script na ito ay kukuha ng tatlong mga argumento: ang pangalan ng sanggunian (branch), ang SHA-1 na tinuturo ng sanggunian bago ang push, at ang SHA-1 na sinusubukang i-push ng manggagamit.
+Kung ang binagong script ay nagpapalabas ng di-sero, ang tinatanggihang sanggunian lamang; ang ibang sanggunian ay maaari paring baguhin.
 
 ===== `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.
+Ang `post-receive` na hook ay tatakbo pagkatapos ng buong proseso ay nakumpleto at maaaring gamitin para i-update ang ibang mga serbisyo o abisuhan ang mga gumagamit.
+Kinakailangan ang parehong stdin na data bilang `pre-receive` na hook.
+Kasama sa mga halimbawa ang pag-email sa isang listahan, abisuhan ang isang tuloy-tuloy na integration na server, o pag-update sa isang ticket-tracking na sistema - maaari mo ring i-parse ang mga mensahe ng commit upang makita kung ang anumang mga tiket ay kailangang mabuksan, mabago, o sarado
+Ang scipt na ito ay hindi kayang pahintuin ang proseso ng pag-push, ngunit ang kliyente ay hindi magdiskonekta hanggang sa makumpleto ito, kaya mag-ingat kung susubukan mong gumawa ng anumang bagay na maaaring tumagal ng mahabang panahon.

book/08-customizing-git/sections/policy.asc

@@ -1,25 +1,25 @@
 [[_an_example_git_enforced_policy]]
-=== An Example Git-Enforced Policy
+=== Isang Halibawa ng Git-Enforced na Patakaran
 
 (((policy example)))
-In this section, you'll use what you've learned to establish a Git workflow that checks for a custom commit message format, and allows only certain users to modify certain subdirectories in a project.
-You'll build client scripts that help the developer know if their push will be rejected and server scripts that actually enforce the policies.
+Sa seksyong ito, gagamitin mo ang natutunan para magtatag ng isang workflow ng Git na siyang magsusuri sa pinasadyang format ng mensahe ng commit, at magpapahintulot lamang sa ilang manggagamit para baguhin ang ilang mga subdirectory sa isang proyekto.
+Ikaw ay gagawa ng mga script na client na tutulong sa developer para malaman kung ang push nila ay hindi tatanggihan at mga script na server na aktwal na nagpatupad ng mga patakaran.
+Ang mga script na ipapakita namin ay isinulat sa Ruby; bahagyang dahil sa aming intelektwal na pagkawalang-galaw, ngunit dahil din sa madaling basahin ang Ruby, kahit na hindi mo kinakailangang isulat ito.
+Gayunpaman, kahit anong linggwahe ay gagana - ang lahat ng halimbawa na mga script na hook na ibinahagi sa Git ay nasa alinman sa Perl o Bash, kaya maari karing makakita ng maraming mga halimbawa ng mga hook sa mga linggwaheng iyon sa pamamagitan ng pagtingin sa mga halimbawa. 
 
-The scripts we'll show are written in Ruby; partly because of our intellectual inertia, but also because Ruby is easy to read, even if you can't necessarily write it.
-However, any language will work – all the sample hook scripts distributed with Git are in either Perl or Bash, so you can also see plenty of examples of hooks in those languages by looking at the samples.
+==== Hook na Server-Side
 
-==== Server-Side Hook
+Lahat ng server-side na trabaho ay pupunta sa `update` na file sa iyong `hooks` na direktoryo.
+Ang `update` na hook ay tumatakbo isang beses sa bawat branch na pinu-push at kumukuha ng tatlong mga argumento:
 
-All the server-side work will go into the `update` file in your `hooks` directory.
-The `update` hook runs once per branch being pushed and takes three arguments:
+* Ang pangalan ng sanggunian na pinu-push ito
+* Ang lumang rebisyon kung saan ang branch na iyon
+* Ang bagong rebisyon na pinu-push
 
-* The name of the reference being pushed to
-* The old revision where that branch was
-* The new revision being pushed
+Mayroon karing access sa manggagamit na gumawa ng pag-push kung ang push ay pinatakbo sa pamamagitang ng SSH.
+Kung pinapahintulutan mo ang lahat para kumonekta sa iisang manggagamit (like ``git'') sa pamamagitan ng pagpapatunay ng public-key, maaaring ibigay mo sa manggagamit na iyon ang shell wrapper na syang tumutukoy kung aling manggagamit ang nakakonekta batay sa public-key, at itakda ang environment na variable na naaayon.
 
-You also have access to the user doing the pushing if the push is being run over SSH.
-If you've allowed everyone to connect with a single user (like ``git'') via public-key authentication, you may have to give that user a shell wrapper that determines which user is connecting based on the public key, and set an environment variable accordingly.
-Here we'll assume the connecting user is in the `$USER` environment variable, so your update script begins by gathering all the information you need:
+Dito, ipagpalagay natin na ang gumagamit ng pagkonekta ay nasa variable ng environment na `$USER`, kaya ang script na binago ay magsisimula sa pamamagitan ng pagkuha sa lahat ng impormasyong kailangan mo:
 
 [source,ruby]
 ----
@@ -34,19 +34,18 @@ puts "Enforcing Policies..."
 puts "(#{$refname}) (#{$oldrev[0,6]}) (#{$newrev[0,6]})"
 ----
 
-Yes, those are global variables.
-Don't judge – it's easier to demonstrate this way.
+Oo, ang mga ito ay mga pandaigdigang variable.
+Huwag hatulan - mas madaling ipakita ito sa ganitong paraan
 
 [[_enforcing_commit_message_format]]
-===== Enforcing a Specific Commit-Message Format
+===== Pagpapatupad ng isang Tukoy na Format ng Commit-Message
 
-Your first challenge is to enforce that each commit message adheres to a particular format.
-Just to have a target, assume that each message has to include a string that looks like ``ref: 1234'' because you want each commit to link to a work item in your ticketing system.
-You must look at each commit being pushed up, see if that string is in the commit message, and, if the string is absent from any of the commits, exit non-zero so the push is rejected.
-
-You can get a list of the SHA-1 values of all the commits that are being pushed by taking the `$newrev` and `$oldrev` values and passing them to a Git plumbing command called `git rev-list`.
-This is basically the `git log` command, but by default it prints out only the SHA-1 values and no other information.
-So, to get a list of all the commit SHA-1s introduced between one commit SHA-1 and another, you can run something like this:
+Ang iyong unang hamon ay ang pagpapatupad sa bawat mensahe ng commit ay sumusunod sa isang partikular na format
+Para lang magkaroon ng isang target, ipagpalagay na ang bawat mensahe ay dapat na isama ang isang string na mukhang ``ref: 1234'' dahil gusto mo ang bawat commit ay naka-link sa aytem ng trabaho sa iyong sistema na pagtitiket.
+Dapat mong tingnan ang bawat commit bilang pag-push na paitaas, tingnan kung ang string na iyon ay ang mensahe ng commit, at, kung ang string ay wala sa mga commit, pagpapalabas sa di-sero para ang push ay tinanggihan. 
+Maari kang makakuha ng listahan ng SHA-1 na mga value sa lahat ng mga commit na nai-push sa pamamagitan ng pagkuha sa `$newrev` at `$oldrev` na mga value at ipasa sila sa Git na pag-plumb na utos na tinatawag na `git rev-list`.
+Sa pang karaniwan ito ay ang `git log` na utos, ngunit bilang default ito ay ini-print lamang ang mga halaga ng SHA-1 at wala ng ibang impormasyon.
+Kaya, upang makakuha ng isang listahan ng lahat ng commit na mga SHA-1 na ipinakilala sa pagitan ng isang commit na SHA-1 at sa isa pang tulad nito, maaari kang magpatakbu ng tulad nito:
 
 [source,console]
 ----
@@ -58,11 +57,11 @@ dfa04c9ef3d5197182f13fb5b9b1fb7717d2222a
 17716ec0f1ff5c77eff40b7fe912f9f6cfd0e475
 ----
 
-You can take that output, loop through each of those commit SHA-1s, grab the message for it, and test that message against a regular expression that looks for a pattern.
+Maaari mong kunin ang output na yan, i-loop sa bawat isa sa commit na mga SHA-1, kunin ang mensahe para dito, at subukan ang mensaheng iyon laban sa isang regular na expression na naghahanap ng isang pattern. 
 
-You have to figure out how to get the commit message from each of these commits to test.
-To get the raw commit data, you can use another plumbing command called `git cat-file`.
-We'll go over all these plumbing commands in detail in <<_git_internals#_git_internals>>; but for now, here's what that command gives you:
+Kailangan mong alamin kung paano makukuha ang mensahe ng commit galing sa bawat commit na ito para suriin.
+Para makuha ang raw na commit na data, maaari kang gumamit ng ibang pag-plumb na utos na tinatawag na `git cat-file`.
+Tatalakayin natin ang lahat ng pag-plumb na mga utos ng detalye sa <<_git_internals#_git_internals>>; ngunit para sa ngayon, ito ang mga ibibigay ng utos na ito sa iyo:
 
 [source,console]
 ----
@@ -72,21 +71,22 @@ parent 085bb3bcb608e1e8451d4b2432f8ecbe6306e7e7
 author Scott Chacon <schacon@gmail.com> 1205815931 -0700
 committer Scott Chacon <schacon@gmail.com> 1240030591 -0700
 
-changed the version number
+nabago ang numero ng bersyun
 ----
 
-A simple way to get the commit message from a commit when you have the SHA-1 value is to go to the first blank line and take everything after that.
-You can do so with the `sed` command on Unix systems:
+Isang simpleng paraan para makuha ang mensahe ng commit galing sa isang commit kung meron kang SHA-1 na halaga ay pagpunta sa isang blankong unang linya at kunin ang lahat pakatapon nito.
+Maaari mong gawing ito sa pamamagitan ng `sed` na utos sa mga sistemang Unix:
 
 [source,console]
 ----
 $ git cat-file commit ca82a6 | sed '1,/^$/d'
-changed the version number
+nabago ang numero ng bersyun
 ----
 
-You can use that incantation to grab the commit message from each commit that is trying to be pushed and exit if you see anything that doesn't match.
-To exit the script and reject the push, exit non-zero.
-The whole method looks like this:
+Maaari mong gamitin ang ganitong kasinungalingan upang makuha ang mensahe ng commit mula sa bawat commit na sinusubukang i-push at lalabas kung makakakita ng kahit na ano na hindi tugma.
+
+Pata ipalabas ang script at tanggihan ang push. ipalabas ang di-sero.
+Mukhang ganito ang buong paraan:
 
 [source,ruby]
 ----
@@ -106,14 +106,14 @@ end
 check_message_format
 ----
 
-Putting that in your `update` script will reject updates that contain commits that have messages that don't adhere to your rule.
+Paglalagay ng mga iyan sa iyong `update` na script ay tatanggihan ang mga pagbabago na naglalaman ng mga commit na may mga mensahe na hindi sumusunod sa iyong patakaran.
 
-===== Enforcing a User-Based ACL System
+===== Pagpapatupad sa isang Sistema na User-Based na ACL 
 
-Suppose you want to add a mechanism that uses an access control list (ACL) that specifies which users are allowed to push changes to which parts of your projects.
-Some people have full access, and others can only push changes to certain subdirectories or specific files.
-To enforce this, you'll write those rules to a file named `acl` that lives in your bare Git repository on the server.
-You'll have the `update` hook look at those rules, see what files are being introduced for all the commits being pushed, and determine whether the user doing the push has access to update all those files.
+Ipagpalagay natin na gusto mong magdagdag ng mga mekanismo na gumagamit ng pagkontrol sa access na listahan (ACL) na tinutukoy kung aling mga manggagamit ang pinapayagan na i-push ang mga pagbabago sa kung aling mga bahagi ng iyong mga proyekto.
+Iilang mga tao ay merong buong access, at iba ay maaari lamang mag-push ng mga pagbabago sa tiyak na subdirectories o tiyak na file.
+Para ipatupad ito, isusulat mo ang mga patakarang iyon sa isa file na may pangalang `acl` na nakatira sa iyong Git na repositoryo sa server.
+Kinakailangan mong ipakita sa `update` na hook ang mga panuntunang iyon, tingnan kung anong mga file ang ipinapakilala para sa lahat ng mga commit na pinu-push, at matukoy kung ang user na gumagawa ng push ay may access upang i-update ang lahat ng mga file na iyon.
 
 The first thing you'll do is write your ACL.
 Here you'll use a format very much like the CVS ACL mechanism: it uses a series of lines, where the first field is `avail` or `unavail`, the next field is a comma-delimited list of the users to which the rule applies, and the last field is the path to which the rule applies (blank meaning open access).