目录
- [一、 分支](#一、 分支)
- [二、创建分支`git branch [分支名]`](#二、创建分支
git branch [分支名]) - [三、切换分支 `git checkout [分支名]`](#三、切换分支
git checkout [分支名]) - [四、合并分支`git merge [分支名]`](#四、合并分支
git merge [分支名]) - [五、删除分支`git branch -d [分支名]`](#五、删除分支
git branch -d [分支名]) - 六、合并冲突：手动修改
- [七、合并模式 `--no-ff` 强制禁⽤ Fast forward 模式](#七、合并模式
--no-ff强制禁⽤ Fast forward 模式) - 八、分⽀管理策略
-
- [8.1 bug分支 stash命令](#8.1 bug分支 stash命令)
- [8.2 强制删除分支 `git branch -D [分支名]`](#8.2 强制删除分支
git branch -D [分支名])
一、 分支
每次提交，Git都把它们串成⼀条时间线，这条时间线就可以理解为是⼀个分⽀。截⽌到⽬前，只有⼀条时间线，在Git⾥，这个分⽀叫主分⽀，即 master 分⽀。
再来理解⼀下HEAD，HEAD 严格来说不是指向提交，⽽是指向master，master才是指向提交的，所以，HEAD指向的就是当前分⽀。HEAD 也是可以指向其他分支，被 HEAD 指向的分支就是当前正在工作的分支。
二、创建分支git branch [分支名]
我们可以使用git branch 命令查看当前本地的所有分支。
创建第⼀个⾃⼰的分⽀ dev：git branch dev
三、切换分支 git checkout [分支名]
要想切换分支，使⽤ git checkout [分支名] 命令即可完成切换。
-
我们在当前分支修改ReadMe文件
-
我们先在当前分支提交修改后的ReadMe文件。
-
我们再切回master分支，会发现我们在dev分支做的修改不见了
-
切回 dev 看看，又还在。
-
看两个分支的commit id是不一样的
造成上面的结果，是因为两个分支执行的提交是不一样的：相当于下图
四、合并分支git merge [分支名]
为了在 master 主分⽀上能看到新的提交，就需要将 dev 分⽀合并到 master 分⽀。使用git merge [分支名]合并操作，合并后就能在master分支上看见修改后的ReadMe了。
现在就相当于：
Fast-forward 代表"快进模式"，也就是直接把master指向dev的当前提交，所以合并速度⾮常快。当然，也不是每次合并都能 Fast-forward。
五、删除分支git branch -d [分支名]
我们在上面完成了合并分支的操作，那么dev分支的使命也就结束了。使用git branch -d [分支名]就可以删除该分支了
但是注意我们不能在该分支目录下，删除不被允许。
六、合并冲突：手动修改
情景：当我们使用本地分支dev修改文件时，master分支同时也在修改该文件。git 就没办法知道保留dev修改的文件还是保留master分支修改的
本地修改：
master分支修改：
合并造成冲突：
ReadMe文件：
此时就需要我们手动看保留哪个代码
再重新add commit 和merge 即可：git log --graph --pretty=oneline --abbrev-commit查看分支合并情况
七、合并模式 --no-ff 强制禁⽤ Fast forward 模式
我们在前面介绍分支合并的时候讲过通过merge提交，git是默认使用 fast forward 直接修改 master指向的方式。
通过fast forward 模式会有删除分支后，查看分支信息的时候没有记录的情况出现，这样就会不知道这串修改到底是合并进来还是一直都在master分支下的。
但是我们在上面面对合并冲突后，我们手动修改在merge就会显示分支信息。Git ⽀持我们使用 --no-ff 强制禁⽤ Fast forward 模式，那么就会在 merge 时⽣成⼀个新的 commit ，这样，从分⽀历史上就可以看出是合并过的。
语法：git merge --no-ff -m "描述" [分支名]
八、分⽀管理策略
master主分支要保持稳定的。
由于很多人都可以在master拉分支，实现自己的开发，所以团队合作的分⽀就像下图一样：
8.1 bug分支 stash命令
情景：假如我们现在正在 dev 分⽀上进⾏开发，开发到⼀半，突然发现 master 分⽀上⾯有 bug，需要解决。在Git中，每个 bug 都可以通过⼀个新的临时分⽀来修复，修复后，合并分⽀，然后将临时分⽀删除。此时 dev 还没开发完，无法提交 的处理场景。
Git 提供了 git stash 命令，可以将当前的⼯作区信息进⾏储藏，被储藏的内容可以在将来某个时间恢复出来。
我们使用了stash 命令之后，我们就可以在master分支上创建分支修改bug，修改完成后提交即可。那我们如何继续 dev 的开发工作呢？可以看到我们直接切回去后，是没有当时还没写完的代码的。
git stash pop 命令恢复工作区代码
另外，恢复现场也可以采⽤git stash apply恢复，但是恢复后，stash内容并不删除，你需要⽤git stash drop来删除；
你可以多次stash，恢复的时候，先⽤git stash list查看，然后恢复指定的stash，⽤命令git stash apply stash@{0}
当我们写完dev分支代码后，跟master合并，master在前面跟修改bug的分支合并了，此时就可能导致dev和master合并冲突，那我们此时去手动修改冲突，有可能又出现bug。
解决方法：
在⾃⼰的分⽀上合并下 master ，再让 master 去合并dev ，这样做的⽬的是有冲突可以在本地分⽀解决并进⾏测试，⽽不影响 master 。
8.2 强制删除分支 git branch -D [分支名]
情景：当我们开发的这个分支代码突然不需要了。我们要删除已经 commit 的分支，就要使用 git branch -D [分支名]删除。
