本系列学习笔记参考廖雪峰老师的Git教程，地址：https://www.liaoxuefeng.com/wiki/896043488029600
Git学习笔记（一） https://www.cnblogs.com/littlemonsterksn/p/13562632.html
Git学习笔记（二） https://www.cnblogs.com/littlemonsterksn/p/13583004.html
Git学习笔记（三） https://www.cnblogs.com/littlemonsterksn/p/13583197.html
Git学习笔记（四） https://www.cnblogs.com/littlemonsterksn/p/13593841.html
Git学习笔记（五） https://www.cnblogs.com/littlemonsterksn/p/13598243.html
十三、解决冲突
1. 新建分支，在readme.txt添加内容并进行提交
新增并切换到feature1分支，新增一行信息
添加的内容：
Creating a new branch is quick AND simple.
$ git switch -c feature1 $ git add readme.txt $ git commit -m "AND simple"
2. 切换到master分支，在readme.txt文件添加一行信息并提交
添加的内容：
Creating a new branch is quick & simple.
$ git switch master $ git add readme.txt $ git commit -m "& simple"
3. 在master合并feature1分支
$ git merge feature1
提示readme.txt文件冲突，必须手动解决冲突后再提交
用git status也可以查看冲突的文件
查看readme.txt可以看到提示冲突的地方，标记了不同分支的内容
4. 手动修改后再提交
手动修改冲突后，提交成功了
$ git add readme.txt $ git commit -m "conflict fixed"
注意下图中的conflict单词拼写错了…
现在，master分支和feature1分支合并变化如下图所示：
5. 查看分支合并的情况
用带参数的git log也可以看到分支的合并情况
用git log --graph命令可以看到分支合并图
$ git log --graph --pretty=oneline --abbrev-commit
6. 合并完成后，删除feature1分支
$ git branch -d reature1
十四、分支管理，不用快速合并
通常合并分支时，如果可能，Git会用Fast forward模式，但这种模式下，删除分支后，会丢掉分支信息。
如果要强制禁用Fast forward模式，Git就会在merge时生成一个新的commit，这样，从分支历史上就可以看出分支信息。
1. 新建一个dev分支，并在readme.txt文件最后加一排内容
$ git switch -c dev
2. 提交一个新的commit
$ git add readme.txt $ git commit -m "add merge"
3. 切换到master分支
$ git switch master
$ git branch
4. 合并dev分支
$ git merge --no-ff -m "merge with no-ff" dev
注意--no-ff参数，表示禁用Fast forward
因为本次合并要创建一个新的commit，所以加上-m参数，把commit描述写进去
5. 查看分支历史
$ git log --graph --pretty=oneline --abbrev-commit
6. 不用fast forward的模式，merge后是这样的形式
小结：
合并分支时，加上--no-ff参数就可以用普通模式合并，合并后的历史有分支，能看出来曾经做过合并，而fast forward合并就看不出来曾经做过合并
十五、BUG分支
有了bug就需要修复，每个bug都可以通过一个新的临时分支来修复，修复后，合并分支，然后将临时分支删除。
当接到一个修复一个代号101的bug的任务时，很自然地，想创建一个分支issue-101来修复它，但是，当前正在dev上进行的工作还没有提：
1. 创建并切换到dev分支
2. 修改readme.txt文件
在文件最后增加一行内容
3. 查看状态
4. 工作区暂存
在dev的工作还需要1天，但是有个紧急的bug必须在两个小时内修复
这时可以用Git的stash功能，把工作区暂时储藏起来，等以后恢复现场后，就可以继续工作了
$ git stash
$ git status
储藏后，再查看工作区，就是干净的了
5. 新建并切换到修改bug的分支
首先确定要在哪个分支上修复bug，假定需要在master分支上修复，就从master创建临时分支
$ git switch master $ git switch -c issue-101
6. 在readme.txt文件最后添加一行
然后提交readme.txt
7. 切换到master分支，合并bug分支
$ git switch master $ git merge --no-ff -m "merged bug fix again" issue-101
8. 切回dev分支
查看状态，用git stash list查看暂存的工作区列表
$ git stash list
9. 恢复工作区
一是用git stash apply恢复，但是恢复后，stash内容并不删除，需要用git stash drop来删除
另一种方式是用git stash pop，恢复的同时把stash内容也删了
再用git stash list查看，就看不到任何stash内容了
恢复的时候，先用git stash list查看，然后恢复指定的stash，用命令
$ git stash apply stash@{0}
10. 在dev分支上修复同样的bug
因为dev分支是早期从master分支分出来的，所以，在master分支上修复了bug后，这个bug其实在当前dev分支上也存在。
同样的bug，要在dev上修复，只需要把5db1a03 fix bug again这个提交所做的修改“复制”到dev分支。注意：只是复制5db1a03 fix bug again这个提交所做的修改，并不是把整个master分支merge过来。
为了方便操作，Git专门提供了一个cherry-pick命令，能复制一个特定的提交到当前分支：
$ git cherry-pick 5db1a03
注意：刚才在dev工作区修改的内容需要先commit一下。直接切到dev然后cherry-pick会报错
先查看一下状态，查看readme.txt文件内容：
然后提交当前dev分支内容
再git cherry-pick 5db1a03
完成后，再次查看readme.txt文件，修复bug的内容已经复制过来了
小结
修复bug时，我们会通过创建新的bug分支进行修复，然后合并，最后删除
当手头工作没有完成时，先把工作现场git stash一下，然后去修复bug，修复后，再git stash pop，回到工作现场
在master分支上修复的bug，想要合并到当前dev分支，可以用git cherry-pick <commit>命令，把bug提交的修改“复制”到当前分支，避免重复劳动