A common Git workflow has two main branches, 'development'  and 'master'.  With the common workflow of creating feature branches from ‘development’, merging the feature branch back to ‘development’, and then for a release to production, merging 'development' to 'master'.  Non-trivial conflicts can occur during the merge to 'master' when same/similar changes are made in both 'master' and 'development', or 'development' has had some necessary reverts or other changes.

Instead of having two main or long lived branches, another idea for a Git workflow is to use only one main branch, then create a branch for production pulls.

aka 'trunk-based development workflow' or 'single branch strategy'

Think of the one main branch as the 'development' branch

• flow for development would be the same:

       - branch from 'development' for a Ticket, merge request  to 'development' when done

• when want to do a release to production, instead of a merge request to 'master'

       - create a new 'production' branch at the last or desired 'development' commit

• when want to do another release to production

       - rename current 'production' to 'production-date' ie 'production-20200531'

       - create a new 'production' branch at the last or desired 'development' commit

• 'master' branch would then be unused and eventually removed

       - current purpose of 'master' is: 

          release this code, which will be the purpose of 'production'

• 'development' is never merged into 'production'
• overtime, like feature branches, old 'production-date' branches can be deleted

pros:

• never any conflicts between 'master' eg 'production' and 'development', as only one main branch
• hotfixes can be applied to current 'production' branch without worry of later conflicts
• 'production-date' can be used as a rollback for code in case a release is non usable/broken and code related

cons:

• no 'master' branch; but 'production' and 'development' are more explicit
• no merge request to 'master'; 'production' and 'production-*' can be marked as a protected branches in GitLab
• slightly different

GitLab CI/CD:

• should still work at creation of 'production', 
• and maybe the renaming of 'production-date' and creation of 'production' could be part of the GitLab CI/CD

Tags:

An alternative to creating 'production' branches would be to create 'production' tags.  If a hotfix is needed, then create a branch from the tag.  But just keeping everything a branch simplifies: GitLab CI/CD, Git UIs, merge request for hotfix, etc

And yes, the one branch to rule them all could be named the default Git repo branch name of ‘master’.  Or 'sam', or whatever your group agrees upon, and you can tell others.

-End of Document-
Thanks for reading