Git进阶-分支管理
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 分支并发布。
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 分支将被干掉。
feature分支与develop分支关联流程图
从 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查看。）
--no-ff区别图
看了上面的图，那么使用非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分支流程图
创建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分支流程图
创建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
参考文章：https://www.jianshu.com/p/43302a72c399