Mag-commit — ano ito, mga panuntunan sa pag-format at pagtatrabaho sa Git

Ano ang commit sa Git

Ang commit sa Git ay isang object na nag-iimbak ng estado ng mga file ng proyekto sa isang tiyak na oras. Bawat commit ay naglalaman ng snapshot ng lahat ng sinusubaybayang file, reference sa parent commit at metadata. Hindi tulad ng ibang version control system, gumagamit ang Git ng content-addressable storage — bawat object ay natutukoy ng SHA-1 hash ng nilalaman nito.

Kapag nag-commit ang developer ng mga pagbabago, gumagawa ang Git ng commit object na nag-iimbak ng: tree object (istruktura ng file), parent commit hash, may-akda, committer, petsa at mensahe. Ang object na ito ay hindi nababago — pagkatapos gawin ay hindi maaaring baguhin ang commit nang hindi binabago ang hash nito. Ang hindi pagbabagong ito ang nag-gagarantiya ng integridad ng history ng proyekto.

# I-stage ang mga pagbabago at mag-commit
git add index.html style.css
git commit -m "Fix responsive layout on mobile devices"

# Tingnan ang detalye ng commit
git log --oneline -3
git show HEAD

# I-stage lahat ng pagbabago at mag-commit sa isang hakbang
git commit -a -m "Update dependencies to latest versions"

Ang mga commit ay bumubuo ng directed acyclic graph (DAG), kung saan ang bawat bagong commit ay tumutukoy sa nauna. Ito ay nagbibigay-daan sa pag-navigate sa history, pagbawi ng mga pagbabago at pagsusuri ng ebolusyon ng codebase. Pag-unawa sa istruktura ng Git DAG — pundasyon ng advanced na pagtatrabaho sa commit.

Paano mag-commit ng mga pagbabago nang tama

Ang proseso ng commit sa Git ay binubuo ng dalawang yugto: pagdaragdag ng mga pagbabago sa staging area (index) at paggawa ng commit. Ang staging area ay nagbibigay-daan sa developer na pumili kung aling mga pagbabago ang isasama sa commit, kahit na maraming file ang nabago sa working directory.

Ang prinsipyo ng atomicidad — susi sa magandang commit. Bawat commit ay dapat maglaman ng isang lohikal na pagbabago. Kung ang developer ay nag-aayos ng bug at nagre-refactor ng code — ito ay dalawang magkaibang commit. Ang mga atomic commit ay nagpapadali ng code review, pagbawi ng pagbabago at pagsusuri ng history.

Bago mag-commit, mainam suriin: kung may natitira pang debug output, naka-comment na blocks o aksidenteng pagbabago sa code. Para dito gamitin ang command na git diff --cached, na nagpapakita kung ano ang eksaktong isasama sa commit. Karagdagang pagsusuri sa pamamagitan ng git status ay nagpapakita ng listahan ng mga file sa staging area.

• Suriin ang mga pagbabago — git diff --cached nagpapakita kung ano ang isasama sa commit
• Suriin ang kalidad — code dapat pumasa sa linter at tests bago mag-commit
• Sumulat ng mensahe — malinaw na deskripsyon ng layunin ng pagbabago
• Suriin ang staged — git status kinukumpirma ang listahan ng file

Mga panuntunan sa pagsulat ng mensahe ng commit

Ang mensahe ng commit ay dokumentasyon ng pagbabago para sa hinaharap na mga developer. Ang magandang mensahe ay sumasagot sa mga tanong: ano ang binago at bakit. Ang Conventional Commits convention (Angular team, 2016) ay naging pamantayan para sa maraming proyekto at tumutukoy sa format: uri(saklaw): deskripsyon.

Ang magandang commit message ay binubuo ng headline (hanggang 50 character) at body (opsyonal, hanggang 72 character bawat linya). Ang headline ay isinusulat sa imperative mood: “Add” hindi “Added” o “Adds”. Ang Capitalization at tuldok sa dulo ng headline ay hindi ginagamit — ito ang international na kasunduan ng Git.

Masamang mensahe: “fix things” o “update” — walang impormasyon. Pagkalipas ng isang buwan, hindi mauunawaan ng developer kung ano ang eksaktong binago at bakit. Magandang mensahe: “fix(payment): handle timeout in stripe callback” — agad malinaw kung saan at ano ang naayos.

Mga karaniwang pagkakamali sa commit

Ang mga developer, lalo na ang mga baguhan, ay madalas nagkakamali sa commit. Ang pinakakaraniwan — sobrang laking commit na pinaghalo ang sampu-sampung pagbabago. Hindi ito maaaring bahagyang ibalik, at ang code review ay nagiging pahirap.

Ang pangalawang pinakakaraniwang pagkakamali — masamang commit message. Ang mga mensaheng tulad ng “fix”, “update”, “changes” o “wip” ay hindi nagbibigay ng konteksto sa hinaharap na mga developer. Pagkalipas ng anim na buwan, walang makakaalala kung ano ang eksaktong naayos. Ang panuntunan ay simple: isipin na pagkalipas ng isang taon tiningnan mo ang history at sinusubukan mong hanapin ang isang partikular na pagbabago.

Pangatlong pagkakamali — commit ng hindi naka-compile o hindi gumaganang code. Pagkatapos ng commit, code dapat kahit papaano ay mag-compile. Hindi sirang build — pangunahing pangangailangan para sa bawat commit sa shared branch. Para dito bago mag-commit, pinapatakbo ang build at tests.

Pang-apat na pagkakamali — commit na may kumpidensyal na data. Ang mga API key, password at token ay hindi dapat mapunta sa Git history. Kung ang lihim ay na-commit na, hindi sapat na tanggalin lamang ito sa bagong commit — dapat tanggalin mula sa buong history sa pamamagitan ng git filter-branch o BFG Repo-Cleaner.

Mga advanced na teknik sa pagtatrabaho sa commit

Nagbibigay ang Git ng mga tool para sa pamamahala ng commit history. Isa sa pinaka-kapaki-pakinabang ay git commit --amend, na nagbibigay-daan dagdagan ang huling commit ng mga bagong pagbabago o itama ang mensahe. Ito ay maginhawa kung nakalimutan ng developer na isama ang file o nagkamali sa mensahe.

# Ayusin ang huling commit message
git commit --amend -m "fix(auth): correct token validation logic"

# Idagdag ang nakaligtaang file sa huling commit
git add missed-file.txt
git commit --amend --no-edit

# Interactive rebase para sa huling 3 commit
git rebase -i HEAD~3

Ang Interactive rebase — makapangyarihang tool para sa pagsusulat muli ng history. Pinapayagan nito ang pagsasama ng commit (squash), pagbabago ng mensahe (reword), pagbabago ng pagkakasunod-sunod (reorder) at pagtanggal ng commit (drop). Gayunpaman, binabago ng rebase ang history, kaya inilalapat lamang ito sa mga lokal na commit na hindi pa na-push sa remote repository.

Para sa pagbawi ng commit may dalawang approach. git revert ay gumagawa ng bagong commit na bumabawi sa mga pagbabago ng nauna — ligtas na paraan na nag-iingat ng history. Ang git reset ay nagtatanggal ng commit mula sa history — mapanganib kung ang commit ay na-push na. Sa team development, tanging git revert ang ginagamit para sa pagbawi ng mga nai-publish na commit.