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
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.
The key concept to understand with a DVCS (Distributed Version control System) is that you don't have one workflow (merges between branches), but two: publication (push/pull) between repositories.
See "What git branching models actually work?"
That means you will clone repositories around, and for each clone, what you want to ask is:
If I clone a repo "by default" (no special parameters), what content do I want to see?
That content, out of all the possible branches contained by the cloned repo, will be your 'master' branch.
And you can change that "branch by default": see "Git: Correct way to change Active Branch in a bare repository?".
So if you have a repo dedicated for development, the master branch will represents the latest code "that work", with other branches for various "experiments" in progress.
That is basically what the Git repo itself follows: See "Git/Git Workflow".
But any other clone can be dedicated for other development life-cycle step (uat -- user acceptance test, sit -- system integration test, -- pre-prod or prod).
In that case, their 'master' branch will have a different meaning, adapted to the role played by that repo.
I think a good starting place for this is to actually read Git's recomended workflow document. They talk about using master as stable, and feature branches.
An excerpt:
Graduation ~~~~~~~~~~
As a given feature goes from experimental to stable, it also "graduates" between the corresponding branches of the software.
git.gituses the following 'integration branches':
'maint' tracks the commits that should go into the next "maintenance release", i.e., update of the last released stable version;
'master' tracks the commits that should go into the next release;
'next' is intended as a testing branch for topics being tested for stability for master.
There is a fourth official branch that is used slightly differently:
- 'pu' (proposed updates) is an integration branch for things that are not quite ready for inclusion yet (see "Integration Branches" below).
Each of the four branches is usually a direct descendant of the one above it.
Conceptually, the feature enters at an unstable branch (usually 'next' or 'pu'), and "graduates" to 'master' for the next release once it is considered stable enough.
It all depends on the comfort of the developers. You can go ahead with the approach what you explained. Also there can be multiple branches for making the commits based on sprints or any other methodology. Every time you are about to deploy the code in production, merge the specific branches on which the commits have been pushed and way to go .
