Editorial note: I originally wrote this post for the NDepend blog. You can check out the original here, at their site. While you’re there, take a look around at some of the other posts as well.
Committing code involves, in a dramatic sense, two universes colliding. Firstly, you have the universe of your own work and metaphorical workbench. You’ve worked for some amount of time on your code, hopefully in a state of flow. And secondly, you have the universe of the team’s communal work product. And so when you commit, you force these universes together by foisting your recent work on the team.
In bygone years, this created far more heartburn for the average team than it does today. Barbaric as it may seem, I can actually remember a time when some professional software developers didn’t use source control. A “commit” thus involved literally overwriting a file on a shared drive, obliterating all trace of the previous version. (Sometimes, you might create a backup copy of the folder). Here, your universe actually kind of ate the team’s communal universe.
More Frequent Commits, Fewer Problems
But, even in the earliest days of my career, lack of source control represented sloppy process. I remember installing the practice in situations that lacked it. But even with source control in place, people tended to go off and code in their own world for weeks or even months during feature development. Only when release time neared did they start to have what the industry affectionately calls “merge parties,” wherein the team would spend days or weeks sorting out all of the instances where their changes trampled one another’s.
In the interceding years, the industry has learned the wisdom of continuous integration (CI). CI builds on the premise, “if it hurts, do it more,” by encouraging frequent, lower stakes commits. These days, most teams commit on the order of hours, rather than weeks or months. This significantly lowers the onerousness of universes colliding.
But it doesn’t eliminate the problem altogether, even in teams that live the CI dream. No matter how frequently you do it and how sophisticated the workflows around modern source control, you still have the basic problem of putting your stuff into the team’s universe. And this comes with the metaphorical risk of leaving your tools laying around where someone can trip over them.
So today, let’s take a look at some of the most common things everyone forgets before committing code. And, for the purposes of the post, I’ll remain source control agnostic, with the parlance “commit” meaning generally to sync your files with the team’s.