Hello guys,
I’m studying some flows in this week to put in action here in the HHS, follows my analysis regarding the different standards of working with Git.

Let’s start with Git-Flow:

Gitflow

It has two main branches to master and develop. A master branch always reflects production, it can be deployed to production at any time. Branch develop will always be the most updated to contain the latest changes, ready to merge with the release and be tested before merge to master. There are 4 types of branch support feature, bugfix, hotfix, and release:
Feature: New stuff and bug fixes that can wait until the release of the next release, makes direct merge with never ever develop directly with the master.
Release: created from develop is completely testable, can be merged with bugfix and then merge with the master, considering that all bugs have been fixed and tested. Being thus release will be ready to merge with master and develop, we mark with a tag the new version.
Hotfix: When something bad is discovered in production creates a branch from the master a hotfix, then the merge is corrected and again for master and for release, if you have some release in phase, test and release to develop soon after the tests, but if there is no release in progress the merge should be forwarded to develop. The perfect world would be no hotfix, as we will be covered by tests, but the perfect world only in fairy tales 😁, if you are creating many hotfixes we have to review our tests in release.
Bugfix: in the case found a bug testing a possible release, we’ve create a new branch to fix this bug and after we’ll have to merge to release and develop, you can go back the test release branch.

  • master is my production code with the version tag.
  • Only hotfix and release merge with the master. (ideal only release 😎).
  • feature merge with develop.
  • bugfixes are merged to release and if necessary merge is done relase with the match to develop

GitHub-Flow:

Githubflow

Flow simple and objective, which needs implementation frequently. A branch is made from the master both to fix bugs or implement new things. After completing one of the branches a pull request is made where it will be approved and tested before the merge is done for the master and sent the production.

GitLab-Flow:

Gitlabflow

This flow is dedicated to production branch, we have 3 main production, staging and master lines.
master is the local development environment line.
staging test line before going into production, also known as pre-production.
production line that reflects production, when the merge of staging is done for production we mark with a tag and it is done deploy in the production environment.

Conclusion:
There is no better or worse flow, there is something that fits your need.
cya ✌