git add at git commit: tamang paraan ng pag-save ng pagbabago

Walang "save" button ang Git. Dalawang hakbang ang pag-record ng pagbabago: una, pinipili ng git add kung aling mga edit ang papasok sa susunod na snapshot; pangalawa, isinusulat ng git commit ang snapshot na iyon sa history. Ang gitnang zone ay tinatawag na index, o staging area. Marami ang hindi nakakaintindi nito sa loob ng maraming taon, pero dito nagiging makabuluhan ang mga commit.

Tatlong estado ng file: working directory, index, history

Dumadaan ang bawat pagbabago sa tatlong lugar:

1. Working directory: ine-edit ninyo ang file sa editor.
2. Index (stage): inilalagay ng git add ang kasalukuyang bersyon ng file sa draft ng susunod na commit.
3. History: ginagawang commit ng git commit ang laman ng index, kasama ang author, petsa, at mensahe.

Magandang paghahambing dito ang package. Ang working directory ay kuwarto na may mga gamit, ang index ay bukas na kahon kung saan ninyo inilalagay ang gustong ipadala, at ang commit ay selyado at nakapirmang package. Kayo ang nagpapasya kung ano ang ilalagay sa kahon, at hindi kailangang ipadala lahat nang sabay-sabay.

Bakit kailangan ang index

Isipin ninyo: sa loob ng isang oras, naayos ninyo ang bug sa authentication, naitama rin ang typo sa README, at nagsimula na ng bagong feature. Kung walang index, lahat ng ito ay mapupunta sa iisang commit na "iba-iba". Sa index, tatlong magkakahiwalay na commit ang magagawa ninyo, at bawat isa ay madaling maintindihan sa review at madaling i-rollback nang hindi naaapektuhan ang iba.

git status: ano ang nabago at ano ang naihanda na

Bago ang bawat add at commit, magandang tingnan ang git status. Ito ang pinakaligtas na command sa Git, dahil wala itong binabago.

$ git status
On branch main
Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
        modified:   src/auth.js

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

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        src/profile.js

• Changes to be committed: nasa index na, papasok sa commit;
• Changes not staged: nabago na, pero hindi pa idinadagdag;
• Untracked files: mga bagong file na hindi pa alam ng Git.

Mas maikli ang format na ito kapag marami ang file:

$ git status -s
M  src/auth.js
 M README.md
?? src/profile.js

Ang unang column ay estado sa index, ang pangalawa ay estado sa working directory. Ang M sa kaliwa ay ibig sabihin "nabago at naidagdag na", ang M sa kanan ay "nabago, hindi pa naidadagdag", at ang ?? ay "hindi pa tinatrack".

git add: paano idagdag ang pagbabago sa index

Kasingkahulugan ng git add ang git stage: iisang command ito, kaya "stage" ang tawag minsan.

git add -p: idagdag ang bahagi ng file

Ito ang pinakamaliit na napapansing trick. Kapag magkahalo ang dalawang magkaibang edit sa iisang file, ipapakita ng git add -p ang bawat bahagi at magtatanong kung idadagdag ito:

$ git add -p src/auth.js
@@ -12,7 +12,7 @@ function login(user) {
-  if (user.password = input) {
+  if (user.password === input) {
(1/2) Stage this hunk [y,n,q,a,d,s,e,?]?

y para idagdag, n para lampasan, s para hatiin pa nang mas maliit ang bahagi, q para lumabas. Sa ganitong paraan, dalawang maayos na commit ang magagawa mula sa iisang file.

Paano tingnan kung ano ang papasok sa commit

git diff            # mga pagbabagong HINDI pa nasa index
git diff --staged   # ang nasa index na at papasok sa commit

Karaniwang nalilito rito: pagkatapos ng git add, walang ipinapakitang diff ang normal na git diff. Hindi ibig sabihin na nawala ang pagbabago. Nasa index na ito, kaya tingnan ang git diff --staged (kasingkahulugan ng --cached).

Paano alisin ang file sa index

git restore --staged file.js

Nananatili ang mga edit sa file, pero hindi na ito nakahanda para sa commit. Sa mas lumang bersyon ng Git, ginagamit ang git reset HEAD file.js, gumagana pa rin ito.

git commit: i-record ang mga pagbabago

git commit -m "Ayusin ang pag-check ng password sa login"

[main 3f2a9c1] Ayusin ang pag-check ng password sa login
 1 file changed, 1 insertion(+), 1 deletion(-)

Sa sagot, makikita ang branch, ang maikling hash ng bagong commit, at estadistika. Ang papasok lang sa commit ay ang laman ng index. Kung nag-edit pa kayo ng file pagkatapos ng git add, hindi papasok ang bagong edit hangga't hindi ninyo ito idinadagdag ulit.

Mga kapaki-pakinabang na flag ng git commit

Kung Vim ang default na editor at na-stuck kayo: isulat ang mensahe, pindutin ang Esc, i-type ang :wq, at Enter. Para palitan ang editor: git config --global core.editor "code --wait" o nano.

Paano sumulat ng magandang commit message

Babasahin ang mensahe pagkalipas ng anim na buwan, kapag may hinahanap na pinagmulan ng bug. Dapat nitong sagutin ang tanong na "ano at bakit", hindi "ano ang ginawa ko ngayon".

• ang unang linya: hanggang 50–72 na character, ang diwa ng pagbabago;
• nasa utos na anyo o neutral: "Magdagdag ng email validation", "Fix login redirect";
• kung kailangan, isang blangkong linya at detalye: bakit ganito, anong limitasyon;
• isang commit, isang lohikal na pagbabago.

Hindi maganda: fix, mga pagbabago, wip, asdf. Maganda: Ayusin ang pag-crash ng cart kapag walang laman ang listahan ng produkto. Maraming team ang gumagamit ng Conventional Commits format: feat: ..., fix: ..., docs: ....

git commit --amend: ayusin ang huling commit

Typo sa mensahe o nakalimutang file? Hindi kailangang gumawa ng bagong commit na "nakalimutan ko ang file". Para dito ginagamit ang amend.

Ayusin ang mensahe

git commit --amend -m "Ayusin ang pag-check ng password sa login"

Idagdag ang nakalimutang file

git add forgotten.js
git commit --amend --no-edit

Pinananatili ng --no-edit ang dating mensahe.

Mahalagang tandaan tungkol sa amend

Hindi "ine-edit" ng --amend ang commit. Gumagawa ito ng bagong commit na may ibang hash at ipinapalit ito sa luma. Ligtas ito kung kayo lang ang may kopya ng commit. Kung nakapag-git push na kayo, tatanggihan ng normal na push ang bagong bersyon, at kailangang gamitin ang git push --force-with-lease. Sa shared branch na may ibang nagtatrabaho, huwag itong gawin, dahil mabubura ninyo ang history na pinagbabasehan na ng iba.

Kung nagkamali kayo sa amend, mahahanap ang lumang commit sa git reflog, at makakabalik kayo rito gamit ang git reset --soft HEAD@{1}.

Karaniwang mga error

"nothing to commit, working tree clean"

Walang pagbabago: naka-commit na ang lahat, o nag-e-edit kayo sa ibang folder. Tingnan ang git status at ang path ng project.

"no changes added to commit"

Nabago ang mga file pero hindi naidagdag sa index. Patakbuhin ang git add, o gamitin ang git commit -am para sa mga file na tinatrack na.

"Please tell me who you are"

Walang nakatakdang pangalan at email. Patakbuhin nang minsan lang ang git config --global user.name "Pangalan" at git config --global user.email "email".

Nakapag-commit ng hindi dapat

Kung hindi pa naipapadala ang commit, i-undo ito at panatilihin ang pagbabago sa index: git reset --soft HEAD~1. Tanggalin ang hindi dapat gamit ang git restore --staged, tapos mag-commit ulit. Kung may secret na nakapasok sa commit, ituring itong nalantad at palitan ang credential.

Nagdagdag ng basura ang git add .

I-set nang maaga ang .gitignore at tingnan ang git status bago mag-commit. Ang file na tinatrack na ay titigil lang sa pagtrack pagkatapos ng git rm --cached file.

Ano talaga ang commit

Ang commit ay hindi naglalaman ng diperensiya mula sa nakaraang bersyon, kundi snapshot ng buong project: reference sa tree ng mga file, reference sa parent commit, author, petsa, at mensahe. Hindi kinokopya ang mga file na hindi nagbago. Tinuturo lang ng Git ang mga object na naka-save na, kaya maliit ang espasyong kinukuha ng history.

Ang hash ng commit (halimbawa 3f2a9c1) ay kinukuwenta mula sa lahat ng iyon. Kahit isang letra lang ang palitan sa mensahe, iba na ang hash. Kaya gumagawa ng bagong commit ang --amend at rebase imbes na galawin ang luma, at kaya nagkakasalungat ang binagong history sa mga kopya ng katrabaho.

Maikli ang pagtingin sa history ng ganito:

git log --oneline --graph -10

Bawat linya ay commit. Kung nauunawaan ninyo ang history nang hindi binubuksan ang diff, tama ang ginagawa ninyo.

Araw-araw na workflow

git status                 # ano ang nabago
git diff                   # tingnan ang mga edit
git add -p                 # piliin ang kailangan
git diff --staged          # tiyaking ito ang papasok sa commit
git commit -m "Malinaw na paglalarawan"
git log --oneline -5       # siguraduhing nasa lugar ang commit
git push                   # ipadala sa server

Lokal lang ang commit. Para mapunta ang pagbabago sa GitHub o ibang server, kailangan ang git push.

Buod

Ang git add ay nagbubuo ng susunod na snapshot sa index, ipinapakita ng git status at git diff --staged kung ano ang papasok, at isinusulat ng git commit ang snapshot sa history. Gumawa ng maliliit at lohikal na commit na may malinaw na mensahe, at para sa maliliit na pag-ayos sa huling commit, gamitin ang git commit --amend, bago pa mag-push. Ang index at ang dalawang-hakbang na add → commit ay itinuturo nang praktikal sa kursong Git namin.