GIT

Git Branching

Oct 22, 2019

Best practice for the Git Branching and what is the key usage and difference between each.

For the Git workflow, branches can be differentiated:

  • Feature: All features/new functions/major refactoring should be done in feature branches, which branch off of and are merged back into the develop branch (usually after some kind of peer review).

  • Release: When enough features have accumulated or the next release time frame comes near, a new release branch is branched off of develop, which is solely dedicated to testing/bug fixing and any cleanup necessary (e.g. changing some path names, different default values for instrumentation etc.).

  • Master: Once the QA is satisfied with the quality, the release branch is merged into master (and also back to develop). This is then what is shipped/used by the customers.

  • Hotfix: If a major problem is found after release, the fix is developed in a hotfix branch, that is branched off of the master. Those are the only branches that will ever branch off of master.

 

Note: Any commit in the master is a merge commit (either from a release or a hotfix branch) and represents a new release that will be shipped to the customer. master and develop branches should be protected branches which will prevent direct commit. All the changes must be incorporate via pull requests only.

Please be aware that this model is mainly meant for:

  • big software projects that follow
  • classic release versioning and
  • have a separate QA team

Many popular repositories on GitHub follow a simpler model.

TAGS GIT-Branch
Raviraj Patel

About the Author

Raviraj Patel

A results-driven, customer-focused, articulate and analytical Senior Software Engineer who can think “out of the box”. Strong in design and integration of problem-solving skills. Expert in C#, .Net Core, Web API, ASP.NET, jQuery, SQL Server, SSIS, SSRS.

Skilled in developing business plans, requirements specifications, user documentation and architectural systems research.