概述
除了常用的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