Tuesday, December 5, 2017

GIT Branching Model

Idea Extracted from this website as I had the liberty to learn from it and apply it to my personal projects as well as in some of the organizations I work for.

The details are summarized as follows:


Overall picture:




Main branches:

  • MASTER 
  • DEVELOP


We consider origin/master to be the main branch where the source code of HEAD always reflects a production-ready state

We consider origin/develop to be the main branch where the source code of HEAD always reflects a state with the latest delivered development changes for the next release. Some would call this the “integration branch”. This is where any automatic nightly builds are built from

When the source code in the develop branch reaches a stable point and is ready to be released, all of the changes should be merged back into master somehow and then tagged with a release number.

Other Branches

  • Feature branches
  • Release branches
  • Hotfix branches


Unlike the main branches, these branches always have a limited life time, since they will be removed eventually.

Feature:
May branch off from: develop Must merge back into: develop

Finished features may be merged into the develop branch to definitely add them to the upcoming release.

Release:
May branch off from: develop Must merge back into: develop and master
It is exactly at the start of a release branch that the upcoming release gets assigned a version number—not any earlier.
This new branch may exist there for a while, until the release may be rolled out definitely. During that time, bug fixes may be applied in this branch (rather than on the develop branch).

When the state of the release branch is ready to become a real release, some actions need to be carried out. First, the release branch is merged into master (since every commit on master is a new release by definition, remember). Next, that commit on master must be tagged for easy future reference to this historical version

Finally, the changes made on the release branch need to be merged back into develop, so that future releases also contain these bug fixes.

Hotfix:
May branch off from: master Must merge back into: develop and master

When finished, the bugfix needs to be merged back into master, but also needs to be merged back into develop, in order to safeguard that the bugfix is included in the next release as well. 

No comments:

Post a Comment