Welche Dotfiles sollten Sie in Git committen (und welche ignorieren)

Die Verwaltung von Dotfiles über mehrere Rechner hinweg ist ein häufiges Problem für Entwickler. Sie haben Stunden damit verbracht, Ihre Shell-Konfiguration, Editor-Einstellungen und Tool-Präferenzen zu perfektionieren – aber welche Dateien gehören in die Versionskontrolle? Noch wichtiger: Wie synchronisieren Sie diese, ohne sensible Daten offenzulegen oder ein Wartungs-Albtraum zu schaffen?

Dieser Artikel vergleicht die beiden beliebtesten Ansätze zur Dotfiles-Verwaltung – Git Bare Repositories und GNU Stow – und behandelt dabei die kritischen Sicherheitsaspekte, die bestimmen, was committet werden sollte und was nicht.

Was committen: Der Security-First-Ansatz

Bevor Sie eine Verwaltungsmethode wählen, sollten Sie verstehen, was in Ihr Dotfiles-Repository gehört. Die goldene Regel: Committen Sie niemals Secrets.

Sicher zu committen

• Shell-Konfigurationen (.bashrc, .zshrc, .config/fish/)
• Editor-Einstellungen (.vimrc, .config/nvim/)
• Git-Konfiguration (.gitconfig ohne Credentials)
• Terminal-Emulator-Konfigurationen (.alacritty.yml, .config/kitty/)
• Window-Manager-Einstellungen (.config/i3/, .config/sway/)
• Tool-Konfigurationen (.tmux.conf, .config/starship.toml)

Niemals committen

• Private SSH-Schlüssel (~/.ssh/id_*)
• API-Tokens und Credentials
• Datenbank-Verbindungsstrings
• Lizenzschlüssel
• Browser-Cookies oder Session-Daten
• Command-History-Dateien (.bash_history, .zsh_history)

Für Konfigurationsdateien, die öffentliche Einstellungen mit Secrets mischen, verwenden Sie Templating oder trennen Sie die sensiblen Teile in separate Dateien, die lokal bleiben und per Source eingebunden werden.

Git Bare Repository: Die minimalistische Methode

Der Git-Bare-Repository-Ansatz behandelt Ihr Home-Verzeichnis als Working Tree, ohne es mit einem .git-Ordner zu überladen. Diese Methode benötigt keine zusätzlichen Tools – nur Git.

Setup-Prozess

git init --bare $HOME/.dotfiles
alias config='git --git-dir=$HOME/.dotfiles --work-tree=$HOME'
config config --local status.showUntrackedFiles no

Dateien verwalten

config add ~/.vimrc
config commit -m "Add vim configuration"
config push origin main

Vorteile:

• Keine Abhängigkeiten außer Git
• Direkte Versionskontrolle ohne Symlinks
• Funktioniert identisch auf allen Unix-ähnlichen Systemen
• Kein Zwischenspeicherort erforderlich

Nachteile:

• Versehentliches Committen sensibler Dateien leicht möglich
• Erfordert Disziplin bei der Verwendung von .gitignore
• Kann mit anderen Git-Repositories in Unterverzeichnissen interferieren
• Weniger intuitiv für die Organisation modularer Konfigurationen

GNU Stow: Der organisierte Ansatz

GNU Stow verwaltet Dotfiles über Symlinks und hält Ihre tatsächlichen Dateien in einem dedizierten Verzeichnis organisiert, während die erwarteten Pfade in Ihrem Home-Ordner beibehalten werden.

Verzeichnisstruktur

~/.dotfiles/
├── vim/
│   └── .vimrc
├── git/
│   └── .gitconfig
└── shell/
    ├── .bashrc
    └── .zshrc

Deployment

cd ~/.dotfiles
stow vim git shell  # Erstellt Symlinks in ~

Vorteile:

• Klare, modulare Organisation nach Anwendung
• Einfaches selektives Deployment pro Rechner
• Integrierte Konflikterkennung
• Unterstützt paketspezifische Ignore-Dateien (.stow-local-ignore)

Nachteile:

• Erfordert Installation von GNU Stow
• Einige Anwendungen kommen nicht gut mit Symlinks zurecht (systemd, bestimmte Editoren)
• Kann brechen, wenn Anwendungen Symlinks überschreiben
• Zusätzliche Abstraktionsebene zu verstehen

Ihre Konfigurationsverwaltungsstrategie wählen

Ihre Wahl zwischen Git Bare Repository und GNU Stow hängt von Ihren spezifischen Anforderungen ab:

Verwenden Sie Git Bare Repository, wenn:

• Sie keine Abhängigkeiten wünschen
• Ihre Dotfiles relativ einfach sind
• Sie direkte Versionskontrolle bevorzugen
• Sie mit Git-Interna vertraut sind

Verwenden Sie GNU Stow, wenn:

• Sie komplexe, modulare Konfigurationen verwalten
• Sie eine Organisation nach Anwendung benötigen
• Sie unterschiedliche Konfigurationen auf verschiedenen Rechnern deployen
• Sie eine visuelle Verzeichnisstruktur bevorzugen

Best Practices für Entwicklerproduktivität

Unabhängig von Ihrer gewählten Methode sollten Sie diese Best Practices für die Versionskontrolle befolgen:

1. Verwenden Sie .gitignore aggressiv: Beginnen Sie mit * und erlauben Sie Dateien explizit
2. Trennen Sie Öffentliches von Privatem: Führen Sie ein privates Repository für sensible Konfigurationen
3. Dokumentieren Sie Ihr Setup: Fügen Sie Installations- und Deployment-Anleitungen hinzu
4. Testen Sie auf einem frischen System: Überprüfen Sie regelmäßig Ihren Bootstrap-Prozess
5. Verwenden Sie bedingtes Laden: Behandeln Sie OS-spezifische Konfigurationen elegant

Für Team-Umgebungen sollten Sie ein separates „blessed” Konfigurations-Repository mit sinnvollen Standardwerten pflegen und gleichzeitig individuelle Anpassungen durch lokale Overrides ermöglichen.

Fazit

Sowohl Git Bare Repositories als auch GNU Stow lösen das Dotfiles-Verwaltungsproblem effektiv – die Wahl hängt von Ihren Komplexitätsanforderungen und Tool-Präferenzen ab. Der kritische Faktor ist nicht, welche Methode Sie wählen, sondern die strikte Trennung zwischen öffentlichen Konfigurationen und sensiblen Daten aufrechtzuerhalten. Beginnen Sie mit einer Security-First-Denkweise, wählen Sie den Ansatz, der zu Ihrem Workflow passt, und Sie werden eine portable, versionskontrollierte Umgebung haben, die Ihre Entwicklerproduktivität steigert, ohne die Sicherheit zu gefährden.

FAQs

Understand every bug

Uncover frustrations, understand bugs and fix slowdowns like never before with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data. Check our GitHub repo and join the thousands of developers in our community.