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.
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
Steps to first adopt this practice:
Download a new operating system for a virtual machine or stage a new computer with a clean operating system
Install basic version control and development tools
Go to the blank machine
Check out the project and your personal tooling/preferences
Continue working where you left off when last at your regular machine
When you discover you’re missing something, make a note of it and start a list
Were you able to work normally?
Did you have access to all of your personal settings, customizations, etc.?
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.
Missing anything you’ll add to a new environment
Start with your batch files and shell scripts
Move to editor and IDE preferences. They might be hidden, but you can find them
Run your own version control server (not on your primary box) or get an area on the team’s server
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:
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!