Reputation: 9785
while having the requirements:
Looking at A successful Git branching model
Can we do away with release branch as long as we tag the master branch after every release?
Can we also do away with develop branch?
Release branch can be branched off master at the start of the new sprint and devs can create their features branches off of that. If a hotfix merge to master (current release) happens in the middle of a sprint, the hotfix can also be merged to the current release branch at the same time as feature-branch-hotfix-
Code from feature/develop branches should be deployed to DEV environment
Feature branches by themselves should not be deployed at all.
Prefer my strategy in which a merge request from release-* to master kicks off the jenkins pipeline build via webhook, that will auto merge release-* to master, build from master and tag the merge commit.
Upvotes: 3
Views: 553
Reputation: 1329102
If you want a simpler (and more flexible) workflow, consider the gitworkflow.
You don't merge dev
to master
: you only merge feature
branches.
Merge feature
branches to:
dev
for integration testingmaster
to preparing the next releaserelease
branch if you maintain/prepare multiple releases in parallelI detail that model further here and illustrate it here
One important point: the dev
branch (for integrating feature
branches together) is transient: it is created/destroyed for each new release (as opposed to one fixed eternal dev
branch merged to master
from time to time).
You recreate as many integration branches you need to testing features together.
Then, when ready, you only merge the right feature
branches to master
(or any other release
branch), delete your dev
branch, and recreate it for the next release.
Upvotes: 3