Gits magische Dateien

 (nesbitt.io)
45 Punkte von GN⁺ 2026-02-24 | Noch keine Kommentare. | Auf WhatsApp teilen
  • Git steuert sein Verhalten über bestimmte Dateien im Repository; diese sind keine Konfigurationen innerhalb von .git/, sondern versionierte Dateien, die zusammen mit dem Code mitwandern
  • .gitignore, .gitattributes, .lfsconfig, .gitmodules, .mailmap usw. sind jeweils für das Ausschließen von Dateien aus dem Tracking, die Definition von Attributen, LFS-Konfiguration, Submodul-Verwaltung und die Zusammenführung von Autoreninformationen zuständig
  • .git-blame-ignore-revs und .gitmessage bieten das Ignorieren von Code-Formatierungs-Commits bzw. Vorlagen für Commit-Nachrichten und verbessern so die Qualität der Zusammenarbeit
  • GitHub, GitLab, Gitea usw. erweitern Funktionen wie CI/CD und die Zuweisung von Reviewern über plattformspezifische Konfigurationsordner wie .github/, .gitlab/, .gitea/
  • Diese Struktur reicht über Git hinaus auch in EditorConfig, Docker und Tools zur Sprachversionsverwaltung hinein und bildet so ein Ökosystem automatischer Konfiguration auf Basis von Dotfiles

Wichtige magische Dateien von Git

  • Git erkennt verschiedene spezielle Dateien wie .gitignore, .gitattributes, .lfsconfig, .gitmodules, .mailmap, um das Verhalten des Repositorys zu steuern
    • Diese Dateien sind keine internen Einstellungen in .git/, sondern versionierte und gemeinsam genutzte Konfigurationsbestandteile, die bei der Zusammenarbeit ein einheitliches Verhalten sicherstellen

.gitignore

  • Definiert Dateimuster, die Git nicht verfolgen soll
    • Unterstützt Wildcards (*.log), Verzeichnisse (dist/) und Negationen (!important.log)
    • Wird in der Reihenfolge .gitignore, .git/info/exclude, globale Konfiguration (~/.config/git/ignore) angewendet
  • Bereits verfolgte Dateien werden auch nach dem Hinzufügen zu .gitignore weiter verfolgt und können mit git rm --cached entfernt werden
  • GitHub, GitLab, Gitea usw. erlauben es, Dateien, die zu ignorierten Mustern passen, trotzdem ohne Warnung zu committen
  • GitHub stellt sprachspezifische .gitignore-Vorlagen im offiziellen Repository bereit

.gitattributes

  • Steuert pro Datei Filter, Diff, Merge, Zeilenenden und Spracherkennung
    • Zum Beispiel: *.psd filter=lfs, *.png binary, *.sh text eol=lf
  • text normalisiert Zeilenenden, binary deaktiviert Diff/Merge, merge=ours behält bei Konflikten die lokale Version bei
  • GitHub Linguist liest .gitattributes, um Sprachstatistiken auszuschließen, generierten Code einzuklappen und Dokumentation auszunehmen
  • Erkennt außerdem .gitattributes pro Verzeichnis sowie .git/info/attributes

.lfsconfig

  • Speichert Git-LFS-Konfiguration gemeinsam mit dem Repository
    • Konfigurierbar sind z. B. die URL des LFS-Servers und die Anzahl von Transfer-Wiederholungen
    • Beispiel: 
      [lfs]
    url = https://lfs.example.com/repo
[lfs "transfer"]
    maxretries = 3
  • In .gitattributes werden die per LFS zu behandelnden Dateien festgelegt, während .lfsconfig Details wie den Serverstandort übernimmt
  • Um Dateien aus bestehenden Commits nach LFS zu migrieren, ist der Befehl git lfs migrate erforderlich

.gitmodules

  • Speichert Konfigurationsinformationen für Submodule
  • Wird bei git submodule add erstellt und bei git submodule update referenziert
  • Bei git clone werden Submodule nicht automatisch geholt; dafür ist die Option --recurse-submodules nötig
  • Nachteile sind unter anderem fehlendes Tracking von Versionsbereichen und die Erzeugung verschachtelter .git-Verzeichnisse

.mailmap

  • Dient der zentralen Zusammenführung von Autorennamen und E-Mail-Adressen
    • Beispiel: 
      Jane Developer <[email protected]> <[email protected]>
  • In git log, git shortlog, git blame usw. werden die zusammengeführten Namen angezeigt
  • Das Beitragsdiagramm von GitHub berücksichtigt mailmap nicht
  • Der Speicherort kann über .mailmap oder die Einstellung mailmap.file festgelegt werden

.git-blame-ignore-revs

  • Legt eine Liste von Commits fest, die git blame ignorieren soll
    • Schließt bedeutungsarme Änderungen wie Formatter-Läufe oder angewendete Lint-Regeln aus
    • Beispiel: 
      # Ran prettier on entire codebase
a1b2c3d4e5f6g7h8i9j0...
  • Aktivierung mit git config blame.ignoreRevsFile .git-blame-ignore-revs
  • GitHub, GitLab (15.4+) und Gitea erkennen die Datei automatisch
  • Wenn die Datei fehlt, kann es zu Fehlern kommen; daher wird empfohlen, eine leere Datei beizubehalten

.gitmessage

  • Definiert eine Vorlage für Commit-Nachrichten
    • Beispiel: 
      # <type>: <subject>
#
# Types: feat, fix, docs, style, refactor, test, chore
  • Muss mit git config commit.template .gitmessage konfiguriert werden
  • Nach dem Klonen ist eine manuelle Einrichtung nötig; manche Teams automatisieren das mit husky o. Ä.
  • Als Alternativen können commit-msg-Hook oder prepare-commit-msg-Hook verwendet werden

Plattformbezogene Erweiterungsordner

  • GitHub, GitLab, Gitea, Forgejo, Bitbucket usw. verwenden eigene Konfigurationsordner
    • .github/, .gitlab/, .gitea/, .forgejo/, .bitbucket/
  • Sie enthalten CI/CD-Workflows, Vorlagen für Issues und PRs, CODEOWNERS-Dateien usw.
  • Forgejo verwendet Fallbacks in der Reihenfolge .forgejo/ → .gitea/ → .github/, Gitea in der Reihenfolge .gitea/ → .github/
  • SourceHut verwendet .build.yml oder .builds/*.yml

Weitere konventionelle Dateien

  • .gitkeep: Da Git keine leeren Verzeichnisse verfolgt, wird diese Datei als Platzhalter verwendet, um Verzeichnisse beizubehalten
  • .gitconfig: Kann projektbezogene Git-Konfigurationsbeispiele bereitstellen, wird aber nicht automatisch geladen
  • .gitsigners: Verwaltet die Liste von GPG-/SSH-Signaturschlüsseln und kann über gpg.ssh.allowedSignersFile angegeben werden
  • .gitreview: Konfigurationsdatei für den Gerrit-Code-Review-Server
    • Beispiel: 
      [gerrit]
host=review.opendev.org
port=29418
project=openstack/nova.git
defaultbranch=master
  • .gitlint: Definiert Lint-Regeln für Commit-Nachrichten
    • Beispiel: 
      [general]
ignore=body-is-missing
[title-max-length]
line-length=72
  • .jj/: Statusverzeichnis von Jujutsu, einem Git-kompatiblen VCS, das neben .git/ existieren kann

Das Dotfile-Ökosystem über Git hinaus

  • .editorconfig: Sorgt für einen konsistenten Code-Stil über verschiedene Editoren hinweg
    • Definiert Einrückung, Zeilenenden, Kodierung, Entfernen von Leerraum usw.
    • Unterstützt von wichtigen Editoren wie VS Code, Vim und Emacs
  • .ruby-version, .node-version, .python-version: Werden von Tools zur Sprachversionsverwaltung (rbenv, nodenv, pyenv usw.) gelesen und lösen automatische Umschaltung aus
  • .tool-versions: Mehrsprachige Versionsverwaltungsdatei von asdf
  • .dockerignore: Legt fest, welche Dateien beim Docker-Build ausgeschlossen werden
    • Verwendet dieselbe Muster-Syntax wie .gitignore, verbessert die Build-Geschwindigkeit und schließt Geheimnisse aus

Was bei der Entwicklung von Git-integrierten Tools zu beachten ist

  • Tools, die mit Git-Repositories arbeiten, sollten die folgenden Dateien unbedingt erkennen
    • .gitignore: Anwenden von Ignoriermustern bei der Dateisuche
    • .gitattributes: Unterscheidung zwischen Binär- und generierten Dateien
    • .mailmap: Einheitliche Anzeige von Autoreninformationen
    • .gitmodules: Behandlung von Submodulen
  • Das Format von Git-Konfigurationsdateien folgt der Struktur [section "subsection"] key = value und kann mit dem Befehl git config gelesen und geschrieben werden
  • Die meisten Git-Bibliotheken für verschiedene Programmiersprachen bieten Funktionen zum Parsen dieses Formats

Verwandte Beiträge

Noch keine Kommentare.

Noch keine Kommentare.