版本冲突与变基

概述

除了常用的git add/commit/push/pull/branch/checkout 等常规操作外，git 还有两个在生产中某些关键时刻可以解决问题的命令：git reset / rebase

reset / revert

昨晚上线的版本有bug，需要回滚到某一个commit

git reset --soft head^
git reset --hard head^

git revert head

git 版本管理的三个关节位置：head 指针指向当前分之当前本的指针；本地文件内容；本地已经commit 让 git 管理的内容 即index（staged）区域。
–soft 只改变head指针指向，不会改变本地文件内容和index中的内容
–hard 改变head 指针， 也会改变本地文件文件内容和index中的内容
revert 会从指定节点的上一个节点新建一个commit， 然后改变index和文件夹中的内容
例如：

git revert HEAD~3

Revert the changes specified by the fourth last commit in HEAD and create a new commit with the reverted changes.

rebase

场景一 : 跟上master 的进度

线上版本为online，张三今天上午接到一个需求，拉了个版本zhangsan，李四下午接到一个需求，也拉了个版本叫lisi，lisi 一会就提交了代码，也通过了code review 合并到了 online 分支，第二天zhangsan 分支开发完了，也想合并到online，这时的online 已经不是当初的online了，lisi 提交的merge request 可能会产生conflict。

这时张三可以先 rebase 到现在的online 上，再提交merge request。

场景二：压缩不必要的commit

沿用上面的场景，假设张三在zhangsan分支上开发时，commit 了 100多 次（每写几行就commit一下），开发完后merge 到了online，也发布到了线上，但是，线上突然出现了个bug，要回滚代码，这时一看commit 信息，岂不要晕了。

所以张三可以在merge request 之前 先rebase 一下，例如 合并最近的三次 commit

git rebase -i HEAD~3

出现

然后修改commit 内容

:wq 退出

选择需要保留的一条commit message, 其余的删除掉或注释掉即可 :wq。

之后 查看commit log 就只剩下保留的那条commit message 了。

附：

头指针分离

git checkout <branch-name> 不会造成头指针分离，但是git checkout <commit-id> 后，会造成头指针分离，若此时在文件中做的修改，然后又切换到别的分支去了，这些修改就不会保存，因为没有branch 留给我们保存，一般此时都会提醒根据当前修改创建一个分支：

git branch <new-branch-name> commit-id