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的冲突，以致于重复解决冲突。