Question

I have read about multiple different git branching strategies and I was suprized that the master branch was often used as a ‘production-ready’ branch and there would be an additional uat and dev branch.
I’m thinking to set up our git repository with the same 3 branches, but to let ‘master’ contain the dev code and add a production and uat branch. That way, developers can simply merge to the default git branch (being ‘master’). Is there a reason not to do it like that?

gr,

Coen

Answer 1

There is no specific reason not to pick one workflow over another, with Git it’s usually left to the discretion of the development team to decide their best practice.

The production-ready master approach you mentioned often has more than one dev branch (sometimes called feature branches), master is then chosen as the final place to put all these since there should typically be only one master branch (and often only one production build).

This is how many companies work, but certainly not all. Many others use an “unstable master” approach, which follows a similar pattern to the one you mention – some instead have a production repository, their own master and branches are considered unstable, and the team leader pushes to the production repo when code in a particular branch is considered production ready.

The key aspect in Git here is that everyone has their own local repository, with their own branches and master. This allows them to create their own private branches any time they want, for whatever evil purposes they see fit, but it does make defining the purpose of branch names more difficult to enforce.