git撤销与合并操作

前奏

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