The rules of git branching

Question

We have a big enterprise project and we have some stages of development. We use git. The branching looks like this:

DEV -> SIT -> PROD

DEV branch is development branch as is. When dev is done it's pushed to SIT branch, and the SIT source is used by QA for testing stage. For release the PROD is used.

So the question: if DEV is finished and SIT testing have been started and a bug was found, what is the correct flow?

1:

• create a branch for bugfix from SIT branch and push it directly from the branch to SIT
• retest
• in case the bug is fixed then the branch from DEV should be created and pushed to DEV with fix this fix.

2:

• Create a branch from DEV and push bugfix to DEV.

• Push changes from DEV to SIT

What flow is correct 1 or 2?

I want to know the best practice

Answer 1

Both are valid strategies you can use.

Option 1

pros:

1. You get to test your bugfix quicker, since you are bypassing the DEV branch.
2. You can see which bugfix branch (if there are more than one) is the best approach and use that to put into DEV and then PROD.
3. SIT is decoulped from DEV so you can continue with work on DEV without worrying what SIT has to test.

cons:

1. There might be a lot of back-and-forth play between DEV and SIT if the bugfix doesn't hold in the long term and you need to re-apply the fix to DEV several times.
2. If you are not careful, then DEV might get merged into PROD, or SIT into PROD, but then the other branch might miss these changes.
3. The workflow is not a staight line: DEV -> SIT -> PROD, meaning it might get confusing which changes go where.

Option 2

pros:

1. The workflow is simple and easy to follow. No confusions here.
2. You can easily track changes at all levels of development, without wondering what the SIT has to test, or if DEV is too far ahead if PROD/SIT, or the other way round.
3. You write all your code in DEV, instead part of it in DEV and part of it in SIT. This way you won't deal with a lot of conflicts.

cons:

1. You might be a bit slower with giving the SIT branch the needed changes/fixes to test, as they need to go through DEV.
2. DEV might get overwheleming with branches if it's not managed properly.
3. It will be more work if you want to test different features for different customers if all your code comes from DEV, as you need more git maintanance to pick the specific version you will test.

Personally I like the second option as it is more streamlined and easy to maintain in DEV. You can also check out these workflows to get some other ideas.

Answer 2

This question doesn't have a 'TRUE' answer but as a developer, you shouldn't reinvent the wheel. There are already broadly accepted branching strategies independent of project:

• Git flow
• Github flow

I would recommend to read them through and decide with your team. And only apply these flow. There are also tools to force each strategy.

Answer 3

Create a hotfix branch from SIT fix the issue there. If the test passes, merge it to SIT and then rebase DEV from SIT

SIT -> create branch fix/issue

QA PASS -> merge fix/issue into SIT -> rebase dev from SIT

Answer 4

Git flows highly depends on your development environment and stack. Github, Bitbucket and GitLab have their own recommendations and best practices.

I recommend to read all of them: Github flow , Bitbucket recommendations , GitLab flows .

As for me both of your bugfix options not optimal and makes flow more complex. Creating additional useless branch for butfix, than make new merge to SIT or DEV. There's no points in all of these operations. What if you find new bug in your DEV-feature? New branches|merges?

I recommend to use Stable mainline branching flow.

feature -> pull --rebase PROD & push -f -> remote/feature -> QA testing -> PROD
   |                                                            |
  FIX    <---                    <---                     <--- bug

Step by step:

1. Create feature branch from prod .
2. Implement in feature functional/fixes.
3. After feature complete rebase it on latest prod and force push.
4. Make tests on remote/feature branch.
5. If you found bug in remote/feature repeat steps 2-4.
6. Fast-forward merge remote/feature to prod .