分支策略管理
通常我们在合并分支的时候，git 会使用 fast-forward模式类合并，但是这种合并方式有一个缺陷：合并分支以后，删除分支，分支的历史记录就看不到了。为了方便后面查看合并的信息，我们使用 --no-f方式禁用fast-forward 模式，这样，哪怕分支删除了，也能看到历史分支信息
创建新的分支 dev , 在 README 文件中增加 “ 分支策略管理”字样，然后提交到 dev 分支，切换回 master 分支 合并。
$ git merge --no-f -m "--no-f 分支管理策略" dev
Merge made by the 'recursive' strategy.
README.md | 1 +
1 file changed, 1 insertion(+)
合并以后，查看 分支信息。git log --graph --pretty=oneline --abbrev-commit
$ git log --graph --pretty=oneline --abbrev-commit
* 833b087 (HEAD -> master) --no-f 分分支管理策略
|\
| * bfd0415 新增分支管理策略文字
|/
* f830213 (origin/master, origin/HEAD) merge
|\
| * fe4a7e8 dev
* | 34ed366 master
能够很直观的看出我们在已经被删除的 dev 分支做过 新增分支管理策略文字 这样的 commit 。
总结
日常开发中，我们应该只在 dev 分支进行开发，master 分支只用来发布新版本，这样能够最大限度的保持 master 分支的安全性。
为了能够看出来历史合并消息，在合并分支的时候，加上 --no-f 参数，禁用 git 的 fast-forward 模式。
bug分支
我们日常在开发的过程中经常出现这样的情况。历史中某一个版本有 bug 需要紧急修复，现在我们又正在进行新功能的开发。这个时候，我们因为新功能还没有开发完成，不能进行提交，又需要先修复 bug 怎么办呢？
可以先将当前工作进度保存起来，新建一个分支，修复bug ，然后恢复当前工作进度。下面我们来模拟这个情景。
我们有一个 README 文件，在其中模拟工作状态。
这里出现了一个bug.
我们愉快的在 dev 分支进行开发...
开发进度70%...
开发进度80%，组长要求先行修复前面的bug使用 git stash 保存当前工作进度
$ git stash
Saved working directory and index state WIP on dev: 5e44f74 在 dev 分支开发进度进行到了 70%
新建一个 issue-66分支，进行bug 修复。
$ git checkout -b issue-66
Switched to a new branch 'issue-66'
修复bug ，并且提交。
$ git checkout -b issue-66
Switched to a new branch 'issue-66'
...
这里出现了一个bug. 对bug 进行了修复
...
$ git add .
$ git commit -m "修复 bug 66"
[issue-66 9a864d0] 修复 bug 666
1 file changed, 1 insertion(+), 1 deletion(-)
$ checkout dev
bash: checkout: command not found
$ git merge --no-f -m "bug修复后合并到 dev 分支" issue-66
Merge made by the 'recursive' strategy.
README.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
$ git branch -d issue-66
Deleted branch issue-66 (was 9a864d0).
回到 dev 分支，继续进行开发
// 查看我们保存了哪些工作进度，这里只有一个
$ git stash list
stash@{0}: WIP on dev: 5e44f74 在 dev 分支开发进度进行到了 70%
$ git stash pop
Auto-merging README.md
On branch dev
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: README.md
no changes added to commit (use "git add" and/or "git commit -a")
Dropped refs/stash@{0} (3092b5561ec681c11f80de49ec799ecc457d7e21)
git stash pop恢复了我们保存的工作场景，并且删除了这个场景，现在看看保存的stash,已经没有未恢复的 stash 了。
$ git stash list在恢复 stash 的时候，我们也可以使用 $ git stash apply stash@{0}来指定恢复列表中的哪一个 stash 。
现在，继续完成我们未完成的新功能吧…
开发进度80%，组长要求先行修复前面的bug
bug也修复了，继续愉快的开发...
开发进度 100%$ git add .
$ git commit -m "新功能开发完成"
[dev cb75959] 新功能开发完成
1 file changed, 7 insertions(+), 1 deletion(-)
$ git checkout master
Switched to branch 'master'
Your branch is ahead of 'origin/master' by 3 commits.
(use "git push" to publish your local commits)
$ git merge --no-f -m "新功能开发完成，合并到 mater分支" dev
Merge made by the 'recursive' strategy.
README.md | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
查看我们的合并历史
$ git log --graph --pretty=oneline --abbrev-commit
* b6e3d60 (HEAD -> master) 新功能开发完成，合并到 mater分支
|\
| * cb75959 (dev) 新功能开发完成
| * 6a5ba4c bug修复后合并到 dev 分支
| |\
| | * 9a864d0 修复 bug 666
| |/
| * 5e44f74 在 dev 分支开发进度进行到了 70%
|/
* d2d724d bug 出现
可以很清晰的看到，我们在 issue-66 分支修复了 bug ，然后合并到了 dev 分支，接着继续在 dev 分支完成了所有的开发，最后合并到了 master 分支。
总结
修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除；
当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复后，再git stash pop，回到工作现场。
Feature分支
我们在 开发新功能的时候，通常是常见一个 feature 分支，类似 bug 分支一样，进行开发，开发完成，合并到 dev 分支。但是如果新功能开发完以后，在合并到 dev 分支以前，公司通知，这个新功能不要了，那么就需要删除这个分支。但是没有合并以前的分支 通过 git branch -d feature-name 是删不掉的，git 会提示我们这样可能丢失数据。我们来试验下。
// 创建新功能的分支 feature-news
$ git checkout -b feature-news
Switched to a new branch 'feature-news'
努力开发…
新功能来了
新功能开发完成了提交完成。
git add .
git commit -m "新功能开发完了"
[feature-news 0f1af3f] 新功能开发完了
1 file changed, 5 insertions(+), 1 deletion(-)
$ git checkout dev
Switched to branch 'dev'
// 删除分支的时候，git 提示我们 feature 分支还没有 merge ，如果一定要删除，是用 -D
$ git branch -d feature-news
error: The branch 'feature-news' is not fully merged.
If you are sure you want to delete it, run 'git branch -D feature-news'.
根据 git 的提示，进行强制删除
$ git branch -D feature-news
Deleted branch feature-news (was 0f1af3f).
$ git branch
* dev
master
现在，就只剩下我们的 dev 分支和 master 分支了。
总结
开发一个新feature，最好新建一个分支；
如果要丢弃一个没有被合并过的分支，可以通过 git branch -D <name> 强行删除。