The Rules of Programming

Rule 19. Rework in Parallel

Most of the time, for most of the work you do as a programmer, you’ll only make brief departures from the main codebase. You’ll investigate a problem, check out the files you need to fix the problem, test and review your changes, then commit them back into the main branch. You might complete the whole cycle in a day, though that’s pretty quick if there’s any testing to be done; more typically, you’ll spend days with stuff checked out.

Eventually, though, you run into a task where this simple model falls apart. You’re teaming up on something with another programmer, say. When you’re working solo, the work in progress only exists on your machine, but that doesn’t work when you’re partnered with someone. The two of you need to maintain a shared version of the work in progress.

The standard answer to this is to create a new branch in your source code control system for the work the two of you have planned. This branch starts as a copy of the main branch, but quickly diverges from the main branch as you work. You probably look for occasional chances to integrate changes from the main branch into your branch to keep up with the work being done by the rest of the team, resolving any conflicts introduced by changes on the main branch. Eventually your work is complete; you integrate one last time from the main branch, do a final test, review your work, and check in.

Bumps in the Road

This approach works—that’s why it’s the standard answer—but it’s not free ...