Is it a good idea to use git for configuration file version controlling?

I use Gentoo Linux and it has rather complex configuration. My question is it wise to use git for version controlling my config files?

I have some git repos in my home, my guess if I put /home/** to my .gitignore they will not cause problems.

Clarification update:

Is it a wise method to use git to version control my system level configuration files in the "/" root directory?

Solution 1:

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:

1. “saving uncommitted changes in /etc prior to yum run”
2. “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

Solution 2:

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.

Solution 3:

I also use git to store and maintain my dotfiles, but in a git bare repository. A detailed guide can be found here. I'm using two repositories, one for my users dotfiles named myconf and one for root's dotfiles named rootconf.

Additionally you can use both configurations on many machines, different Linux Distributions or Virtual Machines: Just create a new branch for a distinct configuration. Then you avoid mixing up code in the same file (e.g. .bash_alias): No annoying if's to check the current machine any more; nore no links needed!

Solution 4:

I also think that Git is a good choice for managing config files. I use a repository for my personal dotfiles in $HOME with symbolic links which point to the working copy of the repository. Differences between hosts can be managed with Git branches. I use common branches for a set of machines (for example linux) and child branches for concrete host machines (for example arch). However, keeping your symlinks and branches up to date is now an extra task. Therefore, I have written a small tool (config-update) which (re)creates symlinks if necessary and automatically merges branches into dependent child branches. Perhaps it is of use for anyone.