Version Control Your Configuration / Dot Files
I’ve been meaning to write this post forever, but once I started doing what I suggest here it seemed so obvious that I have trouble remembering what life was like before I did it. Once you’ve been working in a terminal for long enough, you realize how much more productive you can be with your aliases, scripts, prompts, plugins and other configurations setup the way you like. This becomes especially apparent when you either work on someone else’s machine, or something happens and you have to rebuild yours and you realize just how slow you are in comparison.
How do you avoid this slowdown and prevent loss of all those great hacks and configurations you’ve built up? Version control all the files that enable your productive environment. Here’s my repo for all those files.
I’ve got bash, zsh, vim, screen, tmux, irb, tmux, irssi, ruby scripts, puppet scripts and more in this git repository. I spend a lot time working remotely via ssh or on virtual machines on my development box, so it’s important not only that I have these files available, but I also have a fast way to get all these files in place quickly. I also want changes that I make to these files to be easy to commit back to my repository. To accomplish this, I make all these files symlinks to the files in my repository so that if I edit ~/.bashrc with my great new alias that saves all sorts of typing, it’s actually editing the .bashrc in my git respository. Then I have a little perl script that when run puts all these symlinks in place for my automatically and backup up any files I’m moving out of the way to create the links, just in case.
Now whenever I end up in a new environment on the terminal, I can get all my productivity in place with a few simple commands from the home directory.
git clone git://github.com/mmrobins/config-files.git
Now vim has my plugins and configuration, bash has my prompt, if GNU Screen or tmux are available they’re how I like them, my aliases work, etc. There’s always going to be tweaks necessary for this to work cross platform and on different machines with different privileges, but since committing those changes back to the git repo is so easy, it become a natural part of my workflow to have these incremental improvements to my work environment available everywhere I work.