Die kurze Antwort auf Ihre Frage lautet Ja .
Ich würde ohne zu zögern Git (oder jede andere Versionskontrollsoftware) empfehlen, um Konfigurationsdateien im Auge zu behalten. Seitdem bin ich produktiver (insbesondere bei der Konfiguration neuer Installationen) und habe mehr Vertrauen in meine Konfigurationsdateien. Mit der Versionskontrolle habe ich eine Aufzeichnung von was Änderungen vorgenommen wurden und die Commit-Nachricht den Grund warum enthält die Änderung wurde vorgenommen. Wenn eine Änderung unbeabsichtigte Nebenwirkungen hat, kann ich das Protokoll/den Verlauf leicht überprüfen, um zu sehen, welche Änderung die Auswirkungen verursacht hat.
Ich persönlich wäre vorsichtig, alle Dateien unter dem / zu verfolgen Wurzelverzeichnis. Die Liste der zu ignorierenden Pfade könnte umfangreich und unübersichtlich werden. Ich ziehe es vor, jeden logischen Satz von Dateien in seinem eigenen Repository aufzubewahren.
Ich benutze Git manuell, um meine persönlichen zu verfolgen Konfigurations-/Startdateien, z. B. Vim-Konfiguration, Bash-Funktionen, Aliase usw. – ähnlich dem Ansatz, der in How to track $HOME with git aufgeführt ist. Ich bewahre jeden Dateisatz in seinem eigenen Repository auf und verwende symbolische Links zum Home-Verzeichnis.
Für System Konfigurationsdateien verwende ich Git mit Etckeeper, um die Dateien in meinem /etc zu verfolgen Verzeichnis.
Nachteile
Ein Problem, bei dem Sie vorsichtig sein sollten, ist, wenn die verfolgten Dateien feste Links enthalten . Wenn Git zum Auschecken von Dateien oder zum anderweitigen Ändern des Arbeitsbaums verwendet wird, wird die Verknüpfung von Dateien aufgehoben und anschließend neu erstellt. Siehe Git, Dotfiles und Hardlinks für eine ausführlichere Erklärung.
Etckeeper
Etckeeper kann verwendet werden, um einen vollständigen Verlauf der an /etc vorgenommenen Änderungen zu führen. Es verfolgt Dateimetadaten, die Revisionskontrollsysteme normalerweise nicht unterstützen, aber das ist wichtig für /etc , wie etwa die Berechtigungen von /etc/shadow .
Es hängt sich in Paketmanager wie apt und yum ein und führt (in seiner Standardkonfiguration) die Vor- und Nachinstallation aus, sodass sich alle Änderungen in /etc ändern werden verfolgt.
Wenn ein Paket installiert oder entfernt wird, werden alle nicht festgeschriebenen Änderungen in /etc vor der Paketoperation festgeschrieben, sodass es zwei Festschreibungen gibt:
- „Nicht festgeschriebene Änderungen in /etc vor dem Ausführen von yum speichern“
- „Änderungen in /etc nach yum-Lauf übernehmen“
Ich habe es mit Debian- und Red Hat-basierten Distributionen verwendet und weiß, dass es die Arch-Paketverwaltung unterstützt. Ich kann nicht sagen, wie viel Automatisierung es zu einem Gentoo-System hinzufügen würde, aber ein Paket dafür ist verfügbar.
Es unterstützt auch das Pushen der Konfigurationsdateien in ein Remote-Repository (der natürlich privat sein sollte).
Konfiguration
Nach der Installation des Pakets müssen Sie es möglicherweise konfigurieren (/etc/etckeeper/etckeeper.conf ), z. B. wird auf Ubuntu-Systemen das Standard-Versionskontrollsystem von Git auf Bazaar geändert. Sie können auch die täglichen Auto-Commits deaktivieren .
Tägliche Autocommits
Änderungen können automatisch durch einen täglichen Cronjob übernommen werden . Dies kann ärgerlich sein, da das Repository mit mehreren automatisierten Commit-Nachrichten überladen werden kann.
Ich entkommentiere die entsprechende Zeile in /etc/etckeeper/etckeeper.conf :
sed -i '/AVOID_DAILY_AUTOCOMMITS/s|^#* *||' /etc/etckeeper/etckeeper.conf
Ignoriere bestimmte Dateien
Bearbeiten Sie /etc/.gitignore um Dateien anzugeben, die nicht nachverfolgt werden sollen.
Erster Lauf
Führen Sie nach der Konfiguration die folgenden Befehle aus:
sudo etckeeper init
sudo etckeeper commit "Initial commit"
Wenn Ihr aktuelles Verzeichnis etc ist , können Sie reguläres git ausführen Befehle, z. B.
sudo git status
sudo git log
Ich verwende git, um bestimmte Bereiche meines Home-Verzeichnisses zu verfolgen. Persönlich würde ich nicht den Weg gehen, das Root-Verzeichnis zu verfolgen, aber ich muss sagen, dass ich Ihren Ehrgeiz bewundere. :)
Vielleicht kann Ihnen diese Sammlung von Erfahrungen eine bessere Vorstellung davon vermitteln, worauf Sie sich einlassen könnten:
Auswirkungen der Initialisierung des Git-Repositorys auf das Linux-Root-Verzeichnis 3:)
Entschuldigung für eine "Antwort", anstatt den Link einfach in einen Kommentar zu werfen; jedoch nicht genug Repräsentant, wollte mich aber einmischen.
Bearbeiten
Wow! Sehr schöne Antwort von @AnthonyGeoghegan. Ich glaube, das ist nicht so ein Kampf, wie ich es mir ursprünglich vorgestellt hatte.