This is the third installment in Getting started with Mercurial for a small team.
In this post we’re going to cover Workflow basics.
Mercurial / Team Workflow Practice
In a small team often the workflow process is not something that has to be complex. There are a few different workflow techniques that make sense in this case. Even in a 1 person team branching and tagging may seem unnecessary butthey can come in handy.
First, here are a few great articles on workflow practices.
http://mercurial.selenic.com/wiki/Workflows
http://secretgeek.net/image/mercurial_workflow_image.png
Steve Losh’s guides are priceless and serve as the basis for the workflow process described below.
Branch as needed (Read Steve’s description and come on back.)
The name may seem a little deceiving but essentially the recommended approach is to not worry about branches in general. Development on the main line / default branch should work a lot of the time for a small team. Often when you are working in small team’s you don’t have to worry about features others are working on since you are likely the only one. In the small cases as well where a few are working it is often in a way that they can develop features that are completely part of a different area of the code than you are working on. You often don’t have to worry about updating the code base for a "hotfix" either which if you were developing off the default branch could present a problem should this be needed.
The reality is even in a small team you will want to think about these possibilities and plan for them if they will be an issue. Hence, "Branch as needed". If you don’t need it, then don’t worry about it.
When you do need to branch there are several techniques described at http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/.
Branch with Named Branches
Even for small teams or code bases, branches offer some great advantages and should be considered a part of your process. Branches offer a way for you to create a separate isolated area for you to develop a feature or bug fix. This isolation allows us to fully develop the feature or bug fix without touching the default line.
This gives us the flexibility to get rid of the branch if we decide it’s not working or work a fix in on the default line while we are still developing the feature on it’s own. If we were not using a branch and a serious bug is found the feature code may stop you from being able to issue a fix for it until you’ve completed the feature.
I tend to use branches for features that I deem larger than a week to work on or if I am really unsure of how I want to accomplish it that way I can get rid of my work easily if I decide to scrap it and start over.
There are several ways to create branches in Mercurial. Were going to use the Branching with Named Branches process. Branching with clones is also a great option if you are really unsure of your work and think you might need to trash it. This is the simplest for trashing but requires a bit more work if you like it and want to merge it back into the original codebase.
Another very good approach is to use a stable branch for releases and have default be where you mainly develop. http://stevelosh.com/blog/2010/05/mercurial-workflows-stable-default/. Depending on your need for your product line this option may be a great option as well.
Next up, setting up your repository.
Image may be NSFW.Clik here to view.
