Git 🌙
Chapters ▾ 2nd Edition

2.2 Mga Pangunahing Kaalaman sa Git - Pagtatala ng mga Pagbabago sa Repositoryo

Pagtatala ng mga Pagbabago sa Repositoryo

Sa puntong ito, dapat kang magkaroon ng tunay na repositoryo ng Git sa iyong lokal na makina, at isang checkout o gumaganang kopya sa lahat ng mga file nito na nasa harapan mo. Kadalasan, ikaw ay gustong mag-umpisa sa paggawa ng mga pababago at pag-commit sa mga snapshot ng mga pagbabago na iyon sa bawat oras na ang proyekto ay aabot sa estado na gusto mong itala.

Tandaan na sa bawat file na nasa iyong tinatrabahong direktoryo ay maaaring nasa isa sa dalawang estado: sinusubaybayan o hindi sinusubaybayan. Ang sinusubaybayan na mga file ay mga file na nasa huling snapshot; maaari silang maging hindi nabago, nabago, o itinanghal. Sa madaling salita, ang sinusubaybayan na mga file ay ang mga file na alam ng Git.

Ang hindi sinusubaybayan na mga file ay lahat ng iba pa — ang anumang mga file sa iyong tinatrabahong direktoryo na wala sa iyong huling snapshot at wala sa iyong staging na lugar. Sa una mong pag-clone ng repositoryo, lahat ng iyong mga file ay magiging sinusubaybayan at hindi nabago dahil sinuri ng Git ang mga ito at hindi mo na-edit ang kahit ano.

Habang ikaw ay nag-edit ng mga file, nakikita ni Git sila na bilang binago, dahil binago mo ang mga ito mula noong iyong huling commit. Habang ikaw ay nagtrabaho, pinili mong itinanghal ang mga nabagong mga file na ito at pagkatapos nag-commit sa lahat ng itinanghal na mga pagbabago, at ang siklo ay umuulit.

Ang lifecycle ng katayuan ng iyong mga file.
Figure 8. Ang lifecycle ng katayuan ng iyong mga file.

Pagsusuri ng Katuyuan ng Iyong mga File

Ang pangunahing kasangkapan na iyong ginamit para matukoy kung aling mga file ay sa aling estado ay ang git status na utos. Kung patakbuhin mo ang utos na ito na direkta pagkatapos ng clone, dapat mong makita ang isang bagay na tulad nito:

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean

Nangangahulugan ito na mayroon kang isang malinis na tinatrabahong direktoryo — sa ibang salita, waka sa iyong mga sinusubaybayan na mga file ang nabago. Hindi rin makikita ni Git ang anumang hindi sinusubaybayan na mga file, o sila ay malista dito. Sa wakas, ang utos ay nagsasabi sa iyo na kung saan na branch ikaw ay nandoon at nagsasabi sayo na hindi ito naiiba mula sa parehong branch sa server. Para sa ngayon, ang branch na yan ay laging “master”, kung saan ay default; hindi ka mag-alala dito. Pag-branch ng Git ay magpapatuloy sa mga branch at mga reperensiya sa detalye.

Sabihin natin na ikaw ay nagdagdag ng isang bagong file sa iyong proyekto, isang simpleng README na file. Kung ang file ay hindi umiiral noon, at ikaw ay nagpatakbo ng git status, Iyong makikita ang iyong hindi sinusubaybayan na file na tulad nito:

$ echo 'My Project' > README
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Untracked files:
  (use "git add <file>..." to include in what will be committed)

    README

nothing added to commit but untracked files present (use "git add" to track)

Makikita mo na ang iyong bagong README na file ay hindi nasubaybayan, dahil ito ay sa ilalim ng “Untracked files” papunta sa iyong katayuan ng output. Ang hindi sinusubaybayan ay talagang ang ibig sabihin nito na ang Git ay nakikita ang isang file na wala sa iyong nakaraang snapshot; Ang Git ay hindi magsisimula kasama ito sa iyong commit na mga snapshot hanggang ikaw ay nagsasabi na gawin ito. Ginagawa ito para ikaw ay hindi aksidenteng makapagsimula na kasama ang nabuong binary na mga file o ibang mga file na hindi mo gustong isama. Gusto mong magsimula na kasama ang README, kaya natin simulan ang pagsubaybay sa file.

Pagsubaybay sa Bagong mga File

Upang magsimula sa pagsubaybay ng isang bagong file , gagamitn mo ang utos na git add. Para umpisahan ang pagsubaybay sa README na file, maaari mo itong patakbuhin:

$ git add README

Kung pinapatakbo mo ang iyong katayuan ng utos uli, makikita mo na ang iyong README na file ay ngano nakasubaybay na at itatanghal upang ma-commit:

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   README

Maaari mong sabihin na ito ay itinanghal dahil ito ay sa ilalim ng “Changes to be committed” na heading. Kung ikaw ay mag-commit sa puntong ito, ang bersyon ng file sa oras na pinatakbo ang git add ay kung ano ang magiging makasaysayan na snapshot. Maaari mong isipin na kapag pinatakbo mo ang git init ng maaga, pagkatapos patakbuhin mo ang git add <files> — iyon ang pagsisimula ng pagsubaybay ng mga file sa iyong direktoryo. Ang git add na utos ay kumukuha ng isang pangalan ng path para sa alinman na file o direktoryo; kung ito ay isang direktoryo, ang utos ay nagdagdag ng lahat ng mga file sa direktoryo ng maraming beses.

Pagtanghal ng Nabagong mga File

Baguhin natin ang file na nasubaybayan na. Kung ikaw ay nagbago sa dating sinusubaybayan na file na tinatawag na CONTRIBUTING.md at pagkatapos pinatakbo mo ang iyong git status na utos uli, may makukuha kang isang bagay na tulad nito:

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   README

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

Ang CONTRIBUTING.md na file ay lumilitaw sa ilalim ng seksyon na nakapangalan na “Changes not staged for commit” — na ibig sabihin na ang isang file na sinusubaybayan ay nabago sa tinatrabahong direktoryo pero hindi pa naitanghal. Upang itanghal ito, patakbuhin mo ang git add na utos. git add ay isang multipurpose na utos — ginagamit mo ito upang magsimula sa pagsubaybay ng bagong mga file, upang itanghal ang mga file, at gumawa pa ng ibang mga bagay tulad ng pagmamarka ng merge-conflicted na mga file bilang nalutas. Maaaring makatulong ito na isipin ito na mas higit pa “magdagdag ng tumpak na nilalaman na ito sa susunod na commit” sa halip na “idagdag ang file na ito sa proyekto”. Patakbuhin natin ang git add ngayon upang itanghal ang CONTRIBUTING.md na file, at pagkatapos patakbuhin ang git status muli:

$ git add CONTRIBUTING.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   README
    modified:   CONTRIBUTING.md

Ang pareho na mga file ay naitanghal at mapupunta sa iyong susunod na commit. Sa puntong ito, ipagpalagay na naaalala mo na isang maliit na pagbago na gusto mong gawin sa CONTRIBUTING.md bago mo i-commit ito. Buksan mo ito uli at gawin ang pagbabago na iyon, at handa kana i-commit. Gayunpaman, patakbuhin natin ang git status ng isa pang pagkakataon:

$ vim CONTRIBUTING.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   README
    modified:   CONTRIBUTING.md

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

Ano ba ‘yan? Ngayon ang CONTRIBUTING.md ay nakalista bilang kapwa nakatanghal at hindi nakatanghal. Paano ito naging posible? Ito ay nagsasabi na ang Git ay nagtatanghal ng isang file na eksakto na kung kailan ikaw ay nagpatakbo sa git add na utos. Kung ikaw ay mag-commit ngayon, ang bersyon ng CONTRIBUTING.md tulad noong huling pinatakbo ang git add na utos ay kung paano ito pupunta sa commit, hindi ang bersyon ng file na tulad ng iyong tinatrabahong direktoryo kapag nagpatakbo ka ng git commit. Kung magbago ka ng isang file pagkatapos iyong pinatakbo ang git add, kailangan mong patakbuhin ang git add muli upang itanghal ang pinakabagong bersyon ng file:

$ git add CONTRIBUTING.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    new file:   README
    modified:   CONTRIBUTING.md

Maikling Katayuan

Habang ang git status na output ay medyo komprehensibo, ito din ay medyo sali-salita. Ang Git din ay merong isang maliit na status flag para ikaw ay makakita ng iyong mga binago sa isang mas compact na paraan. Kung patakbuhin mo ang git status -s o git status --short makakuha ka ng mas pinadali na output mula sa utos:

$ git status -s
 M README
MM Rakefile
A  lib/git.rb
M  lib/simplegit.rb
?? LICENSE.txt

Bagong mga file na hindi sinusubaybayan ay merong isang ?? sunod sa kanila, Ang mga bagong files na idinagdag sa pagtatanghal na lugar ay merong A, nabago na mga file ay merong M at iba pa. Mayroong dalawang column sa output - ang kaliwang-kamay na column ay nagpapaliwanag sa katayuan sa pagtatanghal na lugar at ang kanang-kamay na column ay nagpapaliwanag sa katayuan sa tinatrabahong tree. Kaya halimbawa sa output na iyon, ang README na file ay binago sa tinatrabahong direktoryo pero hindi pa natanghal, habang ang lib/simplegit.rb na file ay binago at natanghal. Ang Rakefile ay binago, natanghal at pagkatapos ay binago muli, kaya may mga pagbabago sa mga ito na parehong natanghal at hindi natanghal.

Pagbalewala ng mga File

Madalas, magkakaroon ka ng klase ng mga file na hindi mo gusto ang Git na awtomatikong magdagdag o kahit na magpakita sayo bilang hindi sinusubaybayan. Ang mga ito ay pangkalahatang awtomatikong nabuo na mga file tulad ng log na mga file o mga file na ginawa ng iyong tinayong sistema. Sa ganitong mga kaso, maaari kang gumawa ng mga palatandaan ng listahan ng file upang tumugma sa kanilang napangalan na .gitignore. Narito ang isang halimbawa sa .gitignore na file:

$ cat .gitignore
*.[oa]
*~

Ang unang linya ay nagsasabi ng Git na hindi pansinin ang anumang mga file na nagtatapos sa “.o” o “.a” — na object at archive na mga file na maaari ang produkto ng pag-build ng iyong code. Ang pangalawang linya ay nagsasabi ng Git na hindi pansinin ang lahat ng mga file na kaninong mga pangalan ay nagtatapos na may (~), na ginagamit ng maraming mga tekstong editor tulad ng Emacs upang markahan ang pansamantalang mga file. Maaari mo ring magsama ng log, tmp, o pid na direktoryo; awtomatikong nabuo na dokumentasyon; at iba pa. Pag-set ng isang .gitignore na file para sa iyong bagong repositoryo bago ikaw magsimula ay pangkalahatang isang magandang ideya kaya hindi ka aksidenteng mag-commit ng mga file na hindi mo gusto sa iyong Git na repositoryo.

Ang mga patakaran para sa mga palatandaan na maaari mong ilagay sa .gitignore na file ay ang mga sumusunod:

  • Mga blankong linya o mga linya na nagsisimula ng # ay hindi pinansin.

  • Ang standard glob na mga palatandaan na trabaho, at ilalapad ng maraming beses sa kabuuan na tinatrabahong tree.

  • Maaari mong simulan ang mga palatandaan na may pasulong na slash (/) upang iwasan ang maraming beses.

  • Maaari mong tapusin ang mga palatandaan na may pasulong na slash (/) upang tukuyin ang isang direktoryo.

  • Maaari mong kontrahin ang isang palatandaan sa pagsisimula nito ng may tandang padamdam (!).

Ang Glob na mga palatandaan ay katulad ng pinasimpleng regular na mga expression na ginagamitan ng mga shell. Isang asterisk (*) ay tumutugma sa zero o higit pa na mga karakter; [abc] ay tumugma sa anumang karakter sa loob ng mga bracket (sa kasong ito a, b, o c); isang tanong na marka (?) na tumutugma ng isang solo na karakter; at mga bracket na naglalakip ng mga karakter na pinaghiwalay ng isang hyphen ([0-9]) na tumutugma sa anumang karakter sa pagitan nila (sa kasong ito 0 hanggang 9). You can also use two asterisks to match nested directories; a/**/z would match a/z, a/b/z, a/b/c/z, and so on.

Narito ang isa pang halimbawa sa .gitignore na file:

# ignore all .a files
*.a

# but do track lib.a, even though you're ignoring .a files above
!lib.a

# only ignore the TODO file in the current directory, not subdir/TODO
/TODO

# ignore all files in the build/ directory
build/

# ignore doc/notes.txt, but not doc/server/arch.txt
doc/*.txt

# ignore all .pdf files in the doc/ directory and any of its subdirectories
doc/**/*.pdf
Tip

Ang GitHub ay nagpapanatili ng isang pantay na komprehensibong listahan ng mabuting .gitignore mga halimbawa ng file para sa mga dose-dosenang mga proyekto at mga wika sa https://github.com/github/gitignore kung gusto mo ng panimulang punto para sa iyong proyekto.

Sa simpleng kaso, ang repositoryo ay maaaring mayrong isang solong .gitignore na file sa kanyang root na direktoryo, na kung saan ay naaangkop ng maraming beses sa buong repositoryo. Gayunpaman, ito ay posible rin na magkaroon ng karagdagang .gitignore na mga file sa mga subdirectory. Ang mga patakaran sa mga nested na to ay .gitignore na mga file na nasa ilalim ng direktoryo kung saan matatagpuan ang mga ito. (Ang Linux kernel na pinagmulan na repositoryo ay may 206 na .gitignore na mga file.)

Ito ay lampas sa lawak sa librong ito para makuha ng mga detalye ng maramihang .gitignore na mga file; tingnan ang man gitignore para sa karagdagang mga detalye.

Pagtingin sa iyong itinanghal at hindi itinanghal na mga pagbabago

Kung ang git status na utos ay masyadong malabo para sa iyo — kung gusto mong malaman ang eksakto kung ano ang iyong binago, hindi lamang kung aling mga file — maaari mong gamitin ang git diff na utos. Talakayin natin ang git diff sa mas detalyado mamaya, ngunit malamang ikaw ay gagamit nito ng mas madalas para sagutin ang dalawang tanong na ito: Ano ang iyong nabago pero hindi pa natanghal? At ano ang iyong itinanghal na iyong i-commit pa? Kahit na ang git status ay sasagot sa mga tanong na iyon ng pangkalahatan sa pamamagitan ng paglista ng mga pangalan ng file, ang git diff ay nagpapakita sa iyo ng eksaktong mga linya na idinagdag at inalis — ang patch, na tulad nito.

Let’s say you edit and stage the README file again and then edit the CONTRIBUTING.md file without staging it. Kung pinatakbo mo ang iyong git status na utos, makikita mo ulit ang isang bagay na tulad nito:

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    modified:   README

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

Para tingnan ang iyong binago pero hindi pa naitanghal, i-type ang git diff na walang ibang mga argumento:

$ git diff
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 8ebb991..643e24f 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -65,7 +65,8 @@ branch directly, things can get messy.
 Please include a nice description of your changes when you submit your PR;
 if we have to read the whole diff to figure out why you're contributing
 in the first place, you're less likely to get feedback and have your change
-merged in.
+merged in. Also, split your changes into comprehensive chunks if your patch is
+longer than a dozen lines.

 If you are starting to work on a particular area, feel free to submit a PR
 that highlights your work in progress (and note in the PR title that it's

Ang utos na iyon ay inihahambing kung ano ang nasa iyong tinatrabahong direktoryo at kung ano ang nasa iyong itinanghal na lugar. Ang resulta ay nagsasabi sa iyo na ikaw ay nakagawa sa hindi mo pa naitanghal.

Kung gusto mong tingnan ang hindi mo pa naitanghal na mapupunta sa iyong susunod na commit, maaari mong gamitin ang git diff --staged. Ang utos na ito ay naghahambing sa iyong itinanghal na pagbabago sa iyong huling commit:

$ git diff --staged
diff --git a/README b/README
new file mode 100644
index 0000000..03902a1
--- /dev/null
+++ b/README
@@ -0,0 +1 @@
+My Project

Ito ay importanteng tandaan na ang git diff na sa sarili niya ay hindi nagpapakita ng lahat ng mga pagbabago na iyong nagawa sa huli mong commit — mga pagbabago lamang na hindi pa rin naitanghal. Kung iyong natanghal ang lahat ng iyong mga binago, ang git diff ay magbibigay sayo nang walang output.

Para sa isa pang halimbawa, kung ikaw ay nagtanghal sa CONTRIBUTING.md na file at pagkatapos ay na-edit ito, maaari mong gamitin ang git diff para tingnan ang mga pagbabago sa file na naitanghal at ang mga pagbabago na hindi pa naitanghal. If our environment looks like this:

$ git add CONTRIBUTING.md
$ echo '# test line' >> CONTRIBUTING.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    modified:   CONTRIBUTING.md

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

Ngayon ay maaari mo nang gamitin ang git diff para tingnan kung ano pa ang hindi naitanghal:

$ git diff
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 643e24f..87f08c8 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -119,3 +119,4 @@ at the
 ## Starter Projects

 See our [projects list](https://github.com/libgit2/libgit2/blob/development/PROJECTS.md).
+# test line

at ang git diff --cached para tingnan kung ano ang iyong naitanghal sa ngayon (--staged and --cached are synonyms):

$ git diff --cached
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 8ebb991..643e24f 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -65,7 +65,8 @@ branch directly, things can get messy.
 Please include a nice description of your changes when you submit your PR;
 if we have to read the whole diff to figure out why you're contributing
 in the first place, you're less likely to get feedback and have your change
-merged in.
+merged in. Also, split your changes into comprehensive chunks if your patch is
+longer than a dozen lines.

 If you are starting to work on a particular area, feel free to submit a PR
 that highlights your work in progress (and note in the PR title that it's
Example 1. Ang Git Diff ay isang Panlabas na Kasangkapan

Patuloy tayong gagamit ng git diff na utos sa iba’t ibang paraan sa buong pahina ng aklat. May isa pang paraan para tingnan ang mga diffs na ito na kung ikaw ay mas gusto ang isang graphical o panlabas na diff sa halip na pagtingin sa programa. Kung ikaw ay nagpatakbo ng git difftool sa halip na git diff, makikita mo ang anuman sa mga diffs na ito sa software na tulad ng emerge, vimdiff at marami pang iba (kabilang ang komersyal na mga produkto). Patakbuhin ang git difftool --tool-help para tingnan kung ano ang magagamit para sa iyong sistema.

Pag-commit ng iyong mga Binago

Ngayon na ang iyong itinanghal na lugar ay nai-setup ayon sa gusto mo, maaari mong i-commit ang iyong mga binago. Tandaan na anuman na hindi pa rin naitanghal — ang anumang mga file na iyong nalikha o nabago na hindi mo pa napatakbo ang git add mula nong iyong na-edit mo sila — hindi ka mapupunta sa pag-commit. Mananatili sila bilang nabago na mga file sa iyong disk. Sa kasong ito, sabihin natin na sa iyong huling beses na iyong pinatakbo ang git status, makikita mo lahat na iyong naitanghal, kaya handa kana i-commit ang iyong mga binago. Ang pinakasimpleng paraan para ma-commit ay mag-type ng git commit:

$ git commit

Ang paggawa nito ay naglulunsad ng iyong editor na napili. (Ito ay nag-set ng iyong shell ng EDITOR na environment variable — kadalasan ay vim o emacs, bagaman maaari mong i-configure ito kung ano ang gusto sa paggamit ng git config --global core.editor na utos tulad na iyong nakita sa Pagsisimula).

Ang editor ay nagpapakita ng mga sumusunod na teksto(halimbawa nito ay ang Vim na screen):

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Your branch is up-to-date with 'origin/master'.
#
# Changes to be committed:
#	new file:   README
#	modified:   CONTRIBUTING.md
#
~
~
~
".git/COMMIT_EDITMSG" 9L, 283C

Nakikita mo na ang default na mensahe ng commit ay naglalaman ng pinakabagong output sa git status na utos na nagkomento at isang walang laman na linya sa itaas. Maaari mong alisin ang mga komento na ito at i-type ang iyong mensahe ng commit, o maaari mong iwan ang mga ito doon upang makatulong sayo na tandaan ang iyong mga nai-commit. (Para sa isang mas tahasang paalala kung ano ang iyong nabago, maaari mong ipasa ang -v na opsyon sa git commit. Ang paggawa nito ay naglalagay din ng diff sa iyong nabago sa editor kaya maaari mong tingnan ang eksakto kung ano ang iyong nai-commit.) Kapag lumabas ka sa editor, Ang Git ay lumilikha ng iyong commit na may mensahe sa commit (sa mga komento at diff na nakuha).

Bilang alternatibo, maaari mong i-type ang iyong mensahe sa commit na nasa linya ng commit na utos sa pamamagitan ng pagtukoy nito pagkatapos ng isang -m na flag, tulad nito:

$ git commit -m "Story 182: Fix benchmarks for speed"
[master 463dc4f] Story 182: Fix benchmarks for speed
 2 files changed, 2 insertions(+)
 create mode 100644 README

Nalikha mo na ngayon ang iyong unang commit! Maaari mong makita ang commit ay nagbigay sa iyo ng ilang output tungkol sa sarili nito: kung anong branch ang iyong na-commit sa (master), kung ano ang SHA-1 checksum na commit na meron (463dc4f), kung gaano karami ang mga file na nabago, at istatistika tungkol sa mga linya na naidagdag at inalis sa commit.

Tandaan na ang commit ay nagtatala ng snapshot na iyong nai-setup sa iyong itinanghal na lugar. Anuman ang hindi mo naitanghal ay nakaupo pa rin doon na nabago; maaari mong gawin ang isa pang commit para madagdag sa iyong kasaysayan. Sa bawat oras na magsagawa ka ng commit, Nagtatala ka ng isang snapshot sa iyong proyekto na pwede mong ibalik sa o ihambing sa ibang pagkakataon.

Paglaktaw sa Staging Area

Kahit na ito ay maaaring nakamamanghang kapaki-pakinabang para sa paglikha ng mga commit na eksakto sa kung ano ang gusto mo sa kanila, ang staging na lawak ay paminsan-minsan isang kaunting kumplikado kaysa sa kailangan mo sa iyong workflow. Kung gusto mong laktawan ang staging na lawak, ang Git ay nagbibigay na isang simpleng daang tuwiran. Pagdaragdag ng -a na opsyon sa git commit na utos ay awtomatikong ginagawa ng Git ang pag-stage sa bawat file na nasubaybayan na bago ginagawa ang pag-commit, na hinahayaan ka na maglaktaw sa git add na parte:

$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   CONTRIBUTING.md

no changes added to commit (use "git add" and/or "git commit -a")
$ git commit -a -m 'added new benchmarks'
[master 83e38c7] added new benchmarks
 1 file changed, 5 insertions(+), 0 deletions(-)

Pansinin kung paano hindi ka kailangan na magpatakbo ng git add sa CONTRIBUTING.md na file sa kasong ito bago ka mag-commit. Iyan ay dahil ang -a na flag ay nagsasama ng lahat na nabago na mga file. Ito ay maginhawa, ngunit mag-ingat; kung minsan ang flag na ito ay magdudulot sa iyo ng pagsasama ng hindi inaasahang mga pagbabago.

Pag-alis ng mga File

Para mag-alis ng isang file mula sa Git, kailangan mong alisin ito mula sa iyong nasubaybayan na mga file (mas tama, tanggalin ito mula sa iyong staging na lawak) at pagkatapos i-commit. Ang git rm na utos ay ginagawa yan, at inaalis din ang file mula sa iyong tinatrabahong direktoryo para hindi mo makikita ito bilang hindi nasubaybayan na file sa susunod.

Kung alisin mo lamang ang file mula sa iyong tinatrabahong direktoryo, nagpapakita ito sa ilalim ng “Ang mga pagbabago ay hindi na-stage para i-commit” (yan ay, unstaged) lawak ng iyong git status na output:

$ rm PROJECTS.md
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        deleted:    PROJECTS.md

no changes added to commit (use "git add" and/or "git commit -a")

Pagkatapos, kung ikaw ay nagpatakbo ng git rm, ito ay magsi-stage sa pag-alis ng file:

$ git rm PROJECTS.md
rm 'PROJECTS.md'
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    deleted:    PROJECTS.md

Sa susunod na ikaw ay mag-commit, ang file ay mawawala at hindi na masubaybayan. Kung ikaw ay nakapagbago ng isang file at idinagdag na ito sa staging na lawak, dapat mong pilitin ang pagtanggal kasama ang -f na opsyon. Ito ay isang tampok na kaligtasan para maiwasan ang aksidenteng pag-alis ng datos na hindi pa naitala sa isang snapshot at hindi na ito makuha muli mula sa Git.

Isa pang kapaki-pakinabang na bagay na gusto mong gawin ay ang pagpanatili ng file sa iyong tinatrabahong tree ngunit alisin ito mula sa iyong staging na lawak. Sa ibang salita, baka gusto mong panatilihin ang file sa iyong hard drive ngunit walang Git na nagsubaybay nito ngayon. Ito ay partikular na magagamit kung ikaw ay nakalimot na magdagdag na kung ano sa iyong .gitignore na file at aksidenteng na-staged ito, tulad ng isang malaking log file o isang bugkos ng .a na naipon na mga file. Para gawin ito, gamitin ang --cached na opsyon:

$ git rm --cached README

Maaari mong ipasa ang mga file, mga direktoryo, at ang file-glob na mga palatandaan sa git rm na utos. Ibig sabihin na maaari kang gumawa ng mga bagay na tulad nito:

$ git rm log/\*.log

Tandaan ang backslash (\) na nasa harap sa *. Ito ay kinakailangan dahil ang Git ay gagawang kanyang sariling filename na pagpapalawak bilang karagdagan sa iyong filename expansion sa shell. This command removes all files that have the .log extension in the log/ directory. O, maaari kang gumawa ng isang bagay na tulad nito:

$ git rm \*~

Ang utos na ito ay nag-aalis ng lahat ng mga file na ang mga pangalan ay nagtatapos nang may ~.

Paggalaw ng mga File

Hindi tulad ng maraming iba pang mga sistema ng VCS, ang Git ay hindi malinaw na nagsubaybay ng pagkilos ng file. Kung ikaw ay nagpalit ng pangalan sa Git, walang metadata ay naka-imbak sa Git na nagsasabi na iyong pinalitan ang pangalan ng file. Gayunpaman, ang Git ay medyo matalino sa pag-uunawa na pagkatapos ng katotohanan — haharapin natin ang pag-detect sa paggalaw ng file isang saglit.

Kaya naman ito ay medyo nakakalito na ang Git ay may mv na utos. Kung gusto mong palitan ng pangalan ang isang file sa Git, maaari kang magpatakbo ng isang bagay na tulad nito:

$ git mv file_from file_to

at ito ay gumagana nang maayos. Sa katunayan, kung ikaw ay magpatakbo ng isang bagay na tulad nito at tumingin sa katayuan, iyong makikita na ang Git ay isinaalang-alang ang pagbago ng panglan ng file:

$ git mv README.md README
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

    renamed:    README.md -> README

Gayunpaman, ito ay katumbas sa pagpapatakbo ng isang bagay na tulad nito:

$ mv README.md README
$ git rm README.md
$ git add README

Ang Git ay nakatukoy na ito ay isang pagpapahiwatig ng pagpalit ng pangalan, kaya hindi mahalaga na kung ikaw ay nakapalit ng pangalan sa file sa ganun na paraan o kasama ang mv na utos. Ang tanging tunay na kaibahan ay ang git mv ay isang utos sa halip na tatlo — ito ay isang kaginhawaang function. Higit na mahalaga, maaari kang gumamit ng anumang kasangkapan na gusto mo upang magpalit na pangalan sa isang file, at maipasa sa add/rm mamaya, bago ka mag-commit.

scroll-to-top