Gitignore काम नहीं कर रहा? असली इलाज यहाँ है

TL;DR: अगर .gitignore काम नहीं कर रहा, तो फ़ाइल लगभग हमेशा पहले से tracked होती है। Git उन्हीं फ़ाइलों को अनदेखा करता है जिन्हें उसने कभी देखा ही नहीं — index में पड़ी फ़ाइल आपके लिखे किसी नियम से नहीं चीन्ही जाती। सच git check-ignore -v <path> से पूछें: ख़ामोशी का मतलब path tracked है और कोई नियम लागू नहीं। इलाज git rm --cached <path> है, commit करें, और नियम उसी commit से आगे काम करने लगेगा। नियमों की तरतीब, negation के जाल और VS Code के भ्रम बाक़ी मामले समझाते हैं।

.gitignore काम क्यों नहीं कर रहा?

ज़्यादातर मामलों का जवाब एक ही तंत्र है: नियम बनने से पहले फ़ाइल commit हो चुकी थी। .gitignore फ़ाइलों को git से छिपाने वाली कोई छलनी नहीं है — यह एक नियम है कि git add बिना-ट्रैकिंग वाली अवस्था से क्या उठाए। एक बार फ़ाइल index में आ गई, तो git उसके बदलाव हमेशा देखता रहेगा — जब तक आप साफ़ शब्दों में untrack न करें। बाद में .gitignore संपादित करने से tracked फ़ाइलों पर कोई असर नहीं पड़ता — इसीलिए क्लासिक क्रम ”.env commit करो, घबराओ, .env को .gitignore में जोड़ो, फिर commit करो” हर push पर सीक्रेट जहाज़ में लादता रहता है।

यह हर किसी को काटता है, क्योंकि git लगभग सब जगह है — Stack Overflow 2022 सर्वे में प्रोफेशनल developers में Git का इस्तेमाल 93% से ज़्यादा था (survey.stackoverflow.co) — और उनमें से हर एक किसी न किसी दिन पिछले हफ़्ते commit की गई फ़ाइल के लिए नियम लिखता है।

इस पोस्ट का बाक़ी हिस्सा कम-मिलने वाले मामलों का है: नियमों की तरतीब की चूक, negation के जाल, फ़ोल्डर वाले किनारे के मामले और IDE वाला सवाल। पर पहले अगले सेक्शन की सेहत जाँच चलाएँ — दस में से नौ से ज़्यादा बार तफ़तीश वहीं ख़त्म हो जाती है।

कौन-सा gitignore नियम किसी फ़ाइल पर लग रहा है, कैसे जाँचें?

git check-ignore तफ़तीश का औज़ार है, और उसकी ख़ामोशी ही तफ़तीश है:

# कोई नियम लागू हो तो मिलान वाला नियम + फ़ाइल + लाइन नंबर छापता है
git check-ignore -v debug.log
# .gitignore:3:*.log    debug.log

# कोई नियम लागू नहीं तो कुछ नहीं छापता — फ़ाइल tracked है (या कोई नियम मौजूद नहीं)
git check-ignore -v src/.env
# (ख़ामोशी = .gitignore इस path को अनदेखा नहीं कर रहा, जो भी आपने लिखा हो)

# Exit codes: 0 = ignored, 1 = not ignored — script में इस्तेमाल लायक़
git check-ignore -q debug.log && echo "ignored" || echo "tracked or unruly"

-v आउटपुट पढ़ें: पहले ignore का स्रोत (.gitignore, .git/info/exclude, या आपकी global ignore फ़ाइल), फिर लाइन-नंबर:पैटर्न, फिर path। अगर बाद का कोई नियम चौंका दे, तो प्राथमिकता याद रखें: आख़िरी मिलान वाला नियम जीतता है, इसलिए *.log के बाद !important.log उस एक फ़ाइल को वापस शामिल कर लेता है।

पहले से commit हुई फ़ाइलों के लिए gitignore काम क्यों नहीं करता?

फ़ाइल untrack करें, disk पर रहने दें, हटाने को commit करें:

# एक फ़ाइल untrack करें (लोकल copy बची रहती है — --cached सिर्फ़ index छेड़ता है)
git rm --cached .env
git commit -m "stop tracking .env"

# जाँचें कि ignore नियम अब लागू होता है
git check-ignore -v .env

इस commit से आगे .gitignore का इस path पर राज है: उसके बदलाव अब git status में नहीं दिखेंगे, और git add . उसे दोबारा नहीं उठाएगा। पर फ़ाइल history में पड़ी रहती है — अगर वह कोई सीक्रेट थी, तो आख़िरी commit से हटाना काफ़ी नहीं। सीडेंशियल बदलना ही असली इलाज है; history फिर लिखना श्रृंगार है (और आख़िरी commit उलटना तब तक ही काम आता है जब तक ग़लत commit चोटी पर है)।

पहले commit किए गए कबाड़ से भरे repo के लिए — build output, editor का कचरा, अंदर घुसा हुआ node_modules — थोक में untrack दो लाइन का काम है:

git rm -r --cached .
git add .
git commit -m "apply .gitignore to tracked files"

यह index को मौजूदा नियमों के हिसाब से दोबारा बनाता है: ignored paths छँट जाते हैं, बाक़ी सब जस का तस वापस जुड़ता है। Diff नाटकीय दिखता है (हज़ारों deletions) पर disk से कुछ नहीं मिटता। अगर मक़सद untrack नहीं, उन फ़ाइलों का मिटना है, तो वह git clean -fdx का इलाक़ा है — देखें git remove untracked files, safely।

Git उन्हीं फ़ाइलों को अनदेखा करता है जिन्हें उसने कभी देखा ही नहीं। Index में पहले से पड़ी फ़ाइल .gitignore से माफ़ है — आपका लिखा कोई नियम उसे अनदेखा नहीं करा सकता।

फ़ोल्डर के लिए gitignore काम क्यों नहीं करता?

फ़ोल्डर वाले तीन जाल:

1. अंत का स्लैश इरादे के लिए है, मिलान के लिए नहीं। build और build/ दोनों डायरेक्टरी से मिलते हैं, पर build/ लिखने का मतलब दर्ज होता है कि आप सिर्फ़ डायरेक्टरी कह रहे हैं — build नाम की फ़ाइल बच निकलेगी। पर यह सममिति re-inclusion पर टूट जाती है (अगला जाल)।

2. Negation, बाहर रखी डायरेक्टरी के भीतर की फ़ाइलों को नहीं बचा सकता। Git docs साफ़ कहते हैं: “किसी फ़ाइल की parent डायरेक्टरी बाहर रखी गई हो तो उस फ़ाइल को फिर से शामिल करना संभव नहीं है” (git-scm.com/docs/gitignore)। यह परफ़ॉर्मेंस का फ़ैसला है — git बाहर रखी डायरेक्टरी को साट ही देता है, अंदर चलकर नहीं देखता। इसलिए यह काम नहीं करता:

build/
!build/keep.me        # मृत नियम — git build/ के अंदर कभी झाँकता ही नहीं

इलाज यह कि सामान को बाहर रखें, डायरेक्टरी को नहीं:

build/*
!build/keep.me        # चलता है — build/ ख़ुद जाँच के लिए खुला रहता है

3. घुसपैठी .gitignore फ़ाइलें अपने इलाक़े में जीतती हैं। subdir/.gitignore के नियम subdir के नीचे के paths के लिए रूट वाली फ़ाइल को टाल देते हैं। जब git check-ignore -v कोई अनचाहा ignore स्रोत नाम लेकर दिखाए, तो आमतौर पर यही वजह होती है।

VS Code में gitignore काम क्यों नहीं कर रहा?

लगभग कभी भी VS Code की वजह से नहीं। Editor का Source Control view वही index पढ़ता है जो git पढ़ता है, इसलिए लक्षण एक ही है: फ़ाइल पहले ही commit हो चुकी थी, और कितने भी IDE रीस्टार्ट से index नहीं बदलता। दो VS Code-पास की सच्चाइयाँ जानने लायक़ हैं:

• Explorer में धुँधली = ignored; नारंगी/पीली = बदलावों के साथ tracked। आपके ignore करने के बाद भी modified दिखती फ़ाइल ही आपकी पुष्टि है कि वह tracked है — ऊपर वाला git rm --cached इलाज चलाएँ।
• Explorer की changed सूची में .gitignore न दिखे तो नियम काम कर रहा है — वह पहली जगह ही untracked फ़ाइल बनती नहीं। लोग अक्सर “VS Code ignores my gitignore” रिपोर्ट करते हैं जब CLI का git status किसी पुराने SCM view से अलग दिखाता है; git को दोष देने से पहले window रीलोड करें (Cmd/Ctrl+Shift+P → “Reload Window”)।

.gitignore vs .git/info/exclude vs global: कब कौन-सा?

फ़ाइल	दायरा	Commit होती है?	किस काम के लिए
.gitignore (repo)	Clone करने वाले सब	हाँ	Build output, dependencies, .env — साझा नियम
.git/info/exclude	सिर्फ़ आपका clone	नहीं	निजी कबाड़: .scratch/, editor का कचरा
core.excludesFile (global)	आपके सारे repos	नहीं	OS का कचरा: .DS_Store, Thumbs.db, *.swp
.gitignore + negation	Repo	हाँ	Tracked-config के अपवाद वापस शामिल करने के लिए

Global फ़ाइल वही है जिसे ज़्यादातर developers कभी सेट नहीं करते और करनी चाहिए:

git config --global core.excludesFile ~/.gitignore_global
printf '.DS_Store\nThumbs.db\n*.swp\n' >> ~/.gitignore_global

उठा लेने लायक़ घरेलू नियम: जो नियम पूरी team का काम आए, वह repo में रहे; जो सिर्फ़ आपका, वह exclude या global फ़ाइल में। निजी ignore नियम commit करने से ही .gitignore फ़ाइलें 300 लाइन लंबी हो जाती हैं और किसी को नहीं पता होता कि आधी कौन-सी है जो अब भी कोई मायने रखती है।

Tracked फ़ाइल के बदलाव अनदेखे कैसे करें?

कभी-कभी आप किसी फ़ाइल को tracked ही रखना चाहते हैं (कोई config template, IDE settings की फ़ाइल) पर चाहते हैं कि लोकल बदलाव git status में दिखना बंद कर दें। git update-index के दो flags, जिनमें से कोई भी team workflow में जगह नहीं रखता:

git update-index --skip-worktree config/local.dev   # लोकल बदलाव चुप
git update-index --no-skip-worktree config/local.dev  # ...और वापस

--skip-worktree उनमें सही-ठहराने लायक़ है — वह कहता है “मेरा लोकल version जान-बूझकर अलग है।” उसकी जोड़ी --assume-unchanged परफ़ॉर्मेंस का वादा है (“यह फ़ाइल नहीं बदलेगी”), ignore की कोई प्रणाली नहीं, और git उसे चुपचाप तोड़ भी सकता है। दोनों flags pull के वक़्त ऊँची आवाज़ में फेल होते हैं अगर upstream ने भी फ़ाइल बदली हो — टिकाऊ जवाब हैं: बनते ही exclude से लोकल-only config, या एक template फ़ाइल (config.example) जिसे git track करे और आप उसकी copy बना लें।

30 सेकंड की gitignore सेहत जाँच

git check-ignore -v <path>        # कौन-सा नियम? (ख़ामोशी = tracked, कोई नियम नहीं)
git ls-files --error-unmatch <path>  # track है भी या नहीं?
git rm --cached <path>            # untrack करें, disk पर रखें
git commit -m "stop tracking <path>"
git check-ignore -v <path>        # नियम अब दिखता है

तफ़तीश करें, untrack करें, जाँचें। हर “gitignore not working” रिपोर्ट के पीछे वही एक फ़ाइल है जो दो टोपियाँ पहने है — index की एक ओर tracked, दूसरी ओर ignored — और एक --cached flag दूसरी टोपी उतार देता है।