How do you manage your dotfiles across multiple and/or new developer machines?

Hey All! I’m curious to hear the gritty details about how you synchronize your dotfiles (e.g. .bash_profile, .gitconfig) between multiple dev machines (e.g. your desktop and laptop) and/or to help simplify setting up new machines (e.g. a shiny new MacBook 💻).

Do you store them in a public or private GitHub repo? DropBox? Somewhere else? Once cloned to the target machine, do you install the dotfiles...

1. Manually (e.g. moving files around, running a series of commands)
2. By running a custom shell script stored alongside your config files
3. Using an automation tool, such as Ansible or Puppet
4. Using a “dotfile manager” such as GNU Stow, Dotbot or Homesick

If you’ve already written a blog post about your setup, feel free to link it. Otherwise, I’d love to hear what has been working well for you, and any pro tips you can share. There are a ton of options here, and so I’m very interested to learn more about what folks are actually doing in practice 🙌

Comments

[Joshua Mervine]

I manage mine, as I’m sure many do, via a Github repo — as well as my vimrc. They both include make based installers for easy installation, as well as (very old) Dockerfiles for quick mucking container.

The dotfiles repo loads a .localrc to include things I don’t wish to share. Mostly very work specific aliases and functions.

Admittedly, I don’t push nearly often enough, nor do I clean up the files within with any kind of diligence.

[Jonathan Carter]

Very cool! I really like the “.localrc” idea. That seems like a great solution for keeping a public dotfiles repo for most of your settings, while being able to keep some things private 👍

[Jonathan Carter]

For those that are interested, I found an old HackerNews thread, and Reddit Survey that have a ton of valuable perspectives. This article also provides a really nice explanation of the general practice that many people seem to be taking: store dotfiles in GitHub, and then install them via a simple script that symlinks files and runs any additional init logic.

Also, I’m porting some helpful links that folks have shared on Twitter:

1. Managing Dotfiles with Stow
2. Managing your dotfiles
3. Dotfiles Home Configuration

[Kaleb M]

I typically keep them all in the GitHub, luckily none of mine have any secrets or anything like that.

[Jonathan Carter]

After you clone the repo on to your machine, how to you install them (e.g. symlinking files, etc.)? Do you have something like an “install.sh” script in the repo that you run?

[Dane Hillard]

That's exactly what I do!

[Jonathan Carter]

Great, thanks for confirming 👍

[Kaleb M]

That would be clutch! I typically just copy and paste if there are any updates, many changes outside of the base set ups are specific to the laptop for work vs personal !

[Joshua Mervine]

Here’s my very personalize Makefile for installing which perhaps could be adapted.

github.com/jmervine/zshrc/blob/mas...

Which, when looking over just now for the first in quite a while, needs some clean up.

[Dane Hillard]

Hmmmm I like this enough that I might do it too. Right now I'm symlinking everything in a bash script which works well, but the uninstall would have to be manual at the moment. I like that make would kind of supervise all of that.

[Corey Alexander]

I put all my dotfiles that I want to share in a public repo that I host on Github

coreyja / dotfiles

My dotfile Repo

Coreyja's dotfiles

My dotfiles!

This started out as a fork from github.com/mathiasbynens/dotfiles but diverged enough that I cut the fork tie at some point.

Notably I run my dotfiles where my homedir is under git, so not aliasing/copying is required or provided here

Here are some blog posts I've written about my dotfiles:

• coreyja.com/dotfiles-git-in-home-dir/
• coreyja.com/upgrading-to-brew-2/
• coreyja.com/dotfiles-december-2018/

Setup

Doing setup on a new machine so writing some documentation

Using brew installed bash

To update the shell we need to do two things both need root perms:

• Add $(brew prefix)/bin/bash to /etc/shells so its an allowed shell
• Run sudo chsh -s "$(brew prefix)/bin/bash" to set it as the default shell for the user

View on GitHub

I do something that I think is somewhat unconventional but I really like it! And that is keep my actual home directory under version control. To accomplish this my .gitignore starts with * so that it ignores everything. Then I go in an specifically include files like !file.txt.

This means I don't have to deal with any symlinks or scripts when I pull updates. I also can edit the actual 'live' files and then commit those same files, which makes sharing between machines painless! I've written a few blog posts about my dotfiles!

Dotfiles - January 2018

Corey Alexander ・ Oct 27 '18 ・ 6 min read

#dotfiles #bash #tmux #vim

This second one discusses some recent change to my dotfiles around Homebrew 2

Setting up new Laptop and Upgrading to Homebrew 2

Corey Alexander ・ Apr 19 '19 ・ 4 min read

#macos #homebrew #bash #ruby

[Jonathan Carter]

It definitely seems like many of the “dot file managers” are simply working around the fact that folks don’t want to make their home directory a Git repo. Have you run into any downsides with this solution? It certainly seems really simple.

[Corey Alexander]

Not any huge ones, but there are definitely some interesting side effects.

One if that I am always in a git repo now basically, so my bash indicator of if I'm in a git branch is slightly less meaningful
Two some tools (ex: ripgrep) use your .gitignore file as a generic ignore file when searching, so this needs to be worked around. I accomplish this my using something like rg --no-ignore --glob "!.git/*". I find I don't actually run into this too often, as usually I am running rg from within a different project directory, where it's local .gitignore is used so this isn't an issue.

Besides that everything works as expected! I've been doing it for a few years now and really enjoy the setup!

[the_savage]

I store everything in an org file which I can choose to encrypt using the :crypt: tag. This file can live anywhere(GitHub, Dropbox, drive, etc etc). The dotfiles are stored in source blocks from which I'll tangle to the relevant place in the file system. This approach works really well if you are a heavy emacsen user.

[Jonathan Carter]

As a non-Emacs user (apologies!), I’m not too familiar with org files. Any pointers that could help me understand this solution a bit better? I’m really intrigued 🤗

[Lucas Queiroz]

I currently store them in a secret gist, but I'm creating an install command, and storing it in a secret GitHub repo. It will basically download everything I need and setup all the files to keep my aliases, ZSH themes, Spotify theme (using Spicetify), etc

[Jonathan Carter]

Out of curiosity: why are you using a secret Gist? Are you storing secrets in there, that you wouldn’t want others to see?

Also, have you considered using a “dot file manager” such as YADM or Homeshick, as opposed to scripting your own solution?

[Lucas Queiroz]

I don't have any secrets within the files, not sure why I keep it private... Better safe than sorry I guess?

I didn't know they existed, actually! I discovered with your post. I might still finish my own as it will also install all the softwares I need and apply themes/plugins (For example, it would download VSCode and apply my themes and plugins). I might consider using the dot file managers for the dot files and keeping my "install script" just for the things it can't do.

[Angelika Cathor]

I keep my dotfiles in a Github repository, alongside with a list of things to set up manually. There is a script I copied from somebody's dotfiles repo that does the symlinks. If I update a dotfile on one machine, I just pull from the other. I also have a .bash_profile_priv file that I load from .bash_profile but do not commit, so that I can set there env variables and such that only make sense for one machine or are secrets.

I also keep an install script that installs various packages and apps via brew, and detailed instructions how to configure manually the system and certain apps to my liking.

Spending time on this repo paid off big time. I have re-installed the system more than 5 times now using this repo and I can't imagine not having it. I don't have to think much during the process, I just follow my list :).

[Reese Poirier]

Ohhhh, symlinks 🤦‍♀️ Of course!
Thanks for sharing. I also use github to manage my dotfiles and I've been thinking about how I wanted to manage syncing them without making my home folder a git repo. I was halfway through setting up some bash scripts with rsync, but symlinks are so much less effort and will work better.

[Dan]

Just wanted to say thank you for the discussion topic. I am storing mine in Dropbox at the moment and I’m very new to bash and using dotfiles and etc. I have read many of the things here and I will try to refactor. I have been using bash’s source to include scripts (functions) and settings from a folder in Dropbox. I simply didn’t know of other ways and it’s great to see them now.

After reading several things here I may create a git repo and then I will likely just create symlinks for what I need (as well as a script to generate those symlinks on a fresh install).

[Adrián Norte]

I feel ashamed to say that I only care about my ohmyzsh dir and .zshrc file and store them on Dropbox (because of native Linux app) and symlink them whenever I start a new computer in order to have the same plugins and config across my laptops and workstations.

But I'm gonna check those solutions because that seems neat.

[Dave Follett]

There is some good stuff in here, I've not tried any yet though.

Do you store your local development config in the cloud?

Ben Halpern ・ Feb 1 '19 ・ 1 min read

#discuss #productivity

[Jonathan Carter]

Ah nice! Thanks so much for sharing this. I searched past #discuss posts and totally missed this 🤗

[Dave Follett]

No problem, I've got it permanently on my reading list so I can refer back to it. Post back here if you find an option that works well. I haven't had a chance to try any yet.