引言
虽然有这么优秀的版本管理工具，但是我们面对版本管理的时候，依然有非常大得挑战，我们都知道大家工作在同一个仓库上，那么彼此的代码协作必然带来很多问题和挑战，如下：
- 1、如何开始一个Feature的开发，而不影响别的Feature？
- 2、由于很容易创建新分支，分支多了如何管理，时间久了，如何知道每个分支是干什么的？
- 3、哪些分支已经合并回了主干？
- 4、如何进行Release的管理？开始一个Release的时候如何冻结Feature, 如何在Prepare Release的时候，开发人员可以继续开发新的功能？
- 5、线上代码出Bug了，如何快速修复？而且修复的代码要包含到开发人员的分支以及下一个Release?
大部分开发人员现在使用Git就只是用三个甚至两个分支，一个是Master, 一个是Develop, 还有一个是基于Develop打得各种分支。这个在小项目规模的时候还勉强可以支撑，因为很多人做项目就只有一个Release, 但是人员一多，而且项目周期一长就会出现各种问题。
git 和 svn 的一个显著区别就是提供更丰富的分支特性，我们今天就要说一下如何使用 git 管理这些分支。
1、git常用分支
- Production 分支
也就是我们经常使用的Master分支，这个分支最近发布到生产环境的代码，最近发布的Release， 这个分支只能从其他分支合并，不能在这个分支直接修改
- Develop 分支
这个分支是我们是我们的主开发分支，包含所有要发布到下一个Release的代码，这个主要合并与其他分支，比如Feature分支
- Feature 分支
这个分支主要是用来开发一个新的功能，一旦开发完成，我们合并回Develop分支进入下一个Release
- Release 分支
当你需要一个发布一个新Release的时候，我们基于Develop分支创建一个Release分支，完成Release后，我们合并到Master和Develop分支
- Hotfix 分支
当我们在Production发现新的Bug时候，我们需要创建一个Hotfix, 完成Hotfix后，我们合并回Master和Develop分支，所以Hotfix的改动会进入下一个Release
2、分支之间工作关联
2.1、初始化主分支、创建 develop 分支
主分支包括 master 分支和 develop 分支。master 分支用来发布，HEAD 就是当前线上的运行代码。develop 分支就是我们的日常开发。使用这两个分支就具有了最简单的开发模式：develop 分支用来开发功能，开发完成并且测试没有问题则将 develop 分支的代码合并到 master 分支并发布。
这样两个分支开发会出现一些问题:
a) develop 分支只有发布完了才能进行下一个版本开发，开发会比较缓慢。
b) 线上代码出现 bug 如何进行 bug 修复
2.2、Feature 分支
feature 分支用来开发具体的功能，一般 fork 自 develop 分支，最终可能会合并到 develop 分支。比如我们要在下一个版本增加功能1、功能2、功能3。那么我们就可以起三个feature 分支：feature1，feature2，feature3。（feature 分支命名最好能够自解释，这并不是一种好的命名。）随着我们开发，功能1和功能2都被完成了，而功能3因为某些原因完成不了，那么最终 feature1 和 feature2 分支将被合并到 develop 分支，而 feature3 分支将被干掉。
从 develop 分支建一个 feature 分支，并切换到 feature 分支.
git checkout -b some-feature develop
// Optionally, push branch to origin:
git push -u origin some-feature
// 做一些改动
git status
git add some-file
git commit
开发完成后 feature 合并到 develop 分支
git pull origin develop
git checkout develop
git merge --no-ff some-feature
git push origin develop
git branch -d some-feature
//If you pushed branch to origin:
git push origin --delete some-feature
上面我们 merge 分支的时候使用了参数 --no-ff，ff 是fast-forward 的意思，--no-ff就是禁用fast-forward。关于这两种模式的区别如下图。（可以使用 sourceTree 或者命令git log --graph查看。）
看了上面的图，那么使用非fast-forward模式来 merge 的好处就不言而喻了：我们知道哪些 commit 是某些 feature 相关的。虽然 git merge 的时候会自动判断是否使用fast-farward模式，但是有时候为了更明确，我们还是要加参数--no-ff或者--ff。
2.3、Release 分支
Release分支基于Develop分支创建，打完Release分之后，我们可以在这个Release分支上测试，修改Bug等。同时，其它开发人员可以基于开发新的Feature (记住：一旦打了Release分支之后不要从Develop分支上合并新的改动到Release分支)
release 分支在我看来是 pre-master。release 分支从 develop 分支 fork 出来，最终会合并到 develop 分支和 master 分支。合并到 master 分支上就是可以发布的代码了。有人可能会问那为什么合并回 develop 分支呢？很简单，有了 release 分支，那么相关的代码修复就只会在 release 分支上改动了，最后必然要合并到 develop 分支。
创建release分支
git checkout -b release-0.1.0 develop
//Optional: Bump version number, commit
//Prepare release, commit
release分支测试完成
============测试完成后，release 合并到 master===========
git checkout master
git merge --no-ff release-0.1.0
git push
============测试完成后，release 合并到 develop ===========
git checkout develop
git merge --no-ff release-0.1.0
git push
=============删除 release分支 ============================
git branch -d release-0.1.0
//If you pushed branch to origin:
git push origin --delete release-0.1.0
=============在master分支基础上打tag====================
git tag -a v0.1.0 master
git push --tags
2.4、紧急维护分支 Hotfix
顾名思义，hotfix 分支用来修复线上 bug。当线上代码出现 bug 时，我们基于 master 分支开一个 hotfix 分支，修复 bug 之后再将 hotfix 分支合并到 master 分支并进行发布，同时 develop 分支作为最新最全的代码分支，hotfix 分支也需要合并到 develop 分支上去。仔细想一想，其实 hotfix 分支和 release 分支功能类似。hotfix 的好处是不打断 develop 分支正常进行，同时对于现实代码的修复貌似也没有更好的方法了（总不能直接修改 master 代码吧:D）。
创建Hotfix分支
git checkout -b hotfix-0.1.1 master
Hotfix分支修复完成
============buf fix 之后，hotfix 合并到 master===========
git checkout master
git merge --no-ff hotfix-0.1.1
git push
============buf fix 之后，hotfix 合并到 develop =========
git checkout develop
git merge --no-ff hotfix-0.1.1
git push
=============删除 hotfix分支 ============================
git branch -d hotfix-0.1.1
=============在master分支基础上打tag======================
git tag -a v0.1.1 master
git push --tags
参考:
