Git branch best practices - master, production, staging?

Question

I'm trying to understand the purpose of the master branch. Every new repo starts with one, I've worked several jobs where the master branch was never touched after the repo's initialization and production was the final branch that deployed to production. eg

somefeature => qa => staging => production ==> deploy

or even without a qa branch:

somefeature => staging (acting as qa) => production ==> deploy

Given that there are no hard rules, what is a reasonably common approach to branches, particularly staging, production and master?

Answer 1

There are a variety of common branching approaches, and which one you use depends on your needs.

If you're running your own source code, you may be fine with a single main branch (such as master ). In such a model, you create a PR and get all required approvals. You then deploy outside of your branching system using a separate deploy tool, such as a bot, and merge into the main branch when your code is stable. GitHub uses this system.

You may also wish to use a tiered branching model where a PR gets merged into a sequence of branches, first a development branch, then a QA branch, a staging branch, and a production branch. The latter may or may not be called master .

If you're working on a release-based project, you can have a single development branch into which most code merges and one or more release branches where fixes get cherry-picked if necessary. This is the model many open-source projects use, such as Git LFS. Git uses a similar strategy, but with additional branches where changes "cook" until they are considered stable.

There are other, more complicated workflows, such as Git Flow, which may or many not meet your needs. One thing to consider with a branching strategy is, if you have multiple branches, how you're going to get code through the stages. You may want to have a bot or tool that guides things through the stages after the initial PR or branch, since otherwise it's easy for things to get lost.

What's important is that you document your workflow clearly so everyone knows how it works and that you be willing to revisit your workflow if it doesn't meet your needs anymore. You may find that parts of your workflow other than your branching strategy may need to change if things aren't working for you, and it's okay to make those changes if that works better for your project or organization.

But overall, it's hard to make a one-size-fits-all recommendation.

Answer 2

If you are not familiar with git-flow, that is a very reasonable branching strategy:

https://nvie.com/posts/a-successful-git-branching-model/

Regarding the master branch, keep in mind that "master" is simply the default name assigned to the first branch of a git repo. Nothing more, nothing less.