.gitignore डिफ़ॉल्ट रूप से सब कुछ

मूल लेख ↗ Hacker News चर्चा ↗

“.gitignore everything by default” के समर्थक तर्क देते हैं कि इससे secrets, OS cruft, या IDE artifacts गलती से commit होने का जोखिम कम होता है, खासकर जब लोग आदतन `git add .` चलाते हैं। आलोचक कहते हैं कि यह तरीका नई फ़ाइलों को `git status` से छिपाता है, महत्वपूर्ण source files छूटने की संभावना बढ़ाता है, और collaborative settings में नाज़ुक है। कई लोग इसके बजाय global और project-level .gitignore templates, अधिक अनुशासित staging (`git add -p`, `git add .` से बचना), या commit की जाने वाली और न की जाने वाली चीज़ों को लागू करने के लिए tooling और CI checks की सलाह देते हैं।

“.gitignore everything by default” पर समग्र प्रतिक्रिया

  • कई लोग इसे खराब या ज़रूरत से ज़्यादा मानते हैं: इससे महत्वपूर्ण फ़ाइलों को un-ignore करना भूलने का जोखिम रहता है, builds/CI टूट सकते हैं, और git status में missing फ़ाइलें छिप सकती हैं।
  • समर्थक इसे एक रक्षात्मक, “deny-by-default” / सुरक्षा-उन्मुख रणनीति मानते हैं, ताकि secrets, junk, या tool-specific clutter गलती से commit न हो जाएँ।
  • कई लोग नोट करते हैं कि यह कुछ contexts में बेहतर काम करता है (जैसे Docker build contexts, Unity experiments, tightly structured repos) बजाय सामान्य development के।

Selective staging बनाम blanket git add .

  • एक मज़बूत थीम: blind git add . / git add -A से बचें।
    • सुझाए गए विकल्प: git add -u, git add -p, interactive staging, और add करने से पहले/बाद git status की समीक्षा।
  • कुछ लोग काम को इस तरह संरचित करते हैं कि git add . सुरक्षित हो (clean tree, single coherent change)।
  • reversibility पर असहमति: कुछ मानते हैं कि “सब कुछ add करना” आसानी से undo किया जा सकता है; अन्य बताते हैं कि कई उपयोगकर्ताओं को git reset / git restore --staged पता नहीं होता या वे उनका उपयोग नहीं करते।

Global और local ignore strategies

  • व्यापक रूप से सुझाया गया: user-global ignore (~/.config/git/ignore या ऐसा ही) OS/editor/tool फ़ाइलों (.DS_Store, IDE configs, Emacs/Vim litter) के लिए।
  • अन्य लोग तर्क देते हैं कि repo-level .gitignore में भी common OS/editor artifacts को defensively ignore करना चाहिए, क्योंकि हर कोई global ignore नहीं रखता।
  • लोकप्रिय patterns:
    • सभी dotfiles को globally ignore करें (.*) लेकिन key ones को explicitly un-ignore करें (!.gitignore, !.editorconfig, आदि)।
    • throwaway files के लिए dedicated scratch/playground directories या per-directory .gitignore with *।
    • personal, repo-local ignores के लिए .git/info/exclude का उपयोग करें, जो साझा नहीं होते।

AI / agent config files (जैसे CLAUDE.md)

  • इस पर असहमति है कि क्या ये repo में होने चाहिए:
    • कुछ लोगों को project-level AI instructions shared documentation के रूप में उपयोगी लगते हैं।
    • अन्य इन्हें personal preference dumps मानते हैं, editor configs के क़रीब, और .local-style, gitignored variant पसंद करते हैं।

Tooling, CI, और alternative safeguards

  • कई लोग visual diffs और hunk-level staging के लिए GUIs/TUIs (Magit, lazygit, tig, IDE integrations) की सिफारिश करते हैं।
  • कुछ लोग linters/hooks (जैसे alint) या CI rules का उपयोग करते हैं ताकि disallowed paths को रोका जा सके।
  • missing files पर CI fail होना leaked secrets की तुलना में कम नुकसानदेह माना जाता है, लेकिन अन्य लोग lost work और “works on my machine” समस्याओं को लेकर चिंतित रहते हैं।