分支基础
在 Git 中，每次提交都会形成一条时间线，这实际上就是一个分支。目前只有一条主线，即 master 分支。
理解 HEAD 很重要。它严格来说不是指向某个具体提交，而是指向当前分支（如 master），而 master 才指向具体的提交对象。所以，HEAD 指向的就是当前正在工作的分支。
创建与查看分支
我们可以使用 git branch 命令查看当前本地的所有分支。
创建第一个自己的分支 dev：
git branch dev
切换分支
要想切换分支，使用 git checkout [分支名] 命令即可完成切换。
观察两个分支的 commit id 是不一样的。
切回 dev 看看，修改还在。
再切回 master 分支，会发现我们在 dev 分支做的修改不见了。这是因为两个分支执行的提交不一样，相当于下图所示的分叉状态。
合并分支
为了在 master 主分支上看到新的提交，就需要将 dev 分支合并到 master 分支。使用 git merge [分支名] 执行合并操作，合并后就能在 master 分支上看见修改后的 ReadMe 了。
Fast-forward 代表'快进模式'，也就是直接把 master 指向 dev 的当前提交，所以合并速度非常快。当然，也不是每次合并都能 Fast-forward。
删除分支
完成合并分支的操作后，dev 分支的使命也就结束了。使用 git branch -d [分支名] 就可以删除该分支。
注意不能在该分支目录下直接删除，否则不被允许。
合并冲突处理
当我们使用本地分支 dev 修改文件时，master 分支同时也在修改该文件，Git 就无法自动判断保留哪一方的修改，此时会产生冲突。
本地修改场景：
master 分支修改并尝试合并时：
ReadMe 文件中会出现冲突标记，需要手动决定保留哪个代码。
解决冲突后，重新 add、commit 和 merge 即可。可以使用 git log --graph --pretty=oneline --abbrev-commit 查看分支合并情况。
强制禁用 Fast forward 模式
前面提到过，默认 merge 提交时，Git 会使用 fast forward 直接修改 master 指向。但这会导致删除分支后，查看分支信息时没有记录，无法看出这段修改是合并进来的还是原本就在 master 下的。
Git 支持使用 --no-ff 强制禁用 Fast forward 模式。这样在 merge 时会生成一个新的 commit，从分支历史上就能清楚看出是合并过的。
语法：
git merge --no-ff -m "描述" [分支名]
分支管理策略
master 主分支要保持稳定。
由于多人可以在 master 拉分支开发，团队合作的分支结构通常如下：
Bug 分支与 stash 命令
假如我们正在 dev 分支开发，突然 master 上有 bug 需要修复。每个 bug 都可以通过一个新的临时分支来修复，修复后合并，然后删除临时分支。如果 dev 还没开发完无法提交，可以使用 git stash。
git stash 可以将当前的工作区信息进行储藏，被储藏的内容可以在将来恢复。
使用 stash 后，切换到 master 分支创建分支修改 bug，完成后提交。如何继续 dev 的开发？直接切回去可能发现没写完的代码，这时用 git stash pop 恢复工作区代码。
另外，恢复现场也可以采用 git stash apply，但恢复后 stash 内容不删除，需用 git stash drop 清理。可以多次 stash，先用 git stash list 查看，再用 git stash apply stash@{0} 恢复指定项。
写完 dev 分支代码后跟 master 合并，若 master 已先合并了 bug 分支，可能导致冲突。解决方法是在自己的分支上先合并 master，解决冲突并测试，再让 master 去合并 dev，这样不影响 master 稳定性。
强制删除分支
当开发的分支代码不再需要时，要删除已经 commit 的分支，需使用 git branch -D [分支名]。
