>Here's a nice article on Story Branching (uses Bamboo, Atlassian makes and sells Bamboo services, and wrote the article). Bamboo creates a Plan for the branch (story). What's your take on this?
>
>For those of us happily working in dynamic languages, the key is managing the branches, without the concern for compilation, but of course with the concerns for testing. There is considerable support for branching for each hotfix (defect in the current release), but git by itself doesn't do the organizing. I found this article http://nvie.com/posts/a-successful-git-branching-model/ very useful in organizing branching. What this article doesn't cover is the idea of rebase-ing from the master, which the following article does cover (step 7): http://greybeardedgeek.net/2011/07/29/a-beginners-take-on-git/. I would add the rebase from master action into the hotfix branch described in the first article. This way the master becomes fully tested with the hotfix before the commit to master. The rebase action addresses your sensible objection to branches being left coasting for too long. Rebasing means that the developer has a good reason to get it back in quickly, because that means less chance of having to clean up issues arising from other hotfixes having been completed and merged with master. And for features, I would rebase from develop before committing to develop.
>
>Hank

Thanks Hank for the links.

I'm using a variant of the "successful git branching model" from almost a year now, and it's working ok with parallel developments.

it's true that a DVCS tool makes a big help on merging, and if you use best coding practices, this helps a lot too, because in some way merging algorithms benefit of these good programming practices ,like using good naming conventions and others.

We are merging all the time, and almost all errors found in code, were fault of devs, almost never Integrator's fault.