Git 总结系列如下（感兴趣的赏个脸看一下呗）：
Git基础–常用命令
Git进阶–版本控制管理
Git进阶–远程仓库，在Github上提交代码
工作区，暂存区，提交的版本三个的关系：
工作区：我们当前正在操作的地方，任何修改都是先在工作区里。
暂存区：当我们修改了文件后，并执行git add 命令就将工作区的修改放进暂存区，使工作区与暂存区一致。暂存区可以防止误提交，或将一些不想提交的修改隔绝在工作区里，不添加进暂存区的修改就不会被提交。
提交版本： 放进暂存区之后执行git commit 就可以将暂存区与上一次 commit 不同的东西提交。
提一个不太恰当的比喻，就像3个水桶，里面放满了代码（Git 其实使用HEAD 指针来控制版本的，只会有一份代码），一次提交后，假设上一次提交没有没加进暂存区的修改，这时候3个桶的代码完全一样。你往第一个桶加了点代码或倒掉一点，这时候工作区就不一样了，执行git add 就会将工作区（第一个桶）修改同步进暂存区（第二个桶），然后执行git commit 就可以将暂存区（第二个桶）的内容同步到第三个桶。
图片来源 Git教程
1. 版本回退
git reset
git reset HEAD^ 或git reset HEAD~1 回退到上一版本
git reset HEAD^^ 或git reset HEAD~2 回退到上上个版本
使用 ^，每个^ 代表一个，~ 则后接数字 。
git reset <$id> 回退到任意commit,参数可以只打commit id 前面的部分数字，一般7，8位足够，只要保证id 的唯一性即可。
首先用 git log 查看提交记录。
我们要回退到 First commit 即 532acf...
执行git reset --hard HEAD^
可以看到回退成功了。（–hard 的作用下面再解释）
再执行git log 就可以看到只有一个commit 了。
这时候如果你后悔回退了，向要回到回退之前，git log 也打不出之后的commit了，这时候就需要git reflog 这个命令了，他会记录你的每一次操作。
我们要回到第二次commit 的时候，也就是 1e9832e
执行git reset --hard 1e9832e
可以看到又回到第二次提交了。
git reset --hard --soft --mixed(default)
三种的区别：
--hard 工作区，暂存区，版本 都回退到某次commit（HEAD 指向某次commit ，index 即为暂存区，working 为工作区）
--soft 只有版本会回退，暂存区，工作区保持原样
--mixed 也是不加参数时的默认操作，暂存区 和 提交版本 会回退，但工作区保持原样。
详细的可以看看这篇博文(图片来源)
2.分支管理
分支创建，切换，合并上一篇文章已经说过了，这里就不再赘述了，想要了解的可以查看我的上一篇文章 Git基础–常用命令 的后半部分。
git stash
现在 还有一种情况，当你在开发新功能开发到一半，这时候突然有一个紧急的bug需要修复，而新功能距离开发完成还需要一段较长时间，无法提交。你需要先修复bug，在这时候就需要 git stash 这个命令了，这个命令用来把当前工作现场“储藏”起来，等以后恢复现场后继续工作：
先用status 看一下状态：
然后 使用git stash 保存状态。
git stash list 可以查看stash的工作现场：
这时候你就可以欢快的在需要修复bug的分支新建bug分支修复代码了。
等修复完bug，就可以切换回你刚才的工作分支了，然后恢复工作现场，
一是用git stash apply恢复，但是恢复后，stash内容并不会删除，你需要用git stash drop 命令来删除。
另一种方式是用git stash pop，恢复的同时把stash内容也删了。
这时候再用git stash list 就没有东西了。
我们也可以多次stash，恢复的时候，先用git stash list查看，然后用命令恢复指定的stash：
git stash apply stash@{0}
解决冲突
我们先各自在a分支和master分支修改同一个地方并分别做一次提交，这时候两个分支都各自前进了一个commit。
a分支
master分支
然后在master分支合并一下a分支，这就发生了冲突
用status查看一下，changes to be commmited 代表没有冲突的部分，unmerged paths 代表发生冲突的部分。
打开文件readme.txt可以查看冲突：
Git用<<<<<<<，=======，>>>>>>>标记出不同分支的内容，我们修改后保存想要保留的部分即可。
最后再add，commit就可以了。
可以使用git log --graph看到分支的合并情况，
git log --graph --pretty=oneline --abbrev-commit
3.修改管理
1.撤销修改
撤销工作区相对于暂存区修改： git checkout -- <file>
-- 主要是为了说明后面所跟的是路径，而不是工作树的一些名词。
便于理解，分为两种应用场景：一种是修改后还没add 进暂存区，此时直接回到上一次commit时暂存区的状态。
一种是修改后add 进了暂存区，然后又做了修改，这时候回到上一次add 进暂存区后的状态。
首先随意修改一下文件，
然后使用 git status 查看一下状态，会有相应提示。
再使用 git checkout -- <file> 命令撤销修改
最后再用git status 看一下，工作区修改已经被撤销了
撤销暂存区相对于提交版本的修改： git reset HEAD <file>
首先随意修改一下文件，
并使用 git add <file> 将修改添加到暂存区。
然后使用 git status 查看一下状态，会有相应提示。
再使用 git reset HEAD <file> 命令撤销暂存区修改
最后再用git status 看一下，暂存区修改已经被撤销回工作区了，这时候如果还需要撤销工作区修改，就可以使用上面的git checkout -- <file> 命令了
撤销全部文件的修改：
这个其实结合前面内容可以猜出来，直接使用git reset HEAD 就可撤销最后提交版本后的全部文件修改，结合 hard soft mixed有不同的场景：
git reset --hard HEAD : 直接回退 工作区和暂存区的全部修改。
git reset --soft HEAD : 无效 ，不会有任何改变
git reset --mixed HEAD : 回退 暂存区 修改