github - Git branching strategies for CICD -

just looking thought on below branching strategies keeping cicd in mind.

1. master branch -

   1.1 development branch - fork master

             team branch - fork development branch , merge                            development branch after feature implementation                            qa/integration testing            team b branch - same above     1.1.1 release branch - goes in prod 

once team , team b branch merge , qa verification done, create release branch , have final regression on it. release branch go production.

then merge release master branch.

intent -

1. master branch stable , production running code available in it.

2. team branch can deployed on dev environment , have required cicd configuration on server.

any issue approach?

to being doing ci (and ci required cd) merge master regularly , not have long lived feature branches. believe once day expected "ci".

an alternative approach 1 suggest have short lived developer branches daily work. have deployment pipeline moves each code change through series of test stages. once changes have passed each stage go next stage , ready production. allows work on master remain stable , allow passing code enter production.

to deal independent feature work can use feature toggles instead of branches. can toggle features on , push master test them , deploy if well. if not, or if there business need remove feature, can toggle off feature , continue use master safely. have seen work on 2 products have worked on.

i know simplified make suggestion of alternatives , help. can learn more implementing these techniques on bunch of blogs , stackoverflow answers - http://martinfowler.com/articles/feature-toggles - http://www.paulhammond.org/2010/06/trunk/alwaysshiptrunk.pdf - feature toggles vs feature branches