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

All these practices eventually point to one goal - to deploy your code on production or more generally speaking, release a version of your product as quick as possible. You almost always never want to mess with your master branch that is used to deploy production. A clean and QA approved feature branch is all that is to be merged into master, nothing less (unless your are doing some basic refactoring).

With a separate develop branch you don’t have the risk of unnecessary commits made by developers just for testing on the prod master. On most occasions, the feature branches your developers create would need to have a set of commits just for testing. Doesn’t really make sense to change a flag or add a log just for debugging in the prod master branch right? You just dump your commits on the develop branch and go on with your testing. But leave a cleaner history in the prod master branch only making commits that code the logic. If at all you want to track a particular feature and its development workflow after the code has been deployed, you will have a neater and lesser set of meaningful commits to look at in the prod master. It just becomes a heck lot easier and enables your team to put lesser time into such issues.

Also, with a separate develop branch, you need not worry about your developers committing code to it while you are deploying production. Not to mention the QA’s job becomes much easier with a separate develop branch.

Answer 2

If you want to denote a release that's ready for QA, the idiomatic way to do that in git is with a tag. Whereas other SCM tools such as ClearCase or Accurev use hierarchy to denote stages of develop/test/release, I have never needed this on any of my projects or teams, nor do I foresee it. The main purpose of git branches is to accomplish parallelism. If the only parallelism is between different development efforts, your branchA and branchB branches should be sufficient.

Answer 3

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.