top of page

THINGS ABOUT SOFTWARE DEVELOPMENT

Home: Welcome
Home: Blog2
Search

Git Branching Model (Simplified)

Writer: ZeCoderZeCoder

Updated: Mar 11, 2021

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




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




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




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




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





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





Someone directed me to an interesting article about an "Enhanced git flow" which I found interesting.

 
 
 

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