Learn git notes from xiaobai
the fourth day
解决冲突：
产生背景：新建一个分支修改后提交后回到原分支又进行修改提交，再进行合并时会产生冲突。
通过git status可以查看产生冲突的文件。然后查看文件，git会用<<<<<<<,=======,>>>>>>>，来显示不同分支分内容。然后通过修改解决冲突再提交。这里可以通过git log查看分支合并情况。
git log --graph --pretty=oneline --abbrev-commit：通过图表查看分支合并情况。
--pretty=oneline：一行显示，之前我说不喜欢一行显示，不过这里看图表时用一行可以看得很清楚。
--abbrev-commit：我没有仔细看这个参数，不过测试知道这是让版本号显示的更简洁。
合并的另外一种方式：git merge --no-ff -m "message" branch_name :合并后master指向下一版本，head指向master，并且可以查看到合并过，而快速合并就看不到，相同的是如果有冲突的话还是不能合并的。
实际开发中管理分支原则：master是稳定的，只用来发布新版本，dev是不稳定的，每个人都在上面干活，直到新版本写好后再合并到master。
写到这我对于昨天的第二个问题可能有点想法，就是开发中可能是通过人为的要求来避免每个人互相产生冲突，而且每个人实现的功能不一样，所修改的文件也是不一样的，然后会有一些文件提前写好供每个人使用，所以修改文件不同，上传时也就不会有冲突。
Bug分支：
| 命令 | |
|---|---|
| git stash | 保存当前修改的内容；类似于压栈 |
| git stash list | 查看保存的版本；姑且说是版本，其实就是不同的修改 |
| git stash apply | 回复现场 |
| git stash drop | 删除栈顶中的版本 |
| git stash pop | 相当于前两个命令的合并 |
| git cherry-pick 某次提交的哈希值 | 复制特定的提交到当前分支 |
注：
1.git stash *** 的命令后边都可以通过加 stash@{数字}来对特定的某个版本操作。
2.git stash前一定要查看status确保所有文件都已经add过，因为它不能将未被跟踪的（也就是从未add过的）文件压栈。
3.个人看了一些相关讨论后，觉得这一部分的应用场景大概就是这样：加入当你正在实现dev分支的功能时，突然需要你修改一个主分支的bug，而你由于没有完全实现不能提交当前分支，如果直接回到主分支会把新增加的内容带过去，所以你需要将dev分支状态压栈，修改完主分支的bug后回到dev，将之前的状态出栈，继续完成未完成的工作，而主分支的bug，dev分支也会出现，所以需要出栈前用git cherry-pick命令将修改bug的那次提交复制到dev分支，在出栈继续完成工作。如果dev修改了master分支中的部分，那么出栈时会出现冲突的情况。
分支强制删除：
使用背景：当你被迫需要删除某个已经完成功能的分支时。
git branch -d 分支名 此时是会报错，需要把参数改成-D可以强制删除掉。
今天解决了一个昨天的问题，明天继续！