Translation #7: 1122 Words Translated

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

@@ -226,13 +226,13 @@ $ git config --global filter.indent.clean indent
 $ git config --global filter.indent.smudge cat
 ----
 
-In this case, when you commit files that match `*.c`, Git will run them through the indent program before it stages them and then run them through the `cat` program before it checks them back out onto disk.
-The `cat` program does essentially nothing: it spits out the same data that it comes in.
-This combination effectively filters all C source code files through `indent` before committing.
+Sa kasong ito, kapag nag-commit ka ng mga file na tumutugma sa `*.c`, ang Git ay tatakbo sa mga ito sa pamamagitan ng indent na  programa bago ito i-stage nila at pagkatapos patakbuhin ang mga ito sa programa ng `cat` bago suriin ang mga ito pabalik sa disk.
+Ang `cat` na programa ay talagang walang magawa: iniluwa palabas nito ang parehong data na pinasok dito.
+Ang kumbinasyon na ito ay epektibong sinasala ang lahat ng mga file ng source code sa C `indent` bago ito i-commit.
 
-Another interesting example gets `$Date$` keyword expansion, RCS style.
-To do this properly, you need a small script that takes a filename, figures out the last commit date for this project, and inserts the date into the file.
-Here is a small Ruby script that does that:
+Ang isa pang kawili-wiling halimbawa ay nakakuha ng pagpapalawak ng keyword na `$Date$`, estilo ng RCS.
+Upang gawin ito ng maayos, kailangan mo ng script na tumatagal sa filename, alamin ang huling petsa ng pag-commit para sa proyektong ito, at isingit ang petsa sa file.
+Narito ang Ruby script na ginagawa niyan:
 
 [source,ruby]
 ----
@@ -242,19 +242,17 @@ last_date = `git log --pretty=format:"%ad" -1`
 puts data.gsub('$Date$', '$Date: ' + last_date.to_s + '$')
 ----
 
-All the script does is get the latest commit date from the `git log` command, stick that into any `$Date$` strings it sees in stdin, and print the results – it should be simple to do in whatever language you're most comfortable in.
-You can name this file `expand_date` and put it in your path.
-Now, you need to set up a filter in Git (call it `dater`) and tell it to use your `expand_date` filter to smudge the files on checkout.
-You'll use a Perl expression to clean that up on commit:
+Ang lahat ng script ay makakakuha ng pinakabagong petsa ng pag-commit mula sa `git log` na utos, idikit sa anumang `$Date$` na mga string na nakikita sa stdin, at i-print ang mga resulta - ito ay dapat madaling gawin sa anumang language na ikaw ay pinaka-komportable. Maaari mong pangalanan ang file na ito `expand_date` at ilagay ito sa iyong path. Sa ngayon, kailangan mong mag-set up ng isang filter sa Git (tawagin mo `dater`) at sabihin ito upang gamitin ang iyong `expand_date` na filter sa smudge ng mga file sa checkout.
+Gagamitin mo ang Perl expression upang linisin ito sa commit:
 
 [source,console]
 ----
 $ git config filter.dater.smudge expand_date
 $ git config filter.dater.clean 'perl -pe "s/\\\$Date[^\\\$]*\\\$/\\\$Date\\\$/"'
 ----
 
-This Perl snippet strips out anything it sees in a `$Date$` string, to get back to where you started.
-Now that your filter is ready, you can test it by setting up a Git attribute for that file that engages the new filter and creating a file with your `$Date$` keyword:
+Ang Perl snippet ay nagtatanggal ng anumang nakikita nito sa `$Date$` string, upang makabalik kung saan ka nagsimula.
+Ngayon na handa na ang iyong filter, maaari mong subukan ito sa pamamagitan ng pagse-set up ng isang katangian ng Git para sa file na nakikipag-ugnayan sa bagong filter at paglikha ng isang file sa iyong `$Date$` na keyword
 
 [source,ini]
 ----
@@ -266,7 +264,7 @@ date*.txt filter=dater
 $ echo '# $Date$' > date_test.txt
 ----
 
-If you commit those changes and check out the file again, you see the keyword properly substituted:
+Kung nag-commit ka ng mga pagbabago at tingnan mo muli ang file, nakikita mo ang keyword na maayos na pinalitan: 
 
 [source,console]
 ----
@@ -278,36 +276,35 @@ $ cat date_test.txt
 # $Date: Tue Apr 21 07:26:52 2009 -0700$
 ----
 
-You can see how powerful this technique can be for customized applications.
-You have to be careful, though, because the `.gitattributes` file is committed and passed around with the project, but the driver (in this case, `dater`) isn't, so it won't work everywhere.
-When you design these filters, they should be able to fail gracefully and have the project still work properly.
+Makikita mo kung gaano kabisa ang pamamaraan na ito para sa mga na-customize na aplikasyon.
+Dapat kang mag-ingat, bagaman, dahil sa `.gitattributes` file ay nag-commit at naipasa sa proyekto, pero ang driver (sa kasong ito, `dater`) ay hindi, kaya hindi ito gagana saan man.
+Kapag dinisenyo mo ang mga filter na ito, dapat silang mabigo ng buong-husay at ayusin pa rin ang proyekto.
 
-==== Exporting Your Repository
+==== Pag-e-export ng Iyong Repository
 
 (((archiving)))
-Git attribute data also allows you to do some interesting things when exporting an archive of your project.
+Ang Git ng katangian ng data ay hinahayaan ka na gawin ang ilang mga kagiliw-giliw na bagay kapag nag-export ng isang archive ng iyong proyekto.
 
 ===== `export-ignore`
 
-You can tell Git not to export certain files or directories when generating an archive.
-If there is a subdirectory or file that you don't want to include in your archive file but that you do want checked into your project, you can determine those files via the `export-ignore` attribute.
+Maaari mong sabihin sa Git na huwag i-export ang ilang mga file o mga direktoryo kapag bumubuo ng isang archive.
+Kung mayroong isang subdirectory o file na hindi mo gustong isama sa iyong file ng archive ngunit nais mong i-tsek sa iyong proyekto, maaari mong matukoy ang mga file na iyon sa pamamagitan ng katangian ng `export-ignore`.
 
-For example, say you have some test files in a `test/` subdirectory, and it doesn't make sense to include them in the tarball export of your project.
-You can add the following line to your Git attributes file:
+Halimbawa, sabihin nating mayroon kang ilang mga test file sa `test/` subdirectory, at hindi ito makatwiran upang isama ang mga ito sa pag-export ng tarball ng iyong proyekto.
+Maaari mong idagdag ang sumusunod na linya sa iyong mga file na katangian ng Git:
 
 [source,ini]
 ----
 test/ export-ignore
 ----
 
-Now, when you run `git archive` to create a tarball of your project, that directory won't be included in the archive.
+Sa ngayon, kapag nagpatakbo ka ng `git archive` upang lumikha ng isang tarball ng iyong proyekto, ang direktoryo na iyon ay hindi isasama sa archive.
 
 ===== `export-subst`
 
-When exporting files for deployment you can apply `git log`'s formatting and keyword-expansion processing to selected portions of files marked with the
-`export-subst` attribute.
+Kapag nag-export ng mga file para sa pag-deploy maaari mong gamitin ang it `git log` sa pag-format at pagpapalawak ng keyword-expansion ng mga napiling bahagi ng mga file na minarkahan ng katangian ng `export-subst`.
 
-For instance, if you want to include a file named `LAST_COMMIT` in your project, and have metadata about the last commit automatically injected into it when `git archive` runs, you can for example set up your `.gitattributes` and `LAST_COMMIT` files like this:
+Halimbawa, kung gusto mong isama ang isang file na pinangalanang `LAST_COMMIT` sa iyong proyekto, at may metadata tungkol sa huling nag-commit awtomatikong na-inject ito kapag ang `git archive` ay tumatakbo, kaya mo tulad ng halimbawang i-set up ang iyong mga `.gitattributes` at `LAST_COMMIT` na mga file tulad nito:
 
 [source,ini]
 ----
@@ -321,7 +318,7 @@ $ git add LAST_COMMIT .gitattributes
 $ git commit -am 'adding LAST_COMMIT file for archives'
 ----
 
-When you run `git archive`, the contents of the archived file will look like this:
+Kapag nagpatakbo ka ng `git archive`, ang mga nilalaman ng naka-archive na file ay magiging ganito:
 
 [source,console]
 ----
@@ -330,7 +327,7 @@ $ cat ../deployment-testing/LAST_COMMIT
 Last commit date: Tue Apr 21 08:38:48 2009 -0700 by Scott Chacon
 ----
 
-The substitutions can include for example the commit message and any `git notes`, and `git log` can do simple word wrapping:
+Maaaring isama sa mga pamalit na halimbawa ang na i-commit na mensahe at anumang `git notes`, at `git log` ay maaaring gumawa ng simpleng word wrapping:
 
 [source,console]
 ----
@@ -349,31 +346,31 @@ Last commit: 312ccc8 by Jim Hill at Fri May 8 09:14:04 2015 -0700
          strips the surrounding `$Format:` and `$` markup from the output.
 ----
 
-The resulting archive is suitable for deployment work, but like any exported archive it isn't suitable for further development work.
+Ang resultang archive ay angkop para sa pag-deploy ng trabaho, ngunit tulad ng anumang na-export na archive na ito ay hindi angkop para sa karagdagang pag-unlad ng trabaho.
 
-==== Merge Strategies
+==== Pagsamahin ang mga Istratehiya
 
 (((merging, strategies)))
-You can also use Git attributes to tell Git to use different merge strategies for specific files in your project.
-One very useful option is to tell Git to not try to merge specific files when they have conflicts, but rather to use your side of the merge over someone else's.
+Maaari mo ring gamitin ang mga katangian ng Git upang sabihin sa Git na gumamit ng iba't ibang mga istratehiya sa pagsasama para sa mga partikular na file sa iyong proyekto.
+Ang isa sa kapaki-pakinabang na pagpipilian ay ang sabihin sa Git na huwag subukan na pagsamahin ang mga tiyak na file kapag mayroon silang mga salungatan, ngunit sa halip na gamitin ang iyong bahagi ng pagsasama sa ibang tao.
 
-This is helpful if a branch in your project has diverged or is specialized, but you want to be able to merge changes back in from it, and you want to ignore certain files.
-Say you have a database settings file called `database.xml` that is different in two branches, and you want to merge in your other branch without messing up the database file.
-You can set up an attribute like this:
+Ito ay kapaki-pakinabang kung ang isang branch sa iyong proyekto ay diverged o dalubhasa, ngunit nais mong ma-merge ang mga pagbabago sa likod mula dito, at nais mong huwag pansinin ang ilang mga file.
+Sabihing mayroon kang database settings file na tinatawag na `database.xml` na iba sa dalawang mga branch, at nais mong pagsamahin 
+Maaari kang mag-set up ng isang katangian tulad nito:
 
 [source,ini]
 ----
 database.xml merge=ours
 ----
 
-And then define a dummy `ours` merge strategy with:
+At pagkatapos ay tukuyin ang isang istratehiya ng dummy `ours` na may:
 
 [source,console]
 ----
 $ git config --global merge.ours.driver true
 ----
 
-If you merge in the other branch, instead of having merge conflicts with the `database.xml` file, you see something like this:
+Kung pinagsama mo ang ibang branch, sa halip na pagsamahin ang mga salungatan sa `database.xml` file, nakakita ka ng ganito:
 
 [source,console]
 ----
@@ -382,4 +379,4 @@ Auto-merging database.xml
 Merge made by recursive.
 ----
 
-In this case, `database.xml` stays at whatever version you originally had.
+Sa kasong ito, ang `database.xml` mananatili sa anumang bersyon sa dati. 

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

@@ -1,28 +1,29 @@
 [[_git_config]]
-=== Git Configuration
+=== Kompigurasyon ng Git
 
 (((git commands, config)))
-As you read briefly in <<_getting_started#_getting_started>>, you can specify Git configuration settings with the `git config` command.
-One of the first things you did was set up your name and email address:
+Habang binabasa mo agad sa <<_getting_started#_getting_started>>, matutukoy mo ang Kompigurasyon ng Git sa `git config` na utos.
+Isa sa mga unang bagay na dapat mong gawin ay i-set up ang iyong pangalan at email address:
 
 [source,console]
 ----
 $ git config --global user.name "John Doe"
 $ git config --global user.email johndoe@example.com
 ----
 
-Now you'll learn a few of the more interesting options that you can set in this manner to customize your Git usage.
+Ngayon matututunan mo ang ilan sa mga mas interesanteng mga pagpipilian na maaari mong itakda sa ganitong paraan upang i-customize ang iyong paggamit sa Git.
 
-First, a quick review: Git uses a series of configuration files to determine non-default behavior that you may want.
-The first place Git looks for these values is in the system-wide `/etc/gitconfig` file, which contains settings that are applied to every user on the system and all of their repositories.
-If you pass the option `--system` to `git config`, it reads and writes from this file specifically.
+Una, isang mabilis na pagsusuri: Gumagamit ang Git ng isang serye ng mga kompigurasyon na file upang matukoy ang non-default behavior na maaaring gusto mo.
+Ang unang titingnan ng Git para sa mga halagang ito ay ang buong sistema ng `/etc/gitconfig` na file, na naglalaman ng mga setting na inilapat sa bawat user sa sistema at lahat ng kanilang mga repositoryo.
+Kung dadaanan mo ang `--system` na opsyon sa `git config`, binabasa at sinulat nito mula sa partikular na file na ito.
 
-The next place Git looks is the `~/.gitconfig` (or `~/.config/git/config`) file, which is specific to each user.
-You can make Git read and write to this file by passing the `--global` option.
+Ang susunod na lugar na titingnan ng Git ay ang `~/.gitconfig` (o `~/.config/git/config`) na file, kung saan ay tiyak sa bawat gumagamit.
+Maaaring gawin ng Git na bumasa at sumulat sa file na ito sa pamamagitan ng pagpapasa ng `--global` na opsyon.
 
 Finally, Git looks for configuration values in the configuration file in the Git directory (`.git/config`) of whatever repository you're currently using.
-These values are specific to that single repository, and represent passing the `--local` option to `git config`.
-(If you don't specify which level you want to work with, this is the default.)
+Sa katapusan, hinahanap ng Git ang mga value ng konpigurasyon sa konpigurasyon na file sa direktoryo ng Git (`.git/config`) ng anumang repositoryo na kasalukuyang ginagamit mo.
+Ang mga halagang ito ay tiyak sa isang solong repositoryo, at kumakatawan sa pagpasa ng `--local` na opsyon hanggang `git config`.
+(Kung hindi mo tukuyin kung aling antas ang gusto mong magtrabaho, ito ang default.)
 
 Each of these ``levels'' (system, global, local) overwrites values in the previous level, so values in `.git/config` trump those in `/etc/gitconfig`, for instance.