Skip to content

Latest commit

 

History

History
87 lines (57 loc) · 3.09 KB

GIT_BRANCHING.md

File metadata and controls

87 lines (57 loc) · 3.09 KB
Raw

Git Branching rules

We are following the development model branching mechanism of Vincent Driessen.

https://nvie.com/posts/a-successful-git-branching-model/

master branch

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

develop branch (aka “integration branch”)

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.

release branches

May branch off from:
    develop
Must merge back into:
    develop and master
Branch naming convention:
    release-*

Release branches support preparation of a new production release. They allow for last-minute dotting of i’s and crossing t’s. Furthermore, they allow for minor bug fixes and preparing meta-data for a release (version number, build dates, etc.). By doing all of this work on a release branch, the develop branch is cleared to receive features for the next big release.

The key moment to branch off a new release branch from develop is when develop (almost) reflects the desired state of the new release. At least all features that are targeted for the release-to-be-built must be merged in to develop at this point in time. All features targeted at future releases may not—they must wait until after the release branch is branched off.

hotfix branches

May branch off from:
    master
Must merge back into:
    develop and master
Branch naming convention:
    hotfix-*

Hotfix branches are very much like release branches in that they are also meant to prepare for a new production release, albeit unplanned. They arise from the necessity to act immediately upon an undesired state of a live production version. 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.

The essence is that work of team members (on the develop branch) can continue, while another person is preparing a quick production fix.

feature branches

May branch off from:
    origin/develop 
Must merge back into:
    origin/develop 
Branch naming convention:
    anything except master, develop, release-*, or hotfix-*

Creating a feature branch

When starting work on a new feature, branch off from the develop branch.

$ git checkout -b myfeature develop
Switched to a new branch "myfeature"

Incorporating a finished feature on develop

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

$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff myfeature
Updating ea1b82a..05e9557
(Summary of changes)
$ git branch -d myfeature
Deleted branch myfeature (was 05e9557).
$ git push origin develop

The --no-ff flag causes the merge to always create a new commit object, even if the merge could be performed with a fast-forward. This avoids losing information about the historical existence of a feature branch and groups together all commits that together added the feature.