There are a few unique challenges when it comes to putting your dot files under source control. The naïve solution — just creating a git repository in your home directory — has pitfalls. What are they, and how can we do better?


Why not just create a git repo in your home directory?

  1. It’s hard to control what’s in and what’s out.
  2. Your home directory most likely has a ton of other stuff in it that you don’t want to add to your repo. One approach is to make a funky .gitignore that ignores everything but the dot files, which can be done, but then there’s another issue…
  3. A .gitignore in your home directory can interfere with git repos in sub folders
  4. In my experience, if I put a .gitignore in my home directory, and then have a git repository in ~/myrepo , git commands run in that subdirectory seem to ‘see’ the .gitignore one level up… and this can cause strange behaviour.

What to do instead

The simplest approach I have come across is:

  1. Create a git repository called dotfiles where you’d normally store your git repos. (For me, this is ~/git/dotfiles ).
  2. Move the files you want to track over to the new repository, and symlink them from their original locations. You can move them to a name without the leading dot if you wish.

Example

In this example we’ll set up the repository and make an initial commit containing our .bashrc.

#git #bash #software-development #dotfiles

Version controlling your dot files
1.35 GEEK