git rebase(变基)

前言

对于git rebase 一直不太了解,这几天想着提高下git提交质量,就发现了这个好用的指令,顺便记录一下,好加深记忆

贴出官方文档以便大家进一步学习 Git

rebase是干嘛的

• rebase 官方解释为变基,可以理解为移动你的分支根节点,维护一个更好的提交记录。rebase把你当前最新分支与其他分支合并时候,会把其他分支的提交记录放在我们当前分支时间线最开始的位置。也就是说,会把我们的提交记录整合在公共分支的后面。
• 简单来讲,合并本地其他分支 为了不产生多余的分叉,及合并记录时可以使用rebase。
• 接下来我们看一下rebase有哪些应用场景及使用技巧与merge的差异。

rebase与merge的差异

• rebase 会把你当前分支的 commit 放到公共分支的最后面,所以叫变基。就好像你从公共分支又重新拉出来这个分支一样。
• merge 会把公共分支和你当前的 commit 合并在一起，形成一个新的 commit 提交。

应用场景

• 你刚入公司，技术leader让你以 master 分支为基础,拉出一个分支进行开发需求。此时 master 分支提交记录为 a、b。你在 dev 分支分别 commit 了2次记录为 e、f ,有其他同事在 master 分支提交了两次记录为 c、d 这个时候你要合并master分支代码。

• 当前分支状态节点如下图所示:

使用git merge 进行合并操作

  $ git merge master  // 合并master分支代码
  $ git log --graph --oneline // 查看log点线图
  // 符号解释:
  * 表示一个commit， 注意不要管*在哪一条主线上 
  | 表示分支前进 
  / 表示分叉 
  \ 表示合入

结论

1. • 如上图所示 merge 会把两个分支合并在一起，形成一个新的 commit 提交记录。
2. • 我们发现 coomit 提交记录是把合并的分支记录放到我们当前dev分支记录的后面。
3. • 并且coomit 提交记录会产生分叉。

使用git rebase 进行合并操作

  $ git rebase master  // 合并master分支代码
  $ git log --graph --oneline // 查看log点线图
  // 符号解释:
  * 表示一个commit， 注意不要管*在哪一条主线上 
  | 表示分支前进 
  / 表示分叉 
  \ 表示合入

结论

1. • 首先，我们发现目前 dev 分支上面的提交记录为 abcdef 并没有像 merge 一样产生新的提交记录
2. • 其次 rebase master 分支到 dev 分支, dev 分支的历史记录会添加在 master 分支的后面。

3. • 如图所示，历史记录成一条线,非常整洁,最后并没有像使 merge 一样提交记录产生分叉。

rebase的使用业务场景

• 认识到了rebase,让我们来看看有哪些实战场景可以参考使用。

场景一

• 经典场景,优化本地提交记录,使其减少分叉。
• 和上面👆那个经典案例一样,这里就不做重复描述了😁

场景二

• 连续性冲突
• 此时你从master分支拉出一个dev分支来对以v1版本为基础a功能进行需求更改，由于项目经理分功能时,让你的同事也对master分支中的a功能中的某个公共页面a也进行了整改,过一会你同事改完,提交x版本并合并push到了master远程分支上面。此时我们在dev分支完成一次开发提交了v2版本,产品经理过来说,需求有变更,要再做修改,然后我们又以v2的基础上在做修改,并提交为v3版本。过一会测试又提了一个需求建议。我们接着以当前dev分支v3版本为基础做好了整改并commit一个v4版本。到此我们本地假设对页面a修改了三次。同事修改了一次,并push到了远程master上面。那么我们对master分支进行合并到时候就会产生冲突。
• 简单来讲就是。远程分支 master 对文件a进行了1次 commit ，而别的分支dev对文件A进行了3次commit，但是本地分支dev提交的n次 commit都与master分支的1次commit有冲突，

使用 git rebase 解决冲突

$ git fetch  // 更新本地存储的远程仓库的分支引用
$ git rebase origin/master // 拉去远程分支master中的代码与当前分支合并且变基
// 此时我们会产生第一次冲突,为当前dev分支版本v2中的a页面与远程分支master中的a页面冲突。解决后,根据提示进行 
$ git add .
$ git rebase continue // 继续进行合并
// 此时我们会产生第二次冲突,为当前dev分支版本v3中的a页面与远程分支master中的a页面冲突。解决后,根据提示进行 
$ git add .
$ git rebase continue // 继续进行合并
// 此时我们会产生第三次冲突,为当前dev分支版本v4中的a页面与远程分支master中的a页面冲突。解决后,根据提示进行 
$ git add .
$ git rebase continue // 继续进行合并
// 至此我们使用 rebase 变基完成 可以根据产品需求push到远程dev分支
$ git log --graph --oneline // 查看log点线图
// 符号解释:
* 表示一个commit， 注意不要管*在哪一条主线上 
| 表示分支前进 
/ 表示分叉 
\ 表示合入

结论

1. • 不会因为像使用 merge 时合代码时遇到冲突产生新的提交记录
2. • 用 merge 只需要解决一次冲突即,简单粗暴,而用 rebase 的时候 ，需要依次解决每次的冲突，才可以提交。
3. • 使用 rebase 提交记录不会分叉,一条线干净整洁
4. • 冲突解决完之后，使用 git add 来标记冲突已解决，最后执行git rebase --continue继续。如果中间遇到某个补丁不需要应用，可以用下面命令忽略：git rebase --skip
5. • 如果想回到 rebase 执行之前的状态，可以执行：git rebase --abort

场景三

1. • 你开发的一个需求产品反复更改,导致你的commit记录多次重复功能点
2. • 在日常开发中,难免有重复的commit提交记录.这时候我们想优化一下提交记录该如何做呢

• 当前分支状态节点如下图所示:

使用git rebase 进行commit记录合并操作

  $ git rebase -i HEAD~x  
  // i(interactive)交互，HEAD~x 代表要合并到距离HEAD最近的几个历史提交,如 HEAD～3就是历史的前3个提交.
  $ git log --graph --oneline // 查看log点线图
  // 符号解释:
  * 表示一个commit， 注意不要管*在哪一条主线上 
  | 表示分支前进 
  / 表示分叉 
  \ 表示合入

• 这里我们使用git rebase -i HEAD~3，此时我们会出现如下界面,我们进行简单设置

• 此时我们会产生一条新的提交记录,并选择填写提交相关信息,并删减掉合并掉的提交记录

• 到此我们的合并已结束。

结论

1. • 合并了冗余的提交记录,并产生了一条新的提交记录
2. • 使提交记录看起来更整洁，也方便同事查阅

总结

• 我们发现分享 rebase 全文都是围绕 优化分支提交记录 来举例子介绍该命令,我个人觉得这也就是该命令的核心之处。
• 在学习 rebase 之前我日常使用的基本都是 merge 导致 commit 记录过于混乱，自己想要哪个功能节点都要找很久的提交记录,以后会慢慢尝试在项目中使用一下。毕竟谁不想要一个整洁好看的提交记录呢😁

---

参考文献

• # 从git log 点线图（graph）看merge和rebase操作

• # 从git rebase的常见冲突及解决办法