Is it a good idea to use git for configuration file version controlling?
The short answer to your question is Yes.
I wouldn’t hesitate to recommend Git (or any other version control software) to keep track of configuration files. Since doing so, I’ve been more productive (particularly for configuring new installations) and have greater confidence in my configuration files. With version control, I have a record of what changes were made and the commit message provides the reason why the change was made. If a change has unintended side effects, I can easily review the log/history to see what change caused the effects.
Personally, I’d be wary of tracking all files under the / root directory. The list of paths to ignore could become large and unwieldy. I prefer to keep each logical set of files in their own repository.
I manually use Git to keep track of my personal configuration / start-up files, e.g., Vim configuration, Bash functions, aliases, etc. – similar to the approach listed in How to track $HOME with git. I keep each set of files in their own repository and use symbolic links to the home directory.
For system configuration files, I use Git with Etckeeper to keep track of files in my /etc directory.
Drawbacks
One issue to be wary of is if the files being tracked include hard links. When Git is used to check out files or otherwise modify the working tree, it unlinks files and then recreates them. See Git, Dotfiles, and Hardlinks for a fuller explanation.
Etckeeper
Etckeeper can be used to keep a full history of changes made to /etc.
It tracks file metadata that revision control systems do not normally support,
but that is important for /etc, such as the permissions of /etc/shadow.
It hooks into package managers such as apt and yum and (in its default
configuration), runs pre- and post-installation so all changes to /etc are
tracked.
If a package is installed or removed, all uncommitted changes in /etc will be committed before the package operation so that there are two commits:
- “saving uncommitted changes in /etc prior to yum run”
- “committing changes in /etc after yum run”
I’ve used it with Debian and Red Hat-based distributions and I know it supports Arch package management. I can’t say how much automation it would add to a Gentoo system but a package is available for it.
It also supports pushing the configuration files to a remote repository (which should, of course, be private).
Configuration
After installing the package you may need to configure it (/etc/etckeeper/etckeeper.conf), e.g., on Ubuntu systems the default version control system is changed from Git to Bazaar. You may also like to disable the daily auto-commits.
Daily autocommits
Changes can be automatically committed by a daily cron job. This can be annoying as the repository can get cluttered with multiple automated commit messages.
I uncomment the appropriate line in /etc/etckeeper/etckeeper.conf:
sed -i '/AVOID_DAILY_AUTOCOMMITS/s|^#* *||' /etc/etckeeper/etckeeper.conf
Ignore certain files
Edit /etc/.gitignore to specify any files that shouldn’t be tracked.
First run
After configuring, run the following commands:
sudo etckeeper init
sudo etckeeper commit "Initial commit"
If your current directory is etc, you can run regular git commands, e.g.,
sudo git status
sudo git log
I use git to track specific areas of my home directory. Personally, I would not journey down the path of tracking the root directory, but I must say that I admire your ambition. :)
Perhaps this collection of experiences could provide you with a better idea of what you might be getting into:
effects of initializing git repository on linux root directory 3:)
Apologies for an "answer", instead of just throwing the link in a comment; however, not enough rep, but wished to chime in.
Edit
Wow! Very nice answer by @AnthonyGeoghegan. I am believing this is not as much of a struggle as I has originally envisioned it as.