Putting Your Dotfiles Under Version Control in 15 Minutes

Last week we explored the joy of dotfiles. Yesterday we looked at why every textsmith should learn Git.

Now it’s time to put those ideas into practice.

One of the best investments you can make in your computing environment is placing your configuration files under version control. Whether you customize your shell, your editor, your terminal, or your window manager, those settings represent hours—often years—of careful refinement.

Git ensures that you never have to start from scratch again.

The good news is that getting started is much easier than most people imagine.

Why Version-Control Your Dotfiles?

A Git repository gives you much more than a backup.

It lets you:

recover from accidental mistakes;
synchronize your settings across multiple computers;
experiment without fear;
remember why you changed something; and
rebuild a new system in minutes instead of hours.

Think of it as giving your computer a memory.

Method 1: The Bare Repository

This is the approach I personally use. After experimenting with different approaches over the years, I settled on the bare repository workflow because it keeps my home directory intact without relying on symbolic links.

Instead of storing your configuration files inside a separate repository, your home directory becomes Git’s working tree while Git stores its own metadata in a hidden bare repository.

Begin by creating the repository:

git init --bare $HOME/.dotfiles

Then create a convenient alias:

alias config='/usr/bin/git --git-dir=$HOME/.dotfiles --work-tree=$HOME'

Now you can manage your configuration files like any other Git project:

config add .vimrc
config add .bashrc
config commit -m "Initial dotfiles"

Finally, tell Git to ignore the thousands of files in your home directory that are not part of your repository:

config config --local status.showUntrackedFiles no

From this point onward, your daily workflow is simply:

config status
config add ...
config commit -m "Update shell configuration"

No symbolic links.

No moving files.

Everything stays exactly where your applications expect it.

Method 2: GNU Stow

GNU Stow follows a different philosophy.

Instead of making your home directory the repository, you create a dedicated directory for your configuration files:

~/dotfiles/
    bash/
        .bashrc
    vim/
        .vimrc
    git/
        .gitconfig

Each application gets its own folder.

Once you’ve arranged your files, installing them is as simple as:

stow bash
stow vim
stow git

Stow creates symbolic links in your home directory that point back to the files stored in your repository.

Applications continue reading ~/.bashrc or ~/.vimrc exactly as before, but the real files are neatly organized inside your dotfiles repository.

If you ever want to remove a package, Stow can cleanly remove only the links it created.

Which Approach Should You Choose?

Both methods are widely used, and each reflects a slightly different Unix philosophy.

Bare Repository	GNU Stow
Git works directly in your home directory.	Git works in a dedicated `dotfiles` directory.
No symbolic links required.	Uses symbolic links automatically.
Minimal setup once configured.	Files remain neatly organized by application.
Requires a Git alias.	Uses ordinary Git commands.
Ideal if you like a lightweight workflow.	Ideal if you prefer explicit organization.

There is no universal winner.

Some experienced Linux users have relied on the bare repository approach for years because of its simplicity.

Others prefer GNU Stow because it keeps everything beautifully organized while automating symbolic links.

Choose the workflow that feels most natural to you.

The Real Goal

The important lesson isn’t whether you use a bare repository or GNU Stow.

The important lesson is that your configuration deserves the same care as your writing.

Every adjustment to your editor, every shell alias, every keyboard shortcut, and every terminal customization represents knowledge you’ve accumulated over time.

That knowledge is worth preserving.

Git simply gives it a safe home.

The Textsmith’s Take

Your documents tell the story of what you write.

Your dotfiles tell the story of how you work.

Version-control both, and you’ll never have to rediscover your own craftsmanship.