My development env: Windows 7, TortoiseHg, ASP.NET 4.0/MVC3
Test branch: code on test server
Prod branch: code on production server
This is my current branching model. The reason to branch out every task (feature) is because some features go to live slower. So in above graph, task 1 finished earlier (changeset #5), and merge into test branch for testing. However, due to bug or modification of original request, changesets #10, #12 have been made. While task 2 has finished testing #8 and pushed to live #9 already.
My problem is every time when modifying task branch (like #10, #12), I have to do another merge to test branch (#11, #13), this makes the graph very messy.
Is there any way to solve this issue? Or any better branching model?
It really sounds like you are trying to implement a feature branching strategy. However, based on your diagram, I think you’re missing a few steps and/or are merging the wrong branches. In essence, you should probably have more like 4 lines of development there, plus 1 representing all feature branches. Unfortunately, I have not been able to find a nice diagram, except for one talking about Git and a workable branching strategy here. The diagram, though, better explains what you are looking for, even if you are using a different DVCS like Mercurial (my fav). Using Steve Losh’s Guide to Branching in Mercurial and the Hg Book, you should be able to implement a good feature branching strategy that works for you. Steve’s got pros/cons for each approach.
And, no, you don’t need to clone to branch properly. Mercurial has named branches that allow you to switch between branches easily if you are commonly working on multiple unfinished items and/or performing code reviews/testing for other developers. With any kind of Web-based development with IIS, named branches are easier to work with as things don’t move and different version can continue to work with the same configuration under IIS.
I must say, though, that feature branching or whatever name you give it is almost always a bad idea as branches that run too long (say, a year, which I have seen with disastrous results) can be almost impossible to merge back in unless you are frequently (daily) managing synchronization between the feature branch and its parent. This type of maintenance overhead is not worth the trouble and you’re better off sticking to trunk-based development with release branches for bug fixes and fix your code to abstract code that is production-used and unfinished work.