Git best practice one or multiple branches

Question

I'm currently working in a remote team with multiple developers. We're all from different locations. Sometimes or most of the time we work on different things, sometimes on the same things.

If for instance I'm working on a feature A (on branchA) and my colleague is working on a feature B (on branchB), what would be the best practice to commit our work.

1. Merge branchA to master, build/execute tests/deploy
2. Merge branchB to master, build/execute tests/deploy

or

Branch off branch name develop of master and then merge branchA and branchB onto it, then build/execute tests.

If all goes well do the step 1 and 2 and deploy the master to the prod.

I mean using a develop it's a way of getting features from multiple branches into a single release for QA.

But using develop branch, you get one more extra branch to maintain and you basically merge the same branches to master again.

What are the approaches that work for your company/similar situations? Are there best practices regarding these situations?

Answer 1

Using feature branches (branchA and branchB) is excellent practice.

In general, a production project should have a separation between staging/QA and production. Whether you do this in version control or with system packages or whatever is up to your project.

If you choose to separate staging from production in Git, I would recommend making master the development tree and production the production tree. Why? Developers are going to habitually merge to master, all the docs talk about merging to master, don't fight it.

A production branch isn't a big maintenance problem. Mostly you'll be doing simple merges to master which should be fast forwards, this are extremely easy and cheap in Git. You might want to force a merge to record each time production was updated, or you can use tags. The important thing is merging from master to production should only be done by a release manager, not by random developers (in a small shop a developer might also be a release manager).

Another benefit of a production branch is recording hot patches. If there's a production emergency and master is not ready for production you can commit a hot patch directly to production. Then that hot patch can be cherry picked back into master for proper testing.

You may wish to have three branches. master for development, staging for QA, and production for production. master is merged into staging and, assuming it passes tests, staging is merged to production. This gives QA a stable branch to work on while production remains a faithful reproduction of what is in production.

You could also implement this with tags, have a staging and production tag that you move around, but this isn't as flexible as a full branch. Tags in Git are just branches that don't move, and you will want to move these tags. Hot patching and cherry-picking is harder with tags, and if master rebases there will be problems.

The basic workflow is...

feature_branch <---> master --QA--> staging --Release Manager--> production

Note that merging is always one way, except between feature branches and master.

The production emergency workflow is...

staging + hot patch --Release--> production --cherry pick--> feature_branch

...and then normal flow from the feature_branch. By patching staging first you can at least run it through an expedited QA process. The hot patch may cause conflicts in the next staging merge, so get a proper patch through development ASAP.