基本概念
工作区，暂存区，本地仓库，远程仓库。
基本流程：
工作区的修改，放入到暂存区，提交到本地仓库，推送到远程仓库。
常见后悔场景
- 丢弃工作区的修改（没有git add过），用命令
git checkout -- file - 丢弃暂存区的修改（已git add过，没有commit过），用命令
git reset HEAD <file> - 丢弃本地仓库的当前提交（已commit过，但没有推到远程仓库），命令
git reset --hard commit_id - 丢弃本地仓库的当前提交（已推到远程仓库），并且覆盖远程仓库提交历史
# 下面两个命令不建议，会被打
git reset --hard resetVersionHash
git push -f origin currentBranch
忠告：如果你的回退涉及到了远程分支，在版本回退时最好使用revert，因它没有修改版本历史；如果使用reset，因为你的reset操作，会使你比远程少了几个提交，远程会提示你落后于远程版本，应该先git pull代码，那么你的reset操作又有何意义呢？（git push -f 强推可以做到，但不推荐这样做）
- 描述如下
假设一开始你的本地和远程都是：
a -> b -> c
你想把HEAD回退到b，那么在本地就变成了：
a -> b
这个时候，如果没有远程库，你就接着怎么操作都行，比如：
a -> b -> d
但是在有远程库的情况下，你push会失败，因为远程库是 a->b->c，你的是 a->b->d
两种方案：
push的时候用--force，强制把远程库变成a -> b -> d，大部分公司严禁这么干，会被别人揍一顿。
实践方案如同4。
做一个反向操作，把自己本地变成a -> b -> c -> d，注意b和d文件快照内容一莫一样，但是commit id肯定不同，再push上去远程也会变成 a -> b -> c -> d
反向操作描述如下（建议操作）：
- git log --pretty=online 显示有三个版本
- git revert 版本号，抵消某个版本与其之后版本的修改，注意，这里的逻辑与git reset不一样，如果想回到Second commit的版本，就需要抵消掉Third commit的修改。所以这里应该git revert Third commit的版本号
- revert的过程中可能会有冲突，git status查看冲突位置，解决冲突，git commit 文件名（无需git add）
- git log --pretty=online，Third commit并没有丢失，而是多了一个revert版本，你可以 git log -p查看每个版本的修改，发现revert的版本所做的修改与Third commit恰恰相反，正好抵消掉了它的修改。
git reset commitID是返回到指定commitID。
git revert commitID是撤销指定的commitID。
- 误commit大文件导致不能push
git push时终端报错：
error: RPC failed; HTTP 413 curl 22 The requested URL returned error: 413 Request Entity Too Large
fatal: The remote end hung up unexpectedly
你已经把大文件写入本地.git历史中。
你需要把它从commit历史，以及.git库里移除掉。
可以使用git filter-branch --tree-filter 'rm -f 文件名' HEAD命令
分支管理策略(git流程)
功能1开发分支命名为daily/0.0.1，并推到远程仓库。
功能2开发分支命名为daily/0.0.2，并推到远程仓库。
功能2开发完毕，合并master分支，并新建分支命名为publish/0.0.2作为发布分支，并推到远程仓库。
功能1开发完毕，合并master，解决冲突，并新建分支命名为publish/0.0.3作为发布分支，并推到远程仓库。
