A good branching model matters a lot for development efficiency, but same as many other topics, there isn’t a golden way that fits all.
The current development flow I am using:
Feature Development
We create a feature branch when we are working on a specific feature, we name the feature branch by the jira ticket name(we integrated Jira with Github, so the branch will show up on Jira tickets, e.g USER-100).
After feature completes and finished testing locally, we deploy the feature branch onto a test environment.
Test environment is controlled by developers, so we can do more integration tests instead of local, this is useful in micro services based architecture.
Once developer is pleased with the tests on test environment, A pull request is made and after code review by peer, the pull request is merged to develop branch.
Release candidate
Everything on develop branch is ready for next release. we will deploy develop branch to staging environment, QA will run automation tests and gives green light for the release.
Then we create a pull request from develop to master, master always has the latest stable release.
We then merge the pull request to master, tag the release and deploy the release to production.
Hotfix
hotfix is directly based on master, then merge back to master after release, we also need to create a pull request to merge it to develop to make develop branch up to date.
Problems and improvements
Apparently, this approach is not robust and has some potential problems.
Since release candidates are always in develop and need to be merged to master, this will block other features merging to develop if the release takes long or there are many features working in parallel.
Add release branch
So for a big project that with a lot of features, we can introduce another branch release branch, when the features merged back to develop and is planned for the next release, then create a release branch based on develop, so other features can still be merged to develop without affecting the upcoming release.
With release branch introduced, our flow works much like http://nvie.com/posts/a-successful-git-branching-model/, this branching model was later be considered harmful, while in my opinion, it’s not really harmful, it’s just different development team needs a way best suits.
Github flow
Github flow is very straightforward, feature branches merge back to master and then master can be deployed to production, this is super efficient to integrate with CI/CD tools with no developer intervention.
Gitlab flow
While this will not work for us, because our releases always rely on a configuration management system, that you need to add configuration changes first and then release your code.
In this case, a gitlab flow introduces a production branch, master branch becomes the release candidate or pre-release.
Some other variations
Some teams do release based on cherry-pick, when feature branches merged to develop, then create a release branch based on master instead of develop, and then cherry pick all commits need to be released from develop to master. This will cause master and develop commit history diverged, and you will not be able to merge master back to develop soon.