文章目录
- 分支管理策略
- 分支策略
- 小结
- Bug分支
- 小结
分支管理策略
通常，合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。
如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。
下面我们实战一下--no-ff方式的git merge：
首先，仍然创建并切换dev分支：
git checkout -b dev
输出：
Switched to a new branch 'dev'
D readme.txt
修改readme.txt文件，并提交一个新的commit：
git add readme.txt
git commit -m "add merge"
输出如下：
[dev e18b34d] add merge
1 file changed, 1 deletion(-)
delete mode 100644 readme.txt
切换回master：
$ git checkout master
输出：
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 4 commits.
(use "git push" to publish your local commits)
合并dev分支，请注意--no-ff参数，表示禁用Fast forward：
$ git merge --no-ff -m "merge with no-ff" dev
输出如下：
Removing readme.txt
Merge made by the 'recursive' strategy.
readme.txt | 1 -
1 file changed, 1 deletion(-)
delete mode 100644 readme.txt
因为本次合并要创建一个新的commit，所以加上-m参数，把commit描述写进去。
合并后，用git log看看分支历史：
git log --graph --pretty=oneline --abbrev-commit
输出如下：
* 8cf7203 (HEAD -> master) merge with no-ff
|\
| * e18b34d (dev) add merge
|/
* 1d26147 conflict fixed
|\
| * ab01e68 AND simple
* | 5f74c5d & simple
|/
* d03e35c branch test
* ee37c08 (origin/master) wrote a readme.txt
分支策略
在实际开发中，我们应该按照几个基本原则进行分支管理：
首先，master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；
小结
Git分支十分强大，在团队开发中应该充分应用。
合并分支时，加上--no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并。
Bug分支
在Git中，由于分支是如此的强大，所以，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。
Git还提供了一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作：
git stash
输出如下：
Saved working directory and index state WIP on master: 8cf7203 merge with no-ff
用git status查看工作区，就是干净的（除非有没有被Git管理的文件），因此可以放心地创建分支来修复bug。
首先确定要在哪个分支上修复bug，假定需要在master分支上修复，就从master创建临时分支：
git checkout master
输出如下：
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 6 commits.
(use "git push" to publish your local commits)
创建分支issue-101:
git checkout -b issue-101
现在修复bug，需要将readme.txt文件内容加一行 “Git is a free software.” 然后提交：
修复好以后，切换到master分支，完成合并，最后删除issue-101分支：
git checkout master
git merge --no-ff -m "merged bug fix 101" issue-101
git checkout -d issue-101
查看刚刚保存的工作现场：
git stash list
输出如下：
stash@{0}: WIP on master: 8cf7203 merge with no-ff工作现场还在，Git把stash内容存在某个地方了，但是需要恢复一下，有两个办法：
一是用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除；
另一种方式是用git stash pop，恢复的同时把stash内容也删了.
再用git stash list查看，就看不到任何stash内容了。
可以多次stash，恢复的时候，先用git stash list查看，然后恢复指定的stash，用命令：
git stash apply stash@{0}小结
修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除；
当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复后，再git stash pop，回到工作现场。
