前奏

很多时候，发现自己真的不曾学会过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的冲突，以至于重复解决冲突。