Git की मैजिक फ़ाइलें

 (nesbitt.io)
45 पॉइंट द्वारा GN⁺ 2026-02-24 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • Git repository के भीतर मौजूद कुछ खास फ़ाइलों के जरिए अपने काम करने का तरीका नियंत्रित करता है, और ये .git/ के अंदर की settings नहीं बल्कि commit होकर code के साथ चलने वाली फ़ाइलें होती हैं
  • .gitignore, .gitattributes, .lfsconfig, .gitmodules, .mailmap आदि क्रमशः फ़ाइल tracking से बाहर रखना, attributes तय करना, LFS settings, submodule management, author mapping का काम करते हैं
  • .git-blame-ignore-revs और .gitmessage code formatting commits को ignore करने और commit message template देने के जरिए collaboration की quality बेहतर बनाते हैं
  • GitHub, GitLab, Gitea आदि .github/, .gitlab/, .gitea/ जैसी platform-specific config folders के जरिए CI/CD, reviewer assignment जैसी सुविधाओं का विस्तार करते हैं
  • यही संरचना Git से आगे बढ़कर EditorConfig, Docker, language version management tools आदि में भी लागू होती है, जिससे dotfile-आधारित automatic configuration ecosystem बनता है

Git की प्रमुख मैजिक फ़ाइलें

  • Git .gitignore, .gitattributes, .lfsconfig, .gitmodules, .mailmap जैसी कई special files को पहचानकर repository के behavior को नियंत्रित करता है
    • ये फ़ाइलें .git/ के अंदर की settings नहीं बल्कि commit होकर साझा की जाने वाली configuration हैं, जो collaboration के दौरान consistent behavior सुनिश्चित करती हैं

.gitignore

  • उन file patterns को परिभाषित करता है जिन्हें Git को track नहीं करना चाहिए
    • wildcard(*.log), directory(dist/), negation(!important.log) आदि को support करता है
    • .gitignore, .git/info/exclude, global settings(~/.config/git/ignore) के क्रम में लागू होता है
  • जो फ़ाइलें पहले से tracked हैं, वे .gitignore जोड़ने के बाद भी tracked रहती हैं, और git rm --cached से हटाई जा सकती हैं
  • GitHub, GitLab, Gitea आदि ignored patterns वाली फ़ाइलों को भी बिना warning के commit करने देते हैं
  • GitHub language-specific .gitignore templates official repository में उपलब्ध कराता है

.gitattributes

  • हर फ़ाइल के लिए filter, diff, merge, line endings, language detection आदि नियंत्रित करता है
    • उदाहरण: *.psd filter=lfs, *.png binary, *.sh text eol=lf
  • text line ending normalization करता है, binary diff/merge को disable करता है, और merge=ours conflict की स्थिति में local version बनाए रखता है
  • GitHub Linguist .gitattributes पढ़कर language statistics से exclusion, generated code folding, documentation exclusion आदि करता है
  • हर directory के .gitattributes और .git/info/attributes दोनों को पहचानता है

.lfsconfig

  • Git LFS settings को repository के साथ साझा करता है
    • LFS server URL, transfer retry count जैसी settings की जा सकती हैं
    • उदाहरण: 
      [lfs]
    url = https://lfs.example.com/repo
[lfs "transfer"]
    maxretries = 3
  • .gitattributes में LFS से process होने वाली फ़ाइलें तय होती हैं, और .lfsconfig server location जैसी detailed settings संभालता है
  • मौजूदा committed फ़ाइलों को LFS में ले जाने के लिए git lfs migrate command चाहिए

.gitmodules

  • submodule configuration information को स्टोर करता है
    • इसमें हर module का path, URL, branch information शामिल होती है
    • उदाहरण: 
      [submodule "vendor/lib"]
    path = vendor/lib
    url = https://github.com/example/lib.git
    branch = main
  • git submodule add पर बनता है और git submodule update के समय संदर्भित होता है
  • git clone करते समय submodules अपने-आप नहीं आते; --recurse-submodules option चाहिए
  • version range tracking का समर्थन नहीं करता, और nested .git directories बनने जैसी कमियाँ हैं

.mailmap

  • author name और email को एकीकृत रूप से प्रबंधित करता है
    • उदाहरण: 
      Jane Developer <[email protected]> <[email protected]>
  • git log, git shortlog, git blame आदि में unified नाम से दिखाता है
  • GitHub का contributors graph mailmap को reflect नहीं करता
  • location को .mailmap या mailmap.file setting से तय किया जा सकता है

.git-blame-ignore-revs

  • git blame में ignore किए जाने वाले commits की सूची निर्दिष्ट करता है
    • formatter चलाना, lint लागू करना जैसी अर्थहीन changes को बाहर रखता है
    • उदाहरण: 
      # Ran prettier on entire codebase
a1b2c3d4e5f6g7h8i9j0...
  • git config blame.ignoreRevsFile .git-blame-ignore-revs से enable किया जाता है
  • GitHub, GitLab(15.4+), Gitea इसे अपने-आप पहचानते हैं
  • फ़ाइल न होने पर error आ सकता है, इसलिए empty file बनाए रखना recommended है

.gitmessage

  • commit message template को परिभाषित करता है
    • उदाहरण: 
      # <type>: <subject>
#
# Types: feat, fix, docs, style, refactor, test, chore
  • git config commit.template .gitmessage से setting करनी होती है
  • clone के बाद manual setup चाहिए होता है, और कुछ teams husky आदि से इसे automate करती हैं
  • विकल्प के तौर पर commit-msg hook या prepare-commit-msg hook इस्तेमाल किए जा सकते हैं

Platform-specific extension folders

  • GitHub, GitLab, Gitea, Forgejo, Bitbucket आदि अपने अलग configuration folders इस्तेमाल करते हैं
    • .github/, .gitlab/, .gitea/, .forgejo/, .bitbucket/
  • इनमें CI/CD workflows, issue·PR templates, CODEOWNERS files आदि शामिल होते हैं
  • Forgejo .forgejo/ → .gitea/ → .github/, और Gitea .gitea/ → .github/ क्रम में fallback करता है
  • SourceHut .build.yml या .builds/*.yml इस्तेमाल करता है

अन्य प्रचलित फ़ाइलें

  • .gitkeep: Git empty directories को track नहीं करता, इसलिए directory बनाए रखने के लिए dummy file के रूप में इस्तेमाल होती है
  • .gitconfig: project-specific Git settings का उदाहरण दे सकती है, लेकिन अपने-आप load नहीं होती
  • .gitsigners: GPG/SSH signing keys की सूची प्रबंधित करती है, gpg.ssh.allowedSignersFile से specify किया जा सकता है
  • .gitreview: Gerrit code review server की settings file
    • उदाहरण: 
      [gerrit]
host=review.opendev.org
port=29418
project=openstack/nova.git
defaultbranch=master
  • .gitlint: commit message linting rules को परिभाषित करता है
    • उदाहरण: 
      [general]
ignore=body-is-missing
[title-max-length]
line-length=72
  • .jj/: Git-compatible VCS Jujutsu की state directory, जो .git/ के साथ मौजूद रह सकती है

Git से आगे का dotfile ecosystem

  • .editorconfig: अलग-अलग editors के बीच consistent code style बनाए रखता है
    • indentation, line endings, encoding, trailing whitespace removal आदि को परिभाषित करता है
    • VS Code, Vim, Emacs जैसे प्रमुख editors इसका support करते हैं
  • .ruby-version, .node-version, .python-version: language version management tools(rbenv, nodenv, pyenv आदि) इन्हें पढ़कर अपने-आप switch करते हैं
  • .tool-versions: asdf की multi-language version management file
  • .dockerignore: Docker build के दौरान exclude की जाने वाली फ़ाइलों की सूची तय करता है
    • .gitignore जैसा ही pattern syntax इस्तेमाल करता है, build speed बढ़ाता है और secrets को बाहर रखता है

Git integration tools बनाते समय ध्यान देने योग्य बातें

  • Git repositories को संभालने वाले tools को इन फ़ाइलों को ज़रूर पहचानना चाहिए
    • .gitignore: file traversal के दौरान ignore patterns लागू करना
    • .gitattributes: binary और generated files में अंतर करना
    • .mailmap: author information को unified रूप में दिखाना
    • .gitmodules: submodule handling
  • Git config file format [section "subsection"] key = value संरचना का होता है, और इसे git config command से पढ़ा-लिखा जा सकता है
  • ज़्यादातर languages की Git libraries इस format को parse करने की क्षमता देती हैं

संबंधित पढ़ाई

2 टिप्पणियां

 
wedding 2026-02-24

gitmessage के बारे में नहीं पता था, इसे इस्तेमाल करके देखना पड़ेगा
 
GN⁺ 2026-02-24
Hacker News की टिप्पणियाँ
  • कहा गया था कि GitHub, GitLab, Gitea सभी .gitignore का सम्मान करते हैं और web UI में ignored files नहीं दिखाते, लेकिन यह गलत व्याख्या लगती है
    असल में वे इसलिए नहीं दिखते क्योंकि वे repository में शामिल ही नहीं होते। अगर कोई फ़ाइल पहले से commit हो चुकी है, तो मेरा मानना है कि उसे दिखना चाहिए
    • ऐसा नहीं है। किसी पहले से push की गई फ़ाइल को बाद में .gitignore में जोड़ने पर भी वह UI में दिखती रहती है। क्योंकि वह अब भी repo का हिस्सा है
      इसके उलट, शुरू से ignored फ़ाइल को ज़बरदस्ती commit करना भी संभव है, लेकिन उसके लिए थोड़ा ट्रिक चाहिए
    • सही है, मूल टिप्पणी गलत है। .gitignore सिर्फ यह तय करता है कि untracked files को छिपाना है या नहीं। चाहें तो ignored files को भी commit किया जा सकता है
    • लगता है showinwebui=(true|false) जैसा कोई option होना अच्छा रहेगा 😄
    • मुझे लगा यह गलती किसी इंसान ने खुद लिखी ही नहीं हो सकती, इसलिए मैंने वहीं पढ़ना बंद कर दिया
  • मैं .git/info/exclude पर ज़ोर देना चाहूँगा। यह एक local-only gitignore है, यानी सिर्फ मेरे लिए सेटिंग
    उदाहरण के लिए, जब bug जाँचते समय कोई temporary file बनानी हो और branch बदलने पर भी उसे वहीं छोड़ना हो, तब यह उपयोगी है
    मैं नीचे जैसा shell alias बनाकर इस्तेमाल करता हूँ 
    git-ignore-local () {
  echo "$1" >> .git/info/exclude
}
    इससे git-ignore-local myfile.ext चलाकर आसानी से जोड़ सकते हैं
    • मैंने इसका थोड़ा और जादुई version बनाया है ताकि root directory में न होने पर भी काम करे
      MacOS में सिर्फ readlink वाला हिस्सा बदलना होगा 
      git-ignore-local () {
  root=$(git rev-parse --show-toplevel)
  path=$(readlink -f "$1")
  relpath=$(relpath -m --relative-to="$root" "$path")
  echo "$relpath" >> "${root}.git/info/exclude"
}
      अगर इस function को PATH में git-ignore-local के रूप में register कर दें, तो इसे git ignore-local की तरह इस्तेमाल किया जा सकता है
    • .git/info/exclude का ज़िक्र .gitignore के description के पहले हिस्से में भी है
    • मुझे this feature के बारे में पहली बार पता चला। मेरे project में ऐसे छोटे temporary files की वजह से PR उलझ जाते थे, शायद इससे समस्या हल हो जाएगी
  • अगर .gitattributes में /test export-ignore जोड़ दें, तो production server पर deploy करते समय test files को बाहर रखा जा सकता है
    Capistrano जैसे deployment tools जब git export इस्तेमाल करते हैं, तो यह अपने-आप लागू हो जाता है और test files server पर नहीं जातीं
    development के दौरान असर डाले बिना disk space भी बचता है
    • अच्छा feature है, लेकिन लगता है ज़्यादातर लोग git archive को ही ठीक से नहीं जानते
      मैंने basic CI tools में भी इसे लगभग इस्तेमाल होते नहीं देखा। Capistrano इसका उपयोग करता है, यह पहला उदाहरण मैंने यहीं जाना
      वैसे export-subst option इस्तेमाल करें तो git describe जैसी जानकारी सीधे file के अंदर भी डाली जा सकती है
  • jj इस्तेमाल करते समय मैं .jj folder को repo और सभी git operations से पूरी तरह बाहर रखना चाहता था
    यहाँ तक कि git clean -xdf से भी वह delete न हो। अभी के लिए मैंने अस्थायी रूप से git clean -e .jj alias से काम चलाया है
    • .git/info/exclude इस्तेमाल कर सकते हैं
  • GitHub का contributor graph .mailmap को support नहीं करता
    इससे जुड़ी चर्चा GitHub Community Discussion में है
  • मुझे package-lock.json merge=ours setting खतरनाक लगती है
    क्योंकि merge या rebase के समय ours/theirs का मतलब अस्पष्ट हो सकता है
    ऐसी setting का मतलब सिर्फ automated merge tools (जैसे git-annex branch) में बनता है
    संदर्भ: ours/theirs का अर्थ, git-annex की आंतरिक संरचना
  • .git-blame-ignore-revs अच्छा feature है, लेकिन इसे “अन्य conventions” section में होना चाहिए
    अगर git client में इसे configure न किया जाए, तो जिस repository में यह file नहीं है वहाँ git blame fail हो जाता है
    • git 2.52 से (:optional) option इस्तेमाल करके file न होने पर भी error से बचा जा सकता है
      इसकी जानकारी Stack Overflow उत्तर में है
  • कुल मिलाकर यह अच्छी तरह से व्यवस्थित list लगी
    लेकिन यह अफ़सोस की बात है कि सभी tools .mailmap को support नहीं करते। उदाहरण के लिए IntelliJ में इससे जुड़ा feature अभी भी bug/feature request की स्थिति में है
    और .git-blame-ignore-revs सिर्फ एक convention है, यह अपने-आप काम नहीं करता; इसे अलग से set करना पड़ता है
  • थोड़ा अलग विषय है, लेकिन मुझे हाल ही में पता चला कि VS Code .ignore file को भी पहचानता है
    मुझे लगता था कि सिर्फ .gitignore ही लागू होता है, लेकिन .ignore में ripgrep setting बदलने पर search results बदल गए। बाद में समझ आया कि यह काफ़ी तर्कसंगत behavior था
  • इस लेख के लेखक ने forge-specific repository folders (एक तरह के “magic folders”) पर follow-up post भी लिखी है
    लिंक: nesbitt.io लेख