前奏
很多时候，发现自己真的不曾学会过 git，特别是本地多个分支在同时开发，合并 master 产生各种冲突，commit 了不必要的信息，commit 了错误的修改等等情况下，总感觉很害怕操作 git，细思而知，git 很强大，自己却不曾认识到它的强大之处。
直观的理解 git，下面是一张很好的图（图片来源网络，不知源处）：
git 的撤销
-
git reset
- git reset --soft: 将分支回退到指定提交，工作区维持现状不变, 暂存区会在现有基础上增加该 commit 之后的提交。- git reset --mixed:（默认操作）将分支回退到指定提交，暂存区也被同步为该指定提交，工作区保持不变。- git reset --hard: 将分支回退到指定分支，暂存区和工作区都会被同步为该指定的提交。
git reset 后的三个参数回退程度是依次递进。soft 最轻微，它不会重置当前工作区和暂存区，只会将回退版本后续的提交加到暂存区。mixed 会改变暂存区，使它和回退版本同步。hard 则会重置工作区和暂存区，使它和回退版本一致。
/*
git reset --soft target
*/
working index HEAD target working index HEAD
-------------------------------------------------------------
A B C C A B C
A B C A A B+C A
/*
git reset --mixed target
*/
working index HEAD target working index HEAD
-------------------------------------------------------------
A B C C A C C
A B C A A A A
/*
git reset --hard target
*/
working index HEAD target working index HEAD
-------------------------------------------------------------
A B C C C C C
A B C A A A A-
git checkout
- git checkout -- file: 撤销工作区的修改。
git 的合并
-
git merge
- 只解决一次冲突，分别对应的是当前分支最新提交和合并分支的最新提交的冲突 - 合并之后产生一个新的提交 - commit 信息按照时间顺序合并 -
git rebase
- 合并不产生新的 commit - 解决冲突的过程是：合并分支的最新提交 && 当前分支第 1 次提交 ------》解决冲突并 add 后的分支 && 当前分支第 2 次提交...... 依次解决完所有当前分支的提交。- commit 信息在合并分支的后续依次添加，呈一条线。
终
对于 push 到远程分支前，合并 master 分支到底用 merge 还是 rebase 看具体情况，如果当前分支的提交是在 merge 执行前一会儿，即使用 git merge，当前的 commit 时间线上还是会排列在后面，也可以先 stash，再 merge。如果是很久之前 commit 过，那 merge 就会吧当前 commit 按照时间顺序插入到某个正确的时间点上，所以 commit 信息就容易混乱，可以撤销 commit 再 stash，再 merge。
当然 rebase 可能不需要考虑那么多，但是需要解决多次 commit 的冲突，以至于重复解决冲突。