What is Gitflow?
(Image credit: https://nvie.com/posts/a-successful-git-branching-model/)
In Gitflow, you mainly deal with two branches: develop and master.
Developers work off the develop branch. Feature branches are created from develop and merged back when done.
When a release is ready, develop gets promoted to master and tagged. Think of master as production-ready or what is in production.
To fix a production bug, a developer will have to create a branch from master and then merge the fix into both master (for another release) and develop. There is a possibility of conflicts when merging into develop.
What is Gitlab flow?
(Image credit: https://docs.gitlab.com/ee/topics/gitlab_flow.html)
Gitlab flow is simpler. It only calls for one main branch: master.
- Developers work off the master branch. Feature branches are created from develop and merged back when done.
- When a release is ready, a release branch is created from master, tagged and released.
To fix a production bug, a developer will have to create a branch from master and then merge the fix back into master as he normally would do with any feature or bug. To release, the revision is cherry-picked into the release branch. A new tag is created and released. There is a possibility of merge conflicts during the cherry-pick.
What do we use?
Here at Vectorwyse, we have adopted Gitlab flow simply because it is simpler. Developers work as they normally would on master. A release engineer can be assigned to handle branching and merging for releases without having to understand much about the code. And the possibility of merge conflicts during a cherry-pick is low.
The steps for a release are basically as follows:
- Create a release branch called v1.0 branch from master
- Tag release branch as v1.0.1
- Release tag v1.0.1
To fix a bug:
- Developer merges fix into master, note the revision number.
- Release engineer cherry-picks revision into v1.0 branch
- Tags it as v1.0.2
- Release tag v1.0.2
