Git branching model

Most importantly, what you eventually use is team specific. Your team must decide what works best for their use-case, their maturity, and experience.

This article describes what there is out there and helps you by deciding.

Common, but not well-aged: git-flow

In 2010 there was a well-received article "A successful Git branching model". This one is commonly referred to as "git-flow".

In short, it says there is a master branch, a develop branch and a couple of others like feature, release, and hotfix branches.

However nowadays this working model fell a bit out of age also due to its complexity, therefore it is commonly agreed that there is a simpler approach:

Nowadays widely adopted: GitHub flow

In a nutshell, following the GitHb flow means:

• the main branch must always contain deployable, working software
• features under development live in a feature/ branch, are maturing there while being worked on. Once considered finished, they get merged to main via a Pull/Merge Request.

You probably want to consider to merge feature branches using squash.

Prior to merging, your CI/CD chain can run all the tests on the feature branch and check whether it would break master if it was merged. Besides, it gives an opportunity to do a code review before merging. Other teams might decide that a review can be replaced if you do pair-programming anyways, hence following a two-man rule anyways.