On the whole you're on the right track, but I'd like to explain a little further about what you're doing and the possible long-term implications. Feature Branc

On the whole you're on the right track, but I'd like to explain a little further about what you're doing and the possible long-term implications. Feature Branches can become corrosive. Any changes made on the mainline will have to be merged with every feature branch. This is fine with small teams (< 3) but can become frustrating when you have a lot of feature branches or high velocity on your trunk/master. Long-lived branches and refactorings must be merged regularly to prevent merge conflict hell! A lot of this comes down to having disciplined developers. Why develop on mainline? A lot of this comes from the non-dvcs days. It was expensive to make a branch/tag and they tended to be made when making a release. The beauty of keeping mainline up-to-date (commits once per day) is that you have a regular tracking point to revert changes back from on production. Instead of trying to remember which feature branch was deployed, you have a consistent (linear) timeline. As you've said this becomes beneficial when you automatically test and deploy your code. A lot of this is to enable best practices for when you decide to setup a CI server like Jenkins to run your unit/integration tests and then deploy automatically (maybe) on a clean run. Regarding git, I'm going to assume that you've taught your devs enough to follow good habits to keep them sane. Many find that learning git takes a fortnight or so to fully understand. Still, it's always worth throwing a bunch of resources their way. In no particular order: http://progit.org/book/ http://progit.org/book/ http://www.gitready.com/ http://www.gitready.com/ http://book.git-scm.com/ http://book.git-scm.com/ For more on this kind of stuff and no doubt a better explanation, check out Continuous Delivery by Jez Humble and Dave Farley. Link: http://continuousdelivery.com/ http://continuousdelivery.com/