Your dotfiles and you

TL;DR this is an introductory article describing what dotfiles are and why you should treat them as a life long software project.

Estimated time reading
3 m 22 sec

What's a dotfile anyway?

Using the words of Zach Holman,

"Dotfiles" are the funky little files in your *nix-based home directory that allow you to customize your nerdery: change how your prompt looks, set up your $PATH, adjust settings for Ruby's IRB, completely change everything about Vim, and about a billion and a half other things. They're fun.

We're usually talking about files like .bashrc, .zshrc, .gitconfig, .vimrc and the .vim/ directory, .inputrc, .ssh/config, .tmux.conf, ... but really every configuration file that is being read during initialization is a dotfile (also called rc files). Sublime Text has its set of dotfiles, for example.

Ok, so what?

The assumption that I'm making in this article is that there is value in editing your dotfiles, altering the default behaviour of the programs you use in your day to day basis so that you can be more productive.

After all if you are reading this article you might very well be a developer or a technology professional of some kind, and what we do on a daily basis is providing value by automating things, streamlining processes, making things more efficient.

So customizing your dotfiles really is applying to your development workflow the same principle that you normally apply with your customer/product.

And what are you proposing?

What I'm proposing is nothing new, just an approach that many developers have already started embracing. The approach is to put your dotfiles under version control (git) and treat them as a life long software project.
Once you accept this idea, publishing your dotfiles on a publicly available repository is really the natural evolution.

Why should I do that?

Github itself has published a page describing why you should start your own dotfiles project.
I think the most important reason is that you have a place that you can call home, a central place that contains all your customizations.

How many times have you logged into a remote machine and found out the environment (bash aliases, vim configuration) is different from the one on your personal machine? Having a publicly available project makes it possible to easily copy your dotfiles on that machine.

Here's another case: how many times have you stumbled upon one of those cool git aliases and wanted to start using them? If you have a git repository dedicated to just that you can have some sort of accountability and history. You can also leverage the usual benefits of having a project under version control: you have freedom and confidence of trying out new things and see if they work out (i.e. if you really use them or not). If they don't you have a history and you can revert the change. It's like having a MVP but for your workflow.

Can you show me how a dotfiles repo looks like?

I personally like to do things by hand and my repository is set up so that files like ~/.gitconfig are only a symlink to the real files in my repository. An installs.sh bash script takes care of setting that up idempotently.
On the github page mentioned previously you can find "meta" projects that help you bootstrapping your repository but really, the most important thing is starting out.

It really can be as simple as:

bash $ cd ~ && git init dotfiles $ mv .bashrc dotfiles/_bashrc $ ln -s ~/dotfiles/_bashrc ~/.bashrc $ cd dotfiles && git -am 'adding initial .bashrc'

Once you start, you will be hooked and you will start to see and treat things differently, I promise.

This article is really meant to be an introduction, I have been brief and not very technical but I will post more about the same subject in the near future.

Latest posts from Giuseppe Rota

Keep in touch

Enter your email address below to receive all our latest articles and announcements via email.