top of page

THINGS ABOUT SOFTWARE DEVELOPMENT

Home: Welcome
Home: Blog2
Search

Git Branching Model (Simplified)

  • Writer: ZeCoder
    ZeCoder
  • Feb 25, 2020
  • 2 min read

Updated: May 3

This is a common branching model used successfully by many development teams. It was surprising to find teams that were not aware of this model.


So here is it again, enjoy :)


Overview


ree


Main Branches


master is the main branch where the source code of HEAD always reflects a production-ready state


develop is the main branch where the source code of HEAD always reflects a state with the latest delivered development changes for the next release. It is also known as an “integration branch” – This is where any automatic nightly builds are built from


ree


Feature Branches


Feature branches names should have a well defined structure e.g. feature/[some-unique-id]/[short-title]

Talk with your team and come up with something that make sense to you. Feature branches are used to develop new features for the upcoming or a distant future release. The essence of a feature branch is that it exists as long as the feature is in development, but will eventually be merged back into develop or discarded



ree

Release (Stabilization) Branches


Stabilization branches names also should have a well defined structure e.g. release/0.1.0


Release branches support preparation of a new production release. Another term used to describe these branches is “Code Freeze”. No additional features will be delivered to these branches. Release branches allow for minor bug fixes and preparing meta-data for a release (version number, build dates, etc.). All changes to the stabilization branch must be merged back to the develop branch



ree

Bug Fix Branches


Bug fix branches are treated like features with well defined names e.g. bugfix/[some-unique-id]/


Bug fix branches are used to fix bugs in the development and release branches. The essence of a bug fix branch is that it exists as long as the bug fix is not confirmed, fix could be merged back into develop/release or discarded



ree


Hotfix Branches


Same as the other branches, Hotfix branch names should have a well defined structure e.g. hotfix/[some-unique-id]/[short-title]


Hotfix branches are very much like stabilization branches in that they are also meant to prepare for a new production release, albeit unplanned. When a critical bug in a production version must be resolved immediately, a hotfix branch may be branched off from the corresponding tag on the master branch that marks the production version. These branches must merge back into develop & master branches


We should avoid using hotfixes unless really really necessary



ree


 
 
 

Recent Posts

See All
5 Levels of Maturity

I remembered a lecture I attended a while back about the Capability Maturity Model (CMM) and I thought I write my version of it from my...

 
 
 
Development Priorities

When developing software there are many things that need to be done: features, bugs, testing, etc. and not all of them have the same...

 
 
 
Software Development Roles

Who are those people that actually do the development work? I've worked for companies that had a nicely defined hierarchy of roles and...

 
 
 

Comments


Subscribe Form

Home: Subscribe
Home: Contact
  • facebook
  • twitter
  • linkedin

©2020 by OfirNoy. Proudly created with Wix.com

bottom of page