GIT branch Management

Purpose

This article describes how to use Git to develop and publish projects. What branches are created and how they are handled in various scenarios.

Original: http://nvie.com/posts/a-successful-git-branching-model/ flowchart

Branch Introduction There are two main branches on the origin server: There are five types of branches on the master and Develop development servers: In addition to master and develop, there are feature branches, release Branches and hotfix branches

The Master Master Branch is used to release a stable version of the branch, and each release will be tagged. Rigorous testing is required for each commit on the master branch. Only the release and hotfix branches can merge to the Master Branch develop develop branch is used to store the code churn for the next release. All feature branches are based on develop, and only the feature of the next release will merge to the develop branch. Feature released later do not merge to the develop branch when deciding to release the next version, pull a release branch from the develop branch while determining the version name. such as: release-1.2 feature Branches

May branch off from:
develop
must merge back to:
Develop

Each feature development is based on the develop pull a new branch name can be: Dbg_username_featurename

git checkout-b dbg_gyf_myfeature Develop

After the feature development is complete, if you decide to release it in the next release, merge back to develop

$ git checkout develop switched to branch ' develop ' $ git merge--no-ff dbg_gyf_myfeature Updating ea1b82a.
05e9557 (Summary of changes) $ git branch-d dbg_gyf_myfeature Deleted branch Dbg_gyf_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 is performed with a FAs T-forward. This avoids losing information on the historical existence of a feature branch and groups together all commits that tog Ether added the feature. Compare: in the latter case, it's impossible to see from the Git history which of the commit objects together had I Mplemented a feature-you would has to manually read all the log messages. Reverting a whole feature (i.e. a group of commits), is a true headache in the latter situation, whereas it was easily done If the--NO-FF flag was used. Release Branches

May branch off from:
develop
must merge back to:
Develop and master
branch
naming convention: release-*

The release branch is used to make the release. When develop has a release condition, pull the Releae branch from develop and decide the version name

$ git checkout-b release-1.2 develop
switched to a new branch "release-1.2"
$./bump-version.sh 1.2
Files MoD Ified successfully, version bumped to 1.2.
$ git commit-a-M "bumped version number to 1.2"
[release-1.2 74d9424] bumped version number to 1.2
1 files Cha Nged, 1 insertions (+), 1 deletions (-)

Bump-version.sh used to change the version number in the source code to 1.2 once the release branch pulls out, it is no longer allowed to add large feature changes, only the bug Fix,fix changes can only merge to the release branch. such as the official release completed, and then unified merge back to develop release test completed, you can make the release to the master branch, while playing tag

$ git checkout master
switched to branch ' master '
$ git merge--no-ff release-1.2
merge made by recursive.
  
    (Summary of changes)
$ git tag-a 1.2

  

and merge back to the develop branch.

$ git checkout develop
switched to branch ' develop '
$ git merge--no-ff release-1.2
merge made by recursive.
   (Summary of changes)

Delete Release Branch

$ git branch-d release-1.2
Deleted Branch release-1.2 (was Ff452fe).

Hotfix Branches

May branch off from:
Master
must merge back into:
Develop and master
Branch naming convention:
hotfix-*

When the master branch has been issued and a serious problem is found and requires an emergency fix, you need to pull a hotfix branch from master to change

$ git checkout-b hotfix-1.2.1 master
switched to a new branch "hotfix-1.2.1"
$./bump-version.sh 1.2.1
Files Modified successfully, version bumped to 1.2.1.
$ git commit-a-M "bumped version number to 1.2.1"
[hotfix-1.2.1 41E61BB] bumped version number to 1.2.1
1 files Changed, 1 insertions (+), 1 deletions (-)
$ git commit-m "Fixed severe production problem"
[hotfix-1.2.1 Abbe5d6] Fixed Severe production problem
5 files changed, insertions (+), deletions (-)

After the repair is complete, merge back to the master branch

$ git checkout master
switched to branch ' master '
$ git merge--no-ff hotfix-1.2.1
merge made by recursive.
   (Summary of changes)
$ git tag-a 1.2.1

If the release branch has delete:merge back to the develop branch

$ git checkout develop
switched to branch ' develop '
$ git merge--no-ff hotfix-1.2.1
merge made by recursive.< c9/> (Summary of changes)

If the release branch still exists, there is no merge back to Develop:merge hotfix to the release branch, then unify merge release to develop and then delete the hotfix branch

$ git branch-d hotfix-1.2.1 Deleted branch hotfix-1.2.1 (was Abbe5d6).