This article sounds interesting, but I'm pretty sure the diagrams are wrong. http://guides.beanstalkapp.com/version-control/branching-best-practices.html
Shouldn't it be DEVELOPMENT > STAGING > PRODUCTION?
Merges should only flow in one direction: from feature and bug-fixes done in their own branch or in development into staging for testing. Once tested, you can merge those changes from development into production.
Here I get a bit confused. So I merge Staging to Master or Master to Staging?
I'm using a client called SmartGit and I get confused about this point. Normally I make a branch for a feature, commit to it, then switch to master and merge it to the branch (forward). So in this new workflow with Staging and Production, I create these two extra branches, then create a branch from master (aka dev) for my feature. Commit to it, then switch to Staging and merge (forward) to my feature branch? Does that sound correct?
Actually what made this so confusing is that the Beanstalk people stand behind their very non-standard use of Staging (it comes before development in their diagram, and it's not a mistake! https://twitter.com/Beanstalkapp/status/306129447885631488
Have decided to forget about Beanstalk and just go with Github.
Since I posted this, the Beanstalk people took my hint and renamed their stages, now calling Development "Stable".
This question is related to
git
Actually what made this so confusing is that the Beanstalk people stand behind their very non-standard use of Staging (it comes before development in their diagram, and it's not a mistake!
We do it differently. IMHO we do it in an easier way: in master we are working on the next major version.
Each larger feature gets its own branch (derived from master) and will be rebased (+ force pushed) on top of master regularly by the developer. Rebasing only works fine if a single developer works on this feature. If the feature is finished, it will be freshly rebased onto master and then the master fast-forwarded to the latest feature commit.
To avoid the rebasing/forced push one also can merge master changes regularly to the feature branch and if it's finished merge the feature branch into master (normal merge or squash merge). But IMHO this makes the feature branch less clear and makes it much more difficult to reorder/cleanup the commits.
If a new release is coming, we create a side-branch out of master, e.g. release-5 where only bugs get fixed.
one of the best things about git is that you can change the work flow that works best for you.. I do use http://nvie.com/posts/a-successful-git-branching-model/ most of the time but you can use any workflow that fits your needs
Source: Stackoverflow.com