git rebase 命令

目录

• 1、使用流程
• 2、黄金法则

 

---

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。