补充：
GIT 分支管理：创建与合并分支、解决合并冲突、分支管理策略
下面开始实战。
-
首先，我们创建dev分支，然后切换到dev分支：
$ git checkout -b devgit checkout命令加上-b参数表示创建并切换，相当于以下两条命令：
$ git branch dev $ git checkout dev然后，用git branch命令查看当前分支：
$ git branch
git branch命令会列出所有分支，当前分支前面会标一个*号。
-
然后，我们就可以在dev分支上正常提交，比如对readme.txt做个修改，加上一行
然后提交：$ git add readme.txt $ git commit -m "create new branch...." -
现在，dev分支的工作完成，我们就可以切换回master分支：
$ git checkout master
切换回master分支后，再查看一个readme.txt文件，刚才添加的内容不见了！因为那个提交是在dev分支上，而master分支此刻的提交点并没有变:
现在，我们把dev分支的工作成果合并到master分支上：
$ git merge dev
git merge命令用于合并指定分支到当前分支。合并后，再查看readme.txt的内容，就可以看到，和dev分支的最新提交是完全一样的。
注意到上面的Fast-forward信息，Git告诉我们，这次合并是“快进模式”，也就是直接把master指向dev的当前提交，所以合并速度非常快。
当然，也不是每次合并都能Fast-forward，我们后面会讲其他方式的合并。
合并完成后，就可以放心地删除dev分支了：
$ git branch -d dev
删除后，查看branch，就只剩下master分支了：
$ git branch
因为创建、合并和删除分支非常快，所以Git鼓励你使用分支完成某个任务，合并后再删掉分支，这和直接在master分支上工作效果是一样的，但过程更安全。
小结:
- 查看分支：git branch
- 创建分支：git branch
- 切换分支：git checkout
- 创建+切换分支：git checkout -b
- 合并某分支到当前分支：git merge
- 删除分支：git branch -d
解决冲突
人生不如意之事十之八九，合并分支往往也不是一帆风顺的。
准备新的feature1分支，继续我们的新分支开发：
$ git checkout -b feature1
修改readme.txt内容
在feature1分支上提交：
$ git add readme.txt
$ git commit -m "create new branch feature1 first modify"
切换到master分支：
$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 1 commit.
(use "git push" to publish your local commits)
Git还会自动提示我们当前master分支比远程的master分支要超前1个提交。
在master分支上把readme.txt文件进行修改：
提交：
$ git add readme.txt
$ git commit -m "goback master first modify"
现在，master分支和feature1分支各自都分别有新的提交，变成了这样：
这种情况下，Git无法执行“快速合并”，只能试图把各自的修改合并起来，但这种合并就可能会有冲突，我们试试看：
$ git merge feature1
果然冲突了！Git告诉我们，readme.txt文件存在冲突，必须手动解决冲突后再提交。git status也可以告诉我们冲突的文件：
$ git status
我们可以直接查看readme.txt的内容：cat readme.txt
将里面的符号内容进行手动删除
再提交：
$ git add readme.txt
$ git commit -m "fixed conflicts"
现在，master分支和feature1分支变成了下图所示：
用带参数的git log也可以看到分支的合并情况：
$ git log --graph --pretty=oneline --abbrev-commit
最后，删除feature1分支：
$ git branch -d feature1
小结
- 当Git无法自动合并分支时，就必须首先解决冲突。解决冲突后，再提交，合并完成。
- 用git log --graph命令可以看到分支合并图。
分支管理策略
通常，合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。
- 如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。
下面我们实战一下–no-ff方式的git merge：
-
首先，仍然创建并切换dev分支：
$ git checkout -b dev
修改readme.txt文件，并提交一个新的commit：
$ git add readme.txt
$ git commit -m "add merge"
-
现在，我们切换回master：
$ git checkout master -
准备合并dev分支，请注意–no-ff参数，表示禁用Fast forward：
$ git merge --no-ff -m "merge with no-ff" dev
因为本次合并要创建一个新的commit，所以加上-m参数，把commit描述写进去。
合并后，我们用git log看看分支历史：
$ git log --graph --pretty=oneline --abbrev-commit
可以看到，不使用Fast forward模式，merge后就像这样：
分支策略
小结
- Git分支十分强大，在团队开发中应该充分应用。
- 合并分支时，加上–no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并。
Bug分支(拓展，可以自己试试)
软件开发中，有了bug就需要修复，在Git中，由于分支是如此的强大，所以，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。
eg:当你接到一个修复一个代号101的bug的任务时，你想创建一个分支issue-101来修复它，但是，当前正在dev上进行的工作还没有提交：
$ git status
Git还提供了一个stash功能，可以把当前工作现场“储藏”起来，等以后恢复现场后继续工作：
$ git stash
现在，用git status查看工作区，就是干净的（除非有没有被Git管理的文件），因此可以放心地创建分支来修复bug。
首先确定要在哪个分支上修复bug，假定需要在master分支上修复，就从master创建临时分支：
$ git checkout master
$ git checkout -b issue-101
修改readme.txt文件
$ git add readme.txt
$ git commit -m "fix bug 101"
修复完成后，切换到master分支，并完成合并，最后删除issue-101分支：
$ git checkout master
$ git merge --no-ff -m "merged bug fix 101" issue-101
接着回到dev分支
$ git checkout dev
$ git status
工作区是干净的，刚才的工作现场存到哪去了？用git stash list命令看看：
$ git stash list
工作现场还在，Git把stash内容存在某个地方了，但是需要恢复一下，有两个办法：
-
一是用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除；
-
另一种方式是用git stash pop，恢复的同时把stash内容也删了：
$ git stash pop
再用git stash list查看，就看不到任何stash内容了：
$ git stash list
你可以多次stash，恢复的时候，先用git stash list查看，然后恢复指定的stash，用命令：
$ git stash apply stash@{0}
小结
- 修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除；
- 当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复后，再git stash pop，回到工作现场。