In an earlier post, I explained the basic change process. In this post I'd like to show how it works in a distributed version control system. Besides encouraging the general use of distributed version control systems, I'd like to expose the difference between the classic branching diagrams and the actual meaningful part of the revision history.
- Start at a stable revision;
- Branch, make change;
- Meanwhile, some other change makes it into the stable branch;
- Pull in the new change, merge;
- Add your change to the stable branch (assuming, of course, it passes QA).
Here's what it looks like in the distributed world:
You start with your main repository. This will usually be hosted on some kind fo more centralized host, or on a service like GitHub or bit bucket. As I explained in my Cherrypicking Made Easy post, the best repo to use is the one that represents your current production version of the code. I believe that in the end, this is the only repository that truly matters to Release Management...
If you wish to make a change, you fork or clone your own repository off the main repo. If you use a remote service, you may wish to first fork/clone the repo on that remote service, then clone onto your local machine.
Now edit, compile, test and check in - creating the green revision in the diagram.
Meanwhile, some other change appears in the main repository, marked as the blue change.
The interesting thing here is how the branching diagram of the basic change process simplifies into the diamond shaped revision graph. This will become more interesting as we examine the basic technique to produce Release Notes by examining changes contributing to a specific revision (usually a release).
A very good read to get into the mood of distributed version control systems is http://hginit.com, especially if you're a subversion or perforce user.