git with development staging and production branches

Question

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

User · Accepted Answer

The thought process here is that you spend most of your time in development. When in development, you create a feature branch (off of development), complete the feature, and then merge back into development. This can then be added to the final production version by merging into production.

See A Successful Git Branching Model for more detail on this approach.

User · Answer

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

User · Answer

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

User · Answer

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

[git] git with development, staging and production branches

Examples related to git