Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

8th Transaltion 1114 Words #79

Merged
merged 6 commits into from
Feb 25, 2018
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
113 changes: 58 additions & 55 deletions book/08-customizing-git/sections/config.asc
Original file line number Diff line number Diff line change
Expand Up @@ -20,89 +20,89 @@ Kung dadaanan mo ang `--system` na opsyon sa `git config`, binabasa at sinulat n
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.
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.)
Panghuli, hinahanap ng Git ang mga halaga ng kompigurasyon sa file ng kompigurasyon sa direktoryo ng Git (`.git/config`) na anumang repositoryo na kasalukuyang ginagamit mo.

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.
Ang mga halagang ito ay tiyak sa isang solong repositoryo, at kumakatawan sa pagpasa ng `--local` na opsyon hanggang `git config`. (Kung hindi mo matukoy kung aling antas ang gusto mong magtrabaho, ito ang default.)

[NOTE]
Ang bawat isa sa mga ``antas'' (sistema, pandaigdigan, lokal) ay nagpapalit ng mga halaga sa nakaraang antas, halimbawa, kaya ang mga halaga sa `.git / config` trump sa mga nasa `/etc/gitconfig`.

[TANDAAN]
====
Git's configuration files are plain-text, so you can also set these values by manually editing the file and inserting the correct syntax.
It's generally easier to run the `git config` command, though.
Ang mga file ng kompigurasyon ng Git ay plain-text, kaya maaari mo ring itakda ang mga halagang ito sa pamamagitan ng pag-edit ng file nang manu-mano at pagpasok ng tamang syntax.
Bagaman, karaniwang mas madaling patakbuhin ang `git config` na utos.
====

==== Basic Client Configuration
==== Basic Client Kompigurasyon

The configuration options recognized by Git fall into two categories: client-side and server-side.
The majority of the options are client-side -- configuring your personal working preferences.
Many, _many_ configuration options are supported, but a large fraction of them are useful only in certain edge cases; we'll cover just the most common and useful options here.
If you want to see a list of all the options your version of Git recognizes, you can run
Ang mga pagpipilian sa kompigurasyon na kinikilala ng Git ay may dalawang kategorya: client-side at server-side.
Ang karamihan sa mga pagpipilian ay client-side -- i-kompigura ang mga personal na kagustuhan sa iyong ginagawa.
Karamihan, ang _maraming_ mga opsyon sa kompigurasyon ay sinusuportahan, ngunit ang isang malaking bahagi nito ay magagamit sa piling mga pagkakataon lamang; sinasaklaw lamang namin ang pinaka-karaniwan at kapaki-pakinabang na mga pagpipilian dito.
Kung nais mong makita ang listahan ng lahat ng mga opsyon na kinikilala ng iyong bersyon ng Git, maaari mong patakbuhin

[source,console]
----
$ man git-config
----

This command lists all the available options in quite a bit of detail.
You can also find this reference material at http://git-scm.com/docs/git-config.html[].
Ang lahat ng magagamit na mga opsyon sa mga listahan ng utos ay mas detalyado
Maaari mo ring mahanap ang materyal ng reperensya sa http://git-scm.com/docs/git-config.html[].

===== `core.editor`

((($EDITOR)))((($VISUAL, see $EDITOR)))
By default, Git uses whatever you've set as your default text editor via one of the shell environment variables `VISUAL` or `EDITOR`, or else falls back to the `vi` editor to create and edit your commit and tag messages.
To change that default to something else, you can use the `core.editor` setting:
Bilang default, ginagamit ng Git ang kahit anong itinakda mo bilang iyong default na editor ng teksto sa pamamagitan ng isa sa mga shell enviroment variable `VISUAL` o` EDITOR`, o kaya ay bumabalik sa editor ng `vi` upang lumikha at mag-edit ng iyong na i-commit at na tag na mga mensahe.
Upang baguhin ang default sa ibang bagay, maaari mong gamitin ang `core.editor` na setting:

[source,console]
----
$ git config --global core.editor emacs
----

Now, no matter what is set as your default shell editor, Git will fire up Emacs to edit messages.
Sa ngayon, hindi mahalaga kung ano ang itinakda bilang iyong default na editor ng shell, ang Git ay gagamitin ang Emacs upang mag-edit ng mga mensahe.

===== `commit.template`

(((commit templates)))
If you set this to the path of a file on your system, Git will use that file as the default initial message when you commit.
The value in creating a custom commit template is that you can use it to remind yourself (or others) of the proper format and style when creating a commit message.
Kung itinakda mo ito sa path ng file sa iyong sistema, ang Git ay gagamitin ang file bilang unang mensahe na default kapag ikaw ay nag-commit.
Ang halaga sa paglikha ng pasadyang commit template ay maaari itong gamitin upang paalalahanan ang iyong sarili (o ang iba) ng tamang pormat at istilo kapag lumilikha ng mensahe na i-commit.

For instance, consider a template file at `~/.gitmessage.txt` that looks like this:
Halimbawa, tignan ang template file sa `~/.Gitmessage.txt` na mukhang ganito:

[source,text]
----
Subject line (try to keep under 50 characters)
Linya ng paksa (subukan na panatilihin sa ilalim ng 50 character)

Multi-line description of commit,
feel free to be detailed.
Maraming linya sa paglalarawan ng commit,
Huwag mag-atubiling i-detalyado.

[Ticket: X]
----

Note how this commit template reminds the committer to keep the subject line short (for the sake of `git log --oneline` output), to add further detail under that, and to refer to an issue or bug tracker ticket number if one exists.

Pansinin kung paano nagpapaalala ang template na ito sa taga-commit upang panatilihing maikli ang linya ng paksa (para sa kapakanan ng `git log --oneline` na output), upang magdagdag ng karagdagang detalye sa ilalim nito, at upang sumangguni sa isang isyu o numero ng tiket ng tracker ng bug kung umiiral ito.
To tell Git to use it as the default message that appears in your editor when you run `git commit`, set the `commit.template` configuration value:

Upang sabihin sa Git na gamitin ito bilang default na mensahe na lumilitaw sa iyong editor kapag nagpatakbo ka ng `git commit`, i-set ang `commit.template` na halaga ng kompigurasyon:

[source,console]
----
$ git config --global commit.template ~/.gitmessage.txt
$ git commit
----

Then, your editor will open to something like this for your placeholder commit message when you commit:
Pagkatapos, magbubukas ang iyong editor sa isang bagay na tulad nito para sa iyong paglalagyan ng mensahe ng commit kapag nag-commit ka:

[source,text]
----
Subject line (try to keep under 60 characters)
Linya ng paksa (subukan na panatilihin sa ilalim ng 60 character)

Multi-line description of commit,
feel free to be detailed.
Maraming linya sa paglalarawan ng commit,
Huwag mag-atubiling i-detalyado.

[Ticket: X]
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Changes to be committed:
# Mangyaring ipasok ang mensahe ng commit para sa iyong mga pagbabago. Mga linyang nagsisimula
# sa '#' ay hindi papansinin, at ang isang walang laman na mensahe ay magbibigo sa commit.
# Sa master ng branch
# Mga pagbabago na i-commit:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: lib/test.rb
Expand All @@ -112,33 +112,33 @@ feel free to be detailed.
".git/COMMIT_EDITMSG" 14L, 297C
----

If your team has a commit-message policy, then putting a template for that policy on your system and configuring Git to use it by default can help increase the chance of that policy being followed regularly.
Kung ang iyong pangkat ay may patakaran sa mensahe ng commit, ang paglalagay ng isang template para sa patakarang iyon sa iyong sistema at pagkompigura sa Git na gamitin ito na default ay maaaring makatulong sa pagtaas ng pagkakataon ng patakarang iyon na regular na sinusunod.

===== `core.pager`

(((pager)))
This setting determines which pager is used when Git pages output such as `log` and `diff`.
You can set it to `more` or to your favorite pager (by default, it's `less`), or you can turn it off by setting it to a blank string:
Tinutukoy ng setting na ito kung alin sa pager ang ginamit kung ang mga pahina ng output ng Git ay `log` at `diff`.
Maaari mo itong itakda sa `more` o sa iyong paboritong pager (bilang default, ito ay `less`), o maaari mong isara ito sa pamamagitan ng pagtatakda nito sa isang blangko na string:

[source,console]
----
$ git config --global core.pager ''
----

If you run that, Git will page the entire output of all commands, no matter how long they are.
Kung patatakbuhin mo yan, ang Git ay magpe-page sa buong output sa lahat ng mga utos, gaano man kahaba sila.

===== `user.signingkey`

(((GPG)))
If you're making signed annotated tags (as discussed in <<_git_tools#_signing>>), setting your GPG signing key as a configuration setting makes things easier.
Set your key ID like so:
Kung gumagawa ka ng naka-sign na anotado na mga tag (tulad ng tinalakay sa <<_git_tools#_signing>>), pagtatakda sa iyong GPG na susi sa pag-sign bilang isang setting na kompigurasyon ay mas pinadali ang mga bagay.
Itakda ang iyong ID na susi katulad nito:

[source,console]
----
$ git config --global user.signingkey <gpg-key-id>
----

Now, you can sign tags without having to specify your key every time with the `git tag` command:
Ngayon, maaari kang mag-sign ng mga tag nang hindi na kailangang tukuyin ang iyong susi sa bawat oras sa paggamit ng `git tag` na utos:

[source,console]
----
Expand All @@ -148,14 +148,14 @@ $ git tag -s <tag-name>
===== `core.excludesfile`

(((excludes)))(((.gitignore)))
You can put patterns in your project's `.gitignore` file to have Git not see them as untracked files or try to stage them when you run `git add` on them, as discussed in <<_git_basics_chapter#_ignoring>>.
Maaari kang maglagay ng mga pattern sa iyong proyektong `.gitignore` na file upang hindi makita ang mga ito ng Git bilang mga untracked na file o subukang i-stage sila kung patatakbuhin mo ang `git add` sa kanila, tulad ng tinalakay sa <<_git_basics_chapter#_ignoring>>.

But sometimes you want to ignore certain files for all repositories that you work with.
If your computer is running macOS, you're probably familiar with `.DS_Store` files.
If your preferred editor is Emacs or Vim, you know about filenames that end with a `~` or `.swp`.
Ngunit kung minsan gusto mong huwag pansinin ang ilang mga file para sa lahat ng mga repositoryo na nagtatrabaho ka.
Kung ang iyong kompyuter ay tumatakbo sa macOS, marahil ikaw ay pamilyar sa `.DS_Store` na mga file.
Kung ang iyong ginustong editor ay Emacs or Vim, alam mo ang tungkol sa mga filename na nagtatapos sa isang `~` o `.swp`.

This setting lets you write a kind of global `.gitignore` file.
If you create a `~/.gitignore_global` file with these contents:
Ang setting na ito ay nagpapahintulot sa iyo na magsulat ng isang uri ng pandaigdigang `.gitignore` na file
Kung gumawa ka ng `~/.gitignore_global` na file sa pamamagitan ng mga nilalaman na ito:

[source,ini]
----
Expand All @@ -164,12 +164,13 @@ If you create a `~/.gitignore_global` file with these contents:
.DS_Store
----

and you run `git config --global core.excludesfile ~/.gitignore_global`, Git will never again bother you about those files.
at pinatakbo ang `git config --global core.excludesfile ~/.gitignore_global`, ang Git ay hindi na kailanman mag-abala sa iyo tungkol sa mga file na iyon.

===== `help.autocorrect`

(((autocorrect)))
If you mistype a command, it shows you something like this:
Kung nagkamali ka sa pag-type ng utos, ito ay magpapakita sa iyo kagaya nito:

[source,console]
----
Expand All @@ -181,7 +182,8 @@ Did you mean this?
----

Git helpfully tries to figure out what you meant, but it still refuses to do it.
If you set `help.autocorrect` to 1, Git will actually run this command for you:
Sinusubukan na matulongan ka ng Git na malaman kung ano ang ibig mong sabihin, ngunit tumatanggi pa rin itong gawin ito.
Kung iyong i-set ang `help.autocorrect` sa 1, ang Git ay talagang patatakbuhin ang utos na ito para sayo:

[source,console]
----
Expand All @@ -191,19 +193,20 @@ Continuing under the assumption that you meant 'checkout'
in 0.1 seconds automatically...
----

Note that ``0.1 seconds'' business. `help.autocorrect` is actually an integer which represents tenths of a second.
So if you set it to 50, Git will give you 5 seconds to change your mind before executing the autocorrected command.
Tandaan na ang ``0.1 seconds'' na negosyo. Ang `help.autocorrect` ay talagang isang integer na kumakatawan sa ikasampu ng isang segundo
Kaya kung itinakda mo ito sa 50, ang Git ay magbibigay sa iyo ng 5 segundo para baguhin ang iyong isip bago isinasagawa ang awtomatikong pagwasto sa utos.

==== Colors in Git

(((color)))
Git fully supports colored terminal output, which greatly aids in visually parsing command output quickly and easily.
A number of options can help you set the coloring to your preference.
Lubos na sinusuportahan ng Git ang pagkulay sa output ng terminal, na kung saan ay lubos na nakakatulong sa paningin sa pag-parse ng output ng utos na mabilis at madali
May iilang mga pagpipilian na maaaring makatulong sa iyo na itakda ang pagkukulay sa iyong kagustuhan.


===== `color.ui`

Git automatically colors most of its output, but there's a master switch if you don't like this behavior.
To turn off all Git's colored terminal output, do this:
Ang Git ay awtomatikong nagkukulay sa karamihan ng output nito, ngunit may suwits na master kung hindi mo gusto ang pag-uugali na ito.
Upang patayin ang lahat ng kulay na output ng Git, gawin ito:

[source,console]
----
Expand Down