इस पेज पर

git log

संक्षेप में: git log project history का audit करने का Git का मुख्य tool है। यह commits के Directed Acyclic Graph (DAG) को current checkout point (HEAD) से शुरू करके traverse करता है, उसके parent hashes पढ़ता है और शुरुआती root commit तक पीछे की ओर recursively चलता है। इसलिए यह केवल text-based list नहीं, बल्कि search और analysis का शक्तिशाली tool है।

नीचे दिए गए hashes के बारे में एक बात: इस lesson में commit और tree IDs उदाहरण के लिए दिए गए हैं। Commit hash उसके tree, parents, author/committer identities और commit timestamp से बनता है—इसलिए वही कमांड्स खुद चलाने पर graph structure तो वही मिलेगा, लेकिन IDs अलग होंगे। दिखाए गए timestamps Unix epoch seconds हैं और +0000 (UTC) offset के साथ हैं।

git log वास्तव में क्या करता है?

यह समझने के लिए कि git log आपका history कैसे बनाता है, पहले देखें कि Git commits को कैसे व्यवस्थित करता है। Git आपके commits को flat list या array में स्टोर नहीं करता। इसके बजाय वह उन्हें Directed Acyclic Graph (DAG) के रूप में व्यवस्थित करता है।

इस graph में:

  • Nodes: ये आपके commit objects होते हैं।
  • Edges: ये child commit से उसके parent commit(s) की ओर जाने वाले pointers होते हैं। ये directed होते हैं (समय में पीछे की ओर point करते हैं) और acyclic होते हैं (history खुद में loop नहीं कर सकती)।
graph RL
    C3[Commit 3<br>HEAD / main] -->|parent| C2[Commit 2]
    C2 -->|parent| C1[Commit 1<br>Root Commit]

जब आप git log चलाते हैं, Git पूरी disk scan नहीं करता। इसके बजाय वह किसी दिए गए entry point से graph traversal शुरू करता है—डिफ़ॉल्ट रूप से HEAD जिस commit की ओर point करता है (आपकी current location, link git-checkout)।

ट्रैवर्सल एल्गोरिदम

  1. Git फ़ाइल .git/HEAD पढ़कर आपका active branch पता करता है (जैसे ref: refs/heads/main)।
  2. वह active branch reference को .git/refs/heads/main पढ़कर उसके 40-character commit hash (जैसे 8a4c10...) में resolve करता है।
  3. वह object डेटाबेस (.git/objects/) से commit object 8a4c10... load करता है और metadata निकालता है: Author, Committer, Timestamp, Message और parent hash।
  4. Git इस commit की details आपके console पर output करता है।
  5. Git parent hash (जैसे 55a420...) को traversal queue में डालता है।
  6. यह loop दोहरता है: Git अगला commit hash queue से निकालता है, उसे पढ़ता है, दिखाता है और उसके parents queue में डालता है।
  7. जब किसी commit में parent field नहीं होती, तब traversal रुक जाता है; इसका मतलब repository का सबसे पहला commit (root commit) मिल गया है।

Merge commit में commit object में कई parent lines होती हैं। Git सभी parent hashes को queue में डालकर इसे संभालता है। Sorting settings (जैसे chronological, topological या date-ordered) के आधार पर Git merged branches के commits को आपस में रखकर एक unified timeline बनाता है।

.git/ के अंदर क्या होता है (hands-on exploration)

आइए कई commits और branches वाला repository बनाते हैं, फिर ठीक-ठीक trace करते हैं कि Git अपनी फ़ाइलें को parse करके git log output कैसे बनाता है।

चरण 1: कई commits वाला repository तैयार करें

आइए repository initialize करें और main branch पर दो quick commits करें।

$ mkdir git-log-demo && cd git-log-demo
$ git init
Initialized empty Git repository in /git-log-demo/.git/

$ echo "v1" > file.txt
$ git add file.txt
$ git commit -m "First commit"
[main (root-commit) 5be36ab] First commit

$ echo "v2" > file.txt
$ git add file.txt
$ git commit -m "Second commit"
[main ae39f81] Second commit

चरण 2: एक branch और merge commit बनाएँ

अब feature नाम की branch बनाएँ (link git-branch), एक commit करें, वापस switch करें और उसे merge करें।

$ git checkout -b feature
Switched to a new branch 'feature'

$ echo "feature-work" > feature.txt
$ git add feature.txt
$ git commit -m "Feature commit"
[feature c4f8101] Feature commit

$ git checkout main
Switched to branch 'main'

$ git merge feature -m "Merge feature branch"
Merge made by the 'ort' strategy.
 feature.txt | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 feature.txt

चरण 3: refs को resolve करें और commits को cata-log करें

देखते हैं कि HEAD इस समय कहाँ point कर रहा है:

$ cat .git/HEAD
ref: refs/heads/main

अब देखते हैं कि main किस commit hash की ओर point कर रहा है:

$ cat .git/refs/heads/main
6df8d0354178de3d038fa61dfb63e8a157580b33

यह हमारा merge commit है। Plumbing कमांड git cat-file से इस commit object को देखते हैं:

$ git cat-file -p 6df8d0354178de3d038fa61dfb63e8a157580b33
tree e7c3909ea1dc725f187e1451f2ad490e5b0213ef
parent ae39f81ca99d45e5b619d854cf78d1f2a36b1d2e
parent c4f810129a8a72cf5a1db5b2f270a2936274b1e2
author Purna Pattela <purna@example.com> 1772960500 +0000
committer Purna Pattela <purna@example.com> 1772960500 +0000

Merge feature branch

ध्यान दें कि यह merge commit होने के कारण इसके दो parents हैं:

  • parent ae39f81... (merge से पहले main पर आखिरी commit)।
  • parent c4f8101... (feature branch का commit)।

अगर हम git log चलाते हैं, तो Git पहले merge commit (6df8d03) output करेगा, फिर उसके parents पढ़ेगा। यह parent ae39f81 और c4f8101 के नीचे chronological order में traverse करता है। ae39f81 को देखते हैं:

$ git cat-file -p ae39f81ca99d45e5b619d854cf78d1f2a36b1d2e
tree b4f93dc52c0dfa6c7f8a9a2a6dfba1d2a36b567d
parent 5be36abc0e9df7f2a7db2e9b0cf2a3d2427a1d1e
author Purna Pattela <purna@example.com> 1772960400 +0000
committer Purna Pattela <purna@example.com> 1772960400 +0000

Second commit

यह commit शुरुआती parent 5be36ab... की ओर point करता है। 5be36ab को देखते हैं:

$ git cat-file -p 5be36abc0e9df7f2a7db2e9b0cf2a3d2427a1d1e
tree f3b3a3c9e6db5832a875a6c11d2b270a2936274b
author Purna Pattela <purna@example.com> 1772960300 +0000
committer Purna Pattela <purna@example.com> 1772960300 +0000

First commit

5be36ab... में कोई parent line नहीं है, इसलिए Git समझता है कि यह tree का root है और traversal रोक देता है। नतीजे में log output चारों commits को reverse chronological order में दिखाता है।

विस्तृत कमांड विकल्प और उन्नत उपयोग

git log का डिफ़ॉल्ट output verbose और sequential होता है। Flags से आप history को format, filter और trace कर सकते हैं।

1. उन्नत फ़ॉर्मेटिंग विकल्प

--oneline

हर commit को एक line में दिखाता है, जिसमें abbreviated commit hash और subject line होती है। Commit histories को जल्दी scan करने के लिए यह उपयोगी है।

$ git log --oneline
6df8d03 Merge feature branch
c4f8101 Feature commit
ae39f81 Second commit
5be36ab First commit

--graph --decorate

Branch execution paths और branch labels (HEAD, branch names, tags) के साथ ASCII-art representation बनाता है।

$ git log --graph --oneline --decorate --all
*   6df8d03 (HEAD -> main) Merge feature branch
|\
| * c4f8101 (feature) Feature commit
* | ae39f81 Second commit
|/
* 5be36ab First commit

Custom formats (--pretty=format:)

Placeholders से आप अपने output templates बना सकते हैं। उदाहरण के लिए, केवल hash, author name, date और commit message print करने के लिए:

$ git log --pretty=format:"%h - %an (%ar): %s"
6df8d03 - Purna Pattela (2 minutes ago): Merge feature branch
c4f8101 - Purna Pattela (5 minutes ago): Feature commit

मुख्य placeholders में शामिल हैं:

  • %h: Abbreviated commit hash।
  • %an: Author name।
  • %ar: Author date (relative, जैसे “3 days ago”)।
  • %ad: Author date (absolute format)।
  • %s: Subject line (commit message की पहली line)।
  • %d: Ref decorations (जैसे (HEAD -> main))।

2. फ़ॉरेंसिक इतिहास फ़िल्टरिंग

Code changes से search करना (Pickaxe -S)

अगर आप पता लगाना चाहते हैं कि किसी खास text string (जैसे function name या API endpoint) को आपके codebase में किस commit ने जोड़ा या हटाया, तो -S flag इस्तेमाल करें:

$ git log -S "payment_processor_v2" --oneline

इसे Pickaxe कहा जाता है। यह केवल commit message text में search करने के बजाय हर commit state में फ़ाइलें के contents को search करता है।

Commit message से search करना (--grep)

केवल commit messages में किसी keyword को search करने के लिए:

$ git log --grep="bugfix"

Path से filter करना

किसी खास फ़ाइल या फ़ोल्डर को modify करने वाले commits देखने के लिए, double-dash के बाद फ़ाइल path जोड़ें:

$ git log --oneline -- src/utils/helper.js

वास्तविक परिदृश्य: रिग्रेशन डीबग करना

मान लीजिए आपकी team application का नया version deploy करती है और users बताते हैं कि “Submit” button पर click करते ही application crash हो रही है। आपको पता है कि button एक सप्ताह पहले ठीक काम कर रहा था।

Culprit खोजने के लिए आप history filters को साथ में इस्तेमाल कर सकते हैं:

# Step 1: List all commits from the last week that modified the checkout button component
$ git log --since="1 week ago" --oneline -- src/components/SubmitButton.js
a3d5f9c refactor: rewrite submit click handler
54f8b9e chore: update button styling

# Step 2: Show the actual code modifications in the suspicious commit (a3d5f9c)
$ git log -p -1 a3d5f9c

Patch flag -p से आप handler function में हुए exact changes review करते हैं, missing event parameter पकड़ते हैं और hotfix लिखते हैं।

आम pitfalls और गलतियाँ

1. Pager में फँस जाना

Default रूप से, अगर log output आपकी screen की height से लंबा हो, तो Git output को pager utility (आमतौर पर less) में pipe करता है। Beginners को अक्सर normal terminal पर लौटने का तरीका पता नहीं होता।

  • Fix: Pager से बाहर निकलने के लिए q दबाएँ।
  • Tip: अगर आप pager खोले बिना output सीधे terminal पर print कराना चाहते हैं, तो pager config को cat पर set करें:
$ git --no-pager log -n 5

2. दूसरी branches के commits न दिखना

git log केवल वे commits दिखाता है जो आपकी current branch के history से reachable हैं। अगर आप main पर हैं और किसी ने feature-b पर changes push किए हैं, तो वे commits आपको नहीं दिखेंगे।

  • Fix: सभी branches के सभी commits दिखाने के लिए --all flag इस्तेमाल करें:
$ git log --oneline --all --graph

3. git log और git reflog को एक समझना

अगर आप rebase (link git-rebase) या reset commits करते हैं, तो वे commits branch history से हट जाते हैं और आगे git log में नहीं दिखेंगे।

  • क्यों: git log केवल active pointers को traverse करता है।
  • Fix: git reflog इस्तेमाल करें। Reference log आपके local machine पर HEAD pointer में हुए हर एक बदलाव (checkout switches, amends, resets और rebases सहित) को track करता है। “Deleted” commits recover करने के लिए यह आपका ultimate safety net है।

कमांड त्वरित संदर्भ

CommandAction
git logपूरा commit history (hashes, author, date, message) दिखाता है।
git log --onelineहर commit का compact, single-line summary दिखाता है।
git log --graph --oneline --allसभी branches और merges का visual tree दिखाता है।
git log -pहर commit से आया patch (code diff) दिखाता है।
git log -n <limit>Output को बताए गए commits की संख्या तक सीमित करता है (जैसे -n 5)।
git log --author="Name"Author name के आधार पर history filter करता है।
git log --grep="pattern"Message में keywords के आधार पर commits filter करता है।
git log -S "code"किसी खास code line/word को जोड़ने या हटाने वाले commits ढूँढता है।
git log --no-mergesHistory log से merge commits हटाता है।

FAQ (लोग अक्सर पूछते हैं)

मेरे commits git log में क्यों नहीं दिख रहे?

अगर आपने अभी git commit चलाया है लेकिन वह log में नहीं दिख रहा, तो ये बातें जाँचें:

  1. Staging जाँच: क्या commit से पहले आपने git add चलाया था? अगर नहीं, तो संभव है कि कुछ staged न होने के कारण commit reject हो गया हो।
  2. Detached HEAD: अगर आप detached HEAD state में हैं, तो आपके commits किसी branch से जुड़े नहीं हैं। main checkout करने पर वे आपके log से गायब लगेंगे। Missing hashes खोजने के लिए git reflog चलाएँ।

Author Date और Committer Date में क्या अंतर है?

  • Author Date: Commit मूल रूप से बनाए जाने का timestamp (जैसे git commit चलाते समय)।
  • Committer Date: Commit को repository में आखिरी बार लिखे जाने का timestamp (जैसे cherry-picked, rebased या amended होने पर)।
  • Default रूप से git log Author Date दिखाता है। Committer Date देखने के लिए चलाएँ: git log --pretty=fuller।

किसी फ़ाइल में किसी खास line को किसने बदला, यह कैसे देखें?

git log -S किसी string को introduce करने वाला commit ढूँढ सकता है, लेकिन line-by-line authorship देखने के लिए git blame <file> सबसे तेज़ है। यह फ़ाइल की हर line के लिए commit hash, author name और timestamp दिखाता है।

किसी खास date range के लिए commit history कैसे search करें?

आप --since (या --after) और --until (या --before) flags को साथ में इस्तेमाल कर सकते हैं:

$ git log --since="2026-06-01" --until="2026-07-01" --oneline

Git relative human dates भी समझता है, जैसे --since="3 weeks ago" या --until="yesterday"।

अपनी जानकारी जाँचें

क्विज़ लोड हो रही है…