git操作场景和分支规范

基本概念

工作区，暂存区，本地仓库，远程仓库。

基本流程：
工作区的修改，放入到暂存区，提交到本地仓库，推送到远程仓库。

常见后悔场景

1. 丢弃工作区的修改（没有git add过），用命令git checkout -- file
2. 丢弃暂存区的修改（已git add过，没有commit过），用命令git reset HEAD
3. 丢弃本地仓库的当前提交（已commit过，但没有推到远程仓库），命令git reset --hard commit_id
4. 丢弃本地仓库的当前提交（已推到远程仓库），并且覆盖远程仓库提交历史

# 下面两个命令不建议，会被打
git reset --hard resetVersionHash
git push -f origin currentBranch

忠告：如果你的回退涉及到了远程分支，在版本回退时最好使用revert，因它没有修改版本历史；如果使用reset，因为你的reset操作，会使你比远程少了几个提交，远程会提示你落后于远程版本，应该先git pull代码，那么你的reset操作又有何意义呢？（git push -f 强推可以做到，但不推荐这样做）

5. 描述如下

假设一开始你的本地和远程都是：

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

反向操作描述如下（建议操作）：

1. git log --pretty=online 显示有三个版本
   

2. git revert 版本号，抵消某个版本与其之后版本的修改，注意，这里的逻辑与git reset不一样，如果想回到Second commit的版本，就需要抵消掉Third commit的修改。所以这里应该git revert Third commit的版本号
   
3. revert的过程中可能会有冲突，git status查看冲突位置，解决冲突，git commit 文件名（无需git add）

4. git log --pretty=online，Third commit并没有丢失，而是多了一个revert版本，你可以 git log -p查看每个版本的修改，发现revert的版本所做的修改与Third commit恰恰相反，正好抵消掉了它的修改。
   

git reset commitID是返回到指定commitID。
git revert commitID是撤销指定的commitID

6. 误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作为发布分支，并推到远程仓库。