git log, diff, show, at blame: paano basahin ang history ng project sa Git

Apat na command ang sumasagot halos sa lahat ng tanong tungkol sa history ng project. Sinasagot ng git log ang "ano ang nangyari", ng git diff ang "ano talaga ang nagbago", ng git show ang "ano ang laman ng partikular na commit", at ng git blame ang "sino at kailan sumulat ng linyang ito". Narito ang mga praktikal na teknik para sa bawat isa, kasama ang mga flag na talagang ginagamit sa araw-araw na development.

git log: listahan ng mga commit

Kapag walang argumento, ipinapakita ng git log ang mga commit ng kasalukuyang branch mula bago hanggang luma: buong SHA-1 hash, author, petsa, at mensahe. Nasa pager ito (karaniwang less): space para sa susunod na pahina, /teksto para maghanap, at q para lumabas.

commit 7be41d0c9a2e4f1b8d6c3e5a7f9b0c2d4e6f8a1b
Author: Anna Petrova <anna@example.com>
Date:   Mon Oct 5 14:22:10 2026 +0800

    feat: cache ng sagot ng API

Hindi kailangang kopyahin nang buo ang hash: tinatanggap ng Git ang anumang natatanging prefix na hindi bababa sa 4 na character, at sa praktika sapat na ang 7.

Compact na output: --oneline

git log --oneline -10
# 7be41d0 (HEAD -> main, origin/main) feat: cache ng sagot ng API
# 1c02e8f fix: timeout ng request
# 9a4b3c2 refactor: inilipat ang client sa module

Nililimitahan ng flag na -10 (o -n 10) ang bilang ng commit. Sa loob ng bracket, makikita ang mga pointer: nasaan ang HEAD, ang lokal at remote na branch, at ang mga tag.

Graph ng branch: git log --graph

Ang paghahanap ng "git graph" ay karaniwang ang ibig sabihin nito: pagpapakita ng mga sangay at merge sa terminal mismo.

git log --oneline --graph --all
# * 3e1f0aa (feature/auth) feat: login gamit ang token
# | * 7be41d0 (HEAD -> main) feat: cache ng sagot ng API
# |/
# * 1c02e8f fix: timeout ng request
# *   5d2c7b1 Merge branch 'feature/search'
# |\
# | * 8f3a9e0 feat: search
# |/
# * 9a4b3c2 refactor: inilipat ang client sa module

Ipinapakita ng --all ang lahat ng branch, hindi lang ang kasalukuyan. Maginhawang gumawa ng alias: git config --global alias.lg "log --oneline --graph --all --decorate", at pagkatapos, sapat na ang git lg.

Sariling format: --pretty=format

git log --pretty=format:"%h %ad %an %s" --date=short
# 7be41d0 2026-10-05 Anna Petrova feat: cache ng sagot ng API

Mga pangunahing placeholder: %h ang maikling hash, %H ang buo, %an ang author, %ae ang email nito, %ad ang petsa ng author, %ar ang kamag-anak na petsa ("2 days ago"), at %s ang headline ng mensahe.

Paano mag-filter ng history sa git log

Ayon sa author at petsa

git log --author="Anna"
git log --since="2 weeks ago" --until="2026-10-01"
git log --since=yesterday --oneline

Tumatanggap ang --author ng regular expression at naghahanap sa pangalan at email. Naiintindihan ng Git ang mga petsa sa malayang anyo at sa ISO.

Ayon sa teksto ng mensahe

git log --grep="fix" -i --oneline

Ginagawang hindi sensitibo sa malaki-maliit na letra ng -i ang paghahanap. Kung naglalagay ang team ninyo ng numero ng task sa mga mensahe, mabilis nitong makikita ang lahat ng commit ng isang task.

Ayon sa file o folder

git log --oneline -- src/api/client.py
git log --follow -p -- src/api/client.py

Pinaghihiwalay ng double dash ang mga path sa mga branch. Patuloy na sinusundan ng --follow ang history ng file kahit dumaan sa pag-rename (gumagana para sa isang file), at ipinapakita ng -p ang patch ng bawat commit.

Ayon sa binagong code: paghahanap ng "kalso"

git log -S "retry_count" --oneline     # mga commit kung saan nagbago ang bilang ng paglitaw ng string
git log -G "timeout\s*=" --oneline    # mga commit kung saan may linya sa diff na tumutugma sa regex

Hinahanap ng -S ang commit kung saan idinagdag o inalis ang function o variable. Hindi ito mapapalitan kapag gusto ninyong malaman kung saan nawala ang isang piraso ng code.

Mga saklaw ng commit

git log main..feature      # nasa feature pero wala sa main
git log origin/main..HEAD  # mga lokal kong commit na hindi pa naipapadala
git log --no-merges        # walang merge commit
git log --stat             # aling mga file at ilang linya ang nabago

git diff: ano talaga ang nagbago

Ang pinakamahalagang maintindihan tungkol sa git diff ay kung aling dalawang estado ang pinaghahambing nito. Dito nanggagaling ang tanong na "bakit walang laman ang diff, binago ko naman ang lahat."

Kapag nagawa na ang git add, magiging walang laman ang karaniwang git diff: nasa index na ang mga pagbabago, kaya tingnan ang --staged. Hindi ipinapakita ng diff ang mga bagong file na hindi pa naidadagdag kailanman.

Paano basahin ang output ng diff

diff --git a/config.py b/config.py
index 3b18e51..a1c4f02 100644
--- a/config.py
+++ b/config.py
@@ -10,7 +10,7 @@ DEFAULTS = {
     "host": "localhost",
-    "timeout": 5,
+    "timeout": 30,
     "retries": 3,

Ang mga linyang may - ay inalis, ang may + ay idinagdag, at ang iba ay konteksto. Ibig sabihin ng header na @@ -10,7 +10,7 @@: nagsisimula ang bahagi sa linya 10 at sumasakop ng 7 linya sa luma at bagong bersyon.

Mga kapaki-pakinabang na flag ng git diff

git diff --stat main feature      # buod ayon sa file
git diff --name-only HEAD~3       # pangalan lang ng mga binagong file
git diff --word-diff               # pagbabago ayon sa salita, mainam para sa teksto
git diff -w                        # huwag isama ang pagbabago sa whitespace
git diff main feature -- src/      # limitahan sa folder

Bago ang bawat commit, makabubuting tingnan ang git diff --staged: ito ang huling pagkakataon na mapansin ang debug na print o file na hindi sinasadyang naidagdag.

git show: buong commit

Ipinapakita ng git show ang metadata ng commit at ang diff nito laban sa parent. Kapag walang argumento, ang huling commit ang ipinapakita.

git show 7be41d0
git show HEAD~2 --stat           # walang patch, buod lang
git show v1.2.0                  # tag: annotation at commit
git show main:src/config.py      # file gaya ng itsura nito sa commit

Lalong kapaki-pakinabang ang huling anyo na <revision>:<path>: makikita ninyo ang lumang bersyon ng file nang hindi lumilipat dito. I-redirect ang output sa file, at maibabalik ninyo ang naburang nilalaman nang walang checkout.

git blame: sino ang nagbago ng linyang ito

git blame file ay nagpapakita, para sa bawat linya, ng huling commit na nagbago nito, ng author, at ng petsa. Parang akusasyon ang pangalan, pero ang totoo, kasangkapan ito sa paghahanap ng konteksto: hanapin ang commit, basahin ang mensahe, at intindihin kung bakit ganoon ang code.

git blame -L 40,60 src/api/client.py
# 1c02e8f3 (Anna Petrova 2026-09-28 11:04:51 +0800 41)     timeout = settings.timeout
# 9a4b3c2e (Ivan Smirnov 2026-09-14 18:30:02 +0800 42)     session = build_session()

• -L 40,60: saklaw lang ng mga linya; puwede rin ang -L :pangalan_ng_function.
• -w: huwag isama ang pagbabago sa whitespace, para hindi mapunta sa mga commit ng formatting.
• -C: sundan ang mga linyang inilipat mula sa ibang file.
• --ignore-rev <hash> o file na .git-blame-ignore-revs: laktawan ang malalaking commit gaya ng auto-formatting.

Tipikal na imbestigasyon: hahanapin ng git blame ang commit, ipapakita ng git show ang buo nito, at ang git log sa file ay magbibigay ng mga kalapit na pagbabago.

Paglalakbay sa nakaraan: HEAD~ at HEAD^

Hindi lang hash ang paraan ng pagtukoy sa commit. Ang HEAD~1 ang parent ng kasalukuyang commit, at ang HEAD~3 ang tatlong hakbang pabalik. Ang HEAD^2 ang pangalawang parent ng merge commit. Gumagana rin ang pangalan ng branch, tag, at remote branch: origin/main~2. Para makita ang buong proyekto sa lumang commit, gamitin ang git switch --detach <hash>, at pagbalik ay git switch -.

Mabuti at masamang history

Gaano kapaki-pakinabang ang lahat ng command na ito ay nakadepende sa kung gaano kalinaw ang history. Ang mga mensaheng gaya ng "fix", "wip", "mga pagbabago pa" ay ginagawang walang saysay ang git log --grep at git blame. Ang magandang commit ay iisang lohikal na pagbabago na may headline na nagpapaliwanag ng ano at bakit: fix: itinaas ang API timeout sa 30 s dahil sa mabagal na gateway. Pagkalipas ng anim na buwan, ang ganitong commit ang hahanapin ng blame at makakatipid ng isang oras.

Praktika: pag-imbestiga ng bug gamit ang history

Halimbawa, pagkatapos ng isang release, nagsimulang mag-timeout ang mga request sa API. Ganito dadalhin ng kombinasyon ng mga command ang sanhi sa loob ng ilang minuto.

1. Tingnan kung ano ang pumasok sa release: git log v1.4.0..v1.5.0 --oneline. Maikli ang listahan, pero hindi halata sa mga headline kung sino ang may kasalanan.
2. Paliitin ayon sa file: git log v1.4.0..v1.5.0 --oneline -- src/api/. Dalawang commit na lang ang natitira.
3. Maghanap sa code: git log -S "timeout" --oneline -- src/api/ ang nakakita ng commit kung saan nagbago ang halaga ng timeout.
4. Tingnan nang buo: git show 1c02e8f. Makikita sa diff na binawasan ang timeout mula 30 papuntang 5 segundo, at ang paliwanag sa mensahe ay "pinabilis ang tugon ng UI".
5. Tingnan kung sino pa ang humawak sa linyang iyon: git blame -L :build_session src/api/client.py.

Pagkatapos nito, usapin na ng engineering ang desisyon: ibalik ang halaga, ilipat ang timeout sa settings, o i-revert ang commit gamit ang git revert. Kung daan-daang commit na at hindi na matukoy ang sanhi sa pamamagitan ng pagbabasa, dito papasok ang git bisect: binary search sa history na sa ilang hakbang ay tumuturo sa commit na sumira sa kilos ng code.

Mga setting na nagpapagaan ng buhay

git config --global log.date iso            # format ng petsa sa log
git config --global diff.colorMoved zebra   # i-highlight ang mga inilipat na linya sa diff
git config --global core.pager "less -FRX"  # huwag buksan ang pager para sa maikling output

Kapag ipoproseso ng script ang output, i-off ang kulay at pager: git --no-pager log --format="%H %s" --no-color. Para sa machine processing, gamitin ang buong hash na %H: maaaring maging malabo ang maiikling prefix sa malaking repository habang lumalaki ito.

Buod

Ang git log na may mga filter na --oneline, --graph, --author, -S, at path ay sumasagot sa "ano ang nangyari". Ang git diff ay nagkukumpara ng working directory, index, at mga commit: tandaan lang kung ano ang default nitong pinaghahambing. Ang git show ay nagbubukas ng isang commit o lumang bersyon ng file, at ang git blame ay nagdadala mula sa linya ng code pabalik sa desisyong nagbunga nito. Ang pagbabasa ng history at paglalakbay sa mga commit ay itinuturo nang praktikal sa kursong Git namin.