« SmugMug Customer Service is Great | Home | Wikipedia »
Source Control and Private Branches
By Jacob Cohen | August 21, 2008
Jeff Atwood wrote a blog entry today extolling the virtues of early and often checkins to source control. I agree with this, though I think there are a variety of ways to accomplish it.
Recently I have become fond of using a combination of Git and Perforce. The Perforce depot provides the centralized, managed source control system that lets me coordinate my code with other developers. Git provides the quick personal versioning and branching convenience that I use every day to manipulate my code base on my own machine.
Why do I need both of these? Perforce supports branching too. But then I have to set up the branch, and switching between branches is not an especially quick task. If I want to quickly work on something off a different branch, I have to painstakingly store everything I’m currently working on into the branch I’m on, then switch, open files, check those back in, then switch back.
With Git, I do all of my branching and switching locally. Everything starts from the p4/master branch which is the version Perforce is tracking. I can then easily create several parallel branches on top of this that let me modify different things without stomping all over my own changes.
Since the Git repository is local, more akin to rcs than to centralized SCM products, I can check in as often as I want without having to worry about integration with other code. I typically check in to my Git repository about as often as I save the file in my editor.
Since multiple people on my team use this approach, we can actually pull changes across from each others’ Git repositories without having to go through Perforce. This behavior of Git is similar to SCM products like arch, where changes are defined by the checksum of their contents. Thus, if I pull a change from a co-worker, and apply it to my local copy, and later pull down that same change from Perforce, everything is happy and there are no conflicts because it is the same change.
So I typically work within my own codebase for about a day or two at a time, using Git furiously to keep track of all my fine-grained changes to the code. Then I use Git to compare my repository to what is in the Perforce depot, and create a Perforce change specification representing all of the changes I have made (typically at the user story or feature level).
Topics: General |
August 22nd, 2008 at 8:27 am
Oh cool! I use p4 as well, but haven’t actually heard of git before. This sounds pretty useful and I think I’ll try to use it on my next project. Our team had to struggle with branches. Some developers wanted a developer-specific branch, but I tried to focus more on task-specific branches, since multiple developers often worked on the same general tasks or functionality areas.
The problem was that a couple of engineers who didn’t really have the version control mindset would cause significant problems for the whole team. (e.g., wait wayyy too long and do a massive checkin containing a bunch of updates in a single changelist, with no way of identifying any particular diff with any specific change).
Of course, the fundamental problem is not a CM issue, it’s an attitude issue. People who are resistant to learn to use new tools or to work effectively in a collaborative team environment are bound to create issues regardless of the tool.