git rebase 命令
git rebase 命令
平常项目开发中,经常需要用到分支合并,git merge
和git rebase
都有这个作用,但两者的用法存在些微差别。
1、使用流程
假设现在有master
主分支 1-2-3 和dev
分支。
- 切回
master
分支,拉取最新代码,拉取后的commit
历史变成 1-2-3-4 - 切回
dev
分支,dev
提交了两次commit
,commit
历史变成 1-2-3-5-6 - 将两次
commit
合为一次,现commit
历史变成 1-2-3-5.5, 然后执行git rebase
合并master
分支。 - 如果出现冲突则手动解决,接着再执行
git rebase --continue
继续合并或者git rebase --abort
放弃合并。 - 合并完成的
commit
历史变成 1-2-3-4-5.5, 切回master
分支,merge dev
分支,接着push
远程仓库。
git checkout master
git pull
git checkout dev
# 合并多次commit为一个
git rebase -i HEAD~2
#有冲突则解决,然后执行git rebase --continue
git rebase master
git checkout master
# 此时merge不会存在冲突
git merge dev
git push origin master
如果想直观地以图形的形式查看commit
历史,有以下命令:
git log --oneline --graph
git merge: 如果不使用git rebase
命令,使用git merge
进行合并,dev
分支的commit
历史将是 1-2-3-4-5-6-7,当master
分支与dev
分支发生冲突,将产生新的commit
,例如这里的序号 7。但git merge
因为会保留所有的commit
历史,如果想追溯历史代码很方便。
git rebase: 我自己认为最大的作用是可以合并多个commit
,并让commit
历史线性排列,能够更加直观的管理。缺点也是因为合并commit
历史,如果两次commit
合成为一个commit
,想找回其中一个commit
将变得不可能。
2、黄金法则
使用git rebase
的前提是一定要确保该分支只有你一人使用,即不为共享分支。
例如dev
分支上只有你一个人在开发,那么使用git rebase
怎样都不会破坏commit
历史。多个人同时在dev
分支上 进行git rebase
将造成commit
历史不断重塑而及其混乱。
关于黄金法则请了解文章:https://segmentfault.com/a/1190000005937408。
自我控制是最强者的本能-萧伯纳