分支是什么？
分支就像树分出的树枝，不同的是，它们之间可以互相合并。
将版本的推进想象成一个链表的伸长： version 1.0 ==》 version 2.0 ==》version3.0 。
master是主要的分支基本上用于发布产品。你可以从master分出一个dev，在上面创建新功能，或者修bug然后调试。最后再合并到master里面。就像下面这样。
master分支: version 1.0=========》version 2.0===...
\ / (merge)
dev分支: \=version 1.5=/=========...
甚至还可以有更多分支
master分支: version 1.0=========》version 2.0===...
\ / (merge)
dev分支 : \→→→O→→→→ O=========...
\ / (merge)
Hanson分支: \ -> 修BUG ->/
分支不主动删除是不会消失的。
（另外，当前版本可以认为是一个指针指向链表最后一个节点，reset (第二章) 命令 就是把指针往前移，revert命令还是向后移。 ）
如何管理分支？
1.创建与查看分支：
现在我们要创建一个名为dev的分支。（Dev在软件开发中多用于开发软件的代号，与Beta(测试版)的意思相近，其意思为"开发中的版本" 即development version或development edition etc。）创建分支的命令是 $git branch dev 移动到指定分支的命令是 $git checkout dev
也有一个将两个命令合起来的简便方法：$git checkout -b dev 这样就直接创建并转到分支dev上。（相当于当前master版本的一个副本。）
在windows上的git bash上可以通过每行命令上面那行最后的括号确定现在是哪个分支。在linux上没有。
那如何查看当前有哪些分支和确定在哪条分支上呢? 输入 :$git branch ,会列出所有分支，分支前面的星号就是当前所在分支。
$git branch
*dev
master
2.合并与删除分支：
将工作区内容修改后 使用 $git add hello.txt 和 $git commit hello.txt -m "modify" 上传就dev分支
然后 $git checkout master 切换到master分支后，输入 $git merge dev 这样dev就会融入master。
若是想删除掉dev分支 输入$ git branch -d dev 即可。(如果没有合并就想要废弃这条分支 需要使用$git branch -D dev)
在使用merge命令时，可以添加参数 -m "blabla" 也就是添加备注。
还有一个参数是 --no-ff :
顾名思义 这个参数的意思是 不要FF模式。
FF 即 fast forward ,这种模式下，删除分支后，会丢掉分支信息。 就像这个分支从来没存在过一样。
而如果使用 --no-ff 就会我开头举的例子，Hanson分支被删除后仍然存在于记录中。会在merge时生成一个新的commit 。
这条命令会是这样
git merge --no-ff -m "merge with no-ff" Hanson
另外还有一些原则需要遵守
master分支应该是非常稳定的，也就是仅用来发布新版本，平时不能在上面干活；
那在哪干活呢？干活都在dev分支上，也就是说，dev分支是不稳定的，到某个时候，比如1.0版本发布时，再把dev分支合并到master上，在master分支发布1.0版本；
你和你的小伙伴们每个人都在dev分支上干活，每个人都有自己的分支，时不时地往dev分支上合并就可以了。
或许你已经想到了这个问题 “要是合并的时候有冲突怎么办？”
比如两个分支不约而同地修改了同一行。 在master上 你改了 hello.txt 最后一行，在dev上也改了hello.txt最后一行都提交上去了。
git是这样做的:合并的时候git发现了这样的冲突，它只好试图将两行合起来，并 提示你：
Auto-merging hello.txt
CONFLICT (content): Merge conflict in hello.txt
Automatic merge failed; fix conflicts and then commit the result.
你从这知道 需要你手动更改文件合并 然后提交。
输入$git status 可以查看冲突的文件
# On branch master
# Your branch is ahead of ‘origin/master‘ by 1 commits. （这一句是说当前的master超前远程仓库的master一个commit）
#
# Unmerged paths:
# (use "git add/rm <file>..." as appropriate to mark resolution)
#
# both modified: hello.txt
#
no changes added to commit (use "git add" and/or "git commit -a")打开对应的 hello.txt 文件 发现你分别修改的两行是以这样的形式存在在文件中：
<<<<<<< HEAD
………的……
=======
………地……
>>>>>>> dev这样就标记了不同的分支中的内容 然后需要你手动更改并 $git add hello.txt 与commit -m 提交。
使用 $git log带参数可以看到合并情况 关于参数以后再详细记录笔记。
$ git log --graph --pretty=oneline --abbrev-commit3.临时储存工作现场
你常常会遇到这样的情况，你正在自己的分支上做一个新功能，但是有一个BUG需要在一小时内解决。你不可能直接切换到一个新分支来修复bug，这样你做了大半天的工作就没了。也不可能在这个分支上修复提交，因为等你新功能写完还得好久。
输入 $ git stash save "work in progress for foo feature" （save命令是用于备注，并非必须）吧 你会发现工作区变成了当前分支上次提交的样子，这时候你就可以放心的创建分支修复BUG了。
修复之后，你想回到dev继续工作了！
输入 $git stash list
下面就会显示stash的列表，像这样：[email protected]{0}: WIP on dev: …………
怎么恢复呢？有两个办法：
一是用git stash apply恢复，但是恢复后，stash内容并不删除，你需要用git stash drop来删除，
默认是恢复最后一次保存。如果你多次保存，想恢复前面保存的现场。就得根据stash list找到前面的标志恢复，像这样
git stash apply [email protected]{1} ;
另一种方式是用$git stash pop，恢复的同时把stash内容也删了，这种方法只能恢复最后一次stash。
$git stash clear 用于清除stash列表。
Git 学习笔记<分支管理> (三)