GROWS logo

Everything is under Version Control

Version control is not just for your product source code, but also all of your personal files, such as settings, batch files, shell scripts, IDE configs, templates, and so on.

Pain Points

  • Staging your new development machine is painful
  • Migrating your shortcuts & preferences is hit or miss
  • You lose scripts and personalizations every time you move to a new environment


There are several benefits to using version control in a robust manner on your personal files.

  • Staging a new environment quickly. Whether you’re using a new environment or upgrading from an old one, robust version control lets you spin up everything quickly. From the scripts and shortcuts you have in muscle memory to editor visual tweaks, solid version control makes you productive quickly… which makes you look like more of a wizard in front of coworkers and managers.
  • Growing your toolbox of customized shortcuts. As you move through your career, you should be learning from others and discovering new tricks on your own. But what’s the best way to preserve these tips and tricks? Copy them from machine to machine by hand? Just recreate them when you miss them on the machine? No, save them in version control and restore them in a few seconds instead.
  • Spin up the new team member fast. Is this a personal benefit or a team benefit? Depends on your point of view. Do you want to spend the next week sitting with the new developer, recreating every little script and helping them become productive, or just pull everything out of version control? While that type of pairing can be a great bonding experience, it can also make new team members feel incompetent and slow you both down during a critical deadline.


✓ Critical ❑ Helpful ❑ Experimental

Adoption Experiment

Steps to first adopt this practice:


  1. Download a new operating system for a virtual machine or stage a new computer with a clean operating system
  2. Install basic version control and development tools


  1. Go to the blank machine
  2. Check out the project and your personal tooling/preferences
  3. Continue working where you left off when last at your regular machine
  4. When you discover you’re missing something, make a note of it and start a list

Evaluate Feedback

  1. Were you able to work normally?
  2. Did you have access to all of your personal settings, customizations, etc.?
  3. When you’re done, look over your notes. How many things did you have to find/copy over by hand? How many scripts did you rewrite? These are your candidates for version control.

What Does it Look like?

You either have a small area in the team version control system, or you have your own. All your scripts, tools, and customizations are stored in it. Using git? Then your .gitconfig is stored. Using bash (on OSX or linux?)? How about your .bashrc and/or .bash_profile?

Did you alias sl to ls? How about mroe to more? What about a batch file called ls.bat? What about your tooling preferences? All these things are in your version control system.

  • You write a small script to help you with a common task. You add it to your personal version control.
  • You change your colors in your favorite editor, and commit those changes to version control.
  • A meteor hits the office overnight, destroying your machine… or your hard drive crashes. Whatever. You are back up and running on a fresh box within minutes.

Warning Signs

  1. Missing scripts
  2. Missing shortcuts
  3. Missing preferences
  4. Missing anything you’ll add to a new environment

Growth Path

  1. Start with your batch files and shell scripts
  2. Move to editor and IDE preferences. They might be hidden, but you can find them
  3. Run your own version control server (not on your primary box) or get an area on the team’s server
  4. Be able to stage an entire environment out of your version control. Check out files and run one script. Now you’re ready to work.

Exercises to Get Better

Work on mastering your environment and shaping your machine to be more efficient for you. Then work on persisting those shortcuts into version control. Add in a script to deploy these changes to your new machine. How fast can you stage a new environment? Consider tools to deploy libraries and development tools.

Consider how your work habits would change if switching environments became trivial?

How to Teach This Practice

Pair with another developer… what changes do you feel compelled to make in their environment? Make sure those changes are checked in on your own.

Practice setting a new environment (perhaps in a virtual machine) until it’s trivial.

How To Fail Spectacularly

  • Thinking you don’t need version control and delete your work results with the “rm” or “rsync” commands:
$ cat ~/Documents/LessonsLearned/bookmarks-2016-01-16.json | python >
$ rm ** unclebobmartin       RT @SEInews: Just Published: An Interview
rm: unclebobmartin not found
rm: RT not found
rm: @SEInews: not found
$ rm ~/Documents/LessonsLearned/bookmarks-2016-01-16.json
$ ls
$ ls
  • Working with an extensively customized environment… investing hours or days into getting it all just the way you like it… then watching it go away with a hard drive failure
  • Pushing files that contain your own IDE preferences to the team repository… and overwriting everyone else’s customizations!

(Automate Everything) Next→

Follow @growsmethod on Twitter, or subscribe to our mailing list:

Sign up for more information on how you can participate and use the GROWS Method™. We will not use your email for any other purpose.