How do I use git flow with a staging environment?

Question

We are using git-flow to handle hotfixes & features, with a develop branch & the master branch (for production).

What is the easiest way to add a staging branch to the mix so that we can validate work that is on its way to production from develop while still keeping the helpfulness of git-flow?

Klas Mellbourn · Answer 1 · 2018-03-30T08:11:38.497

15

I would say that staging should be based on a git flow release branch. After a git flow release start and git flow release publish you can start QA work on that branch, including deploying it to a staging area. When the QA work in the staging area has proven the code ready for production deploy in production and do git flow release finish.

If you are using TeamCity, you can easily set up the server to detect new remote release branches and automatically set up builds for them, see here.

edited Mar 30 '18 at 08:11

answered Apr 15 '13 at 18:31

Klas Mellbourn

42,571
24
140
158

You suggest using a different branch for each potential release rather than having a dedicated branch to "the next release in testing" (staging) just like there is always a develop & master branch? – Eric Apr 16 '13 at 11:48
Yes, that would be the standard git-flow way of doing it, afaik. You could always name the branch the same, e.g. "staging". But normal use of git-flow would remove the branch when you `git flow release finish` and recreate it when you `git flow release start` – Klas Mellbourn Apr 16 '13 at 15:10

score 5 · Answer 2 · edited Sep 30 '22 at 10:38

I've just started to use git flow but IMHO the easiest way is to set next release as dev branch and production releases as stage branch and then e.g.: manually merge with master branch (your real production).

In case you release version 1.2.0 to stage and then find bugs in your release (4 hotfixes e.g.: in core CMS, feature1, feature3 and feature4) then you can always apply patches so for instance you can end up with version 1.2.4 and then finally merge it to production.

UPDATE: This scenario assumes that you do not have a roll-back mechanism so you are always adding commits to fix, release feature or anything else. If you do have a roll-back mechanism then you don't need to worry about your bugs in your production. Just when you discover error use roll-back to set-up previous working version. E.g: if you find bug in version 1.2.3 go back to version 1.2.2. Fix bug, test on dev then on stage and push to production as version 1.2.4. So your production will jump from 1.2.2 straight to 1.2.4.

How do I use git flow with a staging environment?

2 Answers2