git rebase 的两种用法


# git rebase 的两种用法

# 前言

rebase 在 Git 中是一个非常有魅力的命令,使用得当会极大提高自己的工作效率;相反,如果乱用会给团队中其他人带来麻烦。

它的作用简要概括为:可以对某一段线性提交历史进行编辑、删除、复制、粘贴;因此,合理使用 rebase 命令可以使我们的提交历史干净、简洁。

# 用法一: 合并当前分支的多个 commit 记录

有时候会遇到对同一处代码进行多次处理的场景。这会导致如下提交记录:

$ git log --pretty=format:'%h: %s'
ad3593c: feat: modify c
21511a4: feat: modify b
a7b8f93: feat: modify b
89ab26f: feat: modify b
5f5d89a: feat: modify a
7092a92: Initial commit
1
2
3
4
5
6
7

其实,中间的对 b 的 3 次提交 完全可以合并成一次 commit,这个时候 rebase 就很有用了。

# 1. 执行 rebase -i 命令

找到想要合并的 commit,使用 rebase -i:

git rebase -i 5f5d89a
1

注意

  • git rebase -i [startPoint] [endPoint]
  • 前开后闭区间,这里的 [startPoint] 指目标 commit 的前一个 commit(即上述示例中的 5f5d89a: feat: modify a)。 因为三个 commit 肯定要基于上一个 commit 来合并成新的 commit。
  • 谨慎使用 [endPoint],省略即默认表示从起始 commit 一直到最后一个,但是一旦填写了,则表示 [endPoint] 后面的 commit 全部不要了。

# 2. 进入 Interact 交互界面

终端会进入选择交互界面,让你进行变基选择操作:

git rebase 交互界面

(git rebase 交互界面)

说明

  • 最上面三行,就是刚刚选中的三个 commit,按时间先后顺序依次往下排序(和 git log 的展示顺序是反的,查看的时候需要注意)
  • 前面的三个 pick 就是下面 Commands 展示的一系列命令中的第一个 p,也就是使用 commit。
    • pick:保留该 commit(缩写:p)
    • reword:保留该 commit,但我需要修改该 commit 的注释(缩写:r)
    • edit:保留该 commit,但我要停下来修改该提交(不仅仅修改注释)(缩写:e)
    • squash:将该 commit 和前一个 commit 合并(缩写:s)
    • fixup:将该 commit 和前一个 commit 合并,但我不要保留该提交的注释信息(缩写:f)
    • exec:执行 shell 命令(缩写:x)
    • drop:丢弃该 commit(缩写:d)

# 3. 使用 s 命令合并 commit

使用 s 命令,合并到上一个commit(编辑时就跟操作 vim 一样):

  • i 进入操作,将第二、三个 commit 的 pick 改成 s
  • Esc 退出操作。
  • 输入 :wq 保存并退出。
使用 s 命令合并 commit

(使用 s 命令合并 commit)

# 4. 修改 commit 记录

接下来会弹出第二个页面,分别展示三个 commit 的提交信息:

相关的 commit 信息列表

(相关的 commit 信息列表)

在这次的示例中,三个 commit 信息都是一样的。选用第一个的提交信息(也可以编辑下),将其余的全部注释掉,重复上述步骤,保存退出即可。

编辑提交信息

(编辑提交信息)

# 5. 查看最新合并情况

查看最新合并情况,会发现原来三个一样的提交现在合并成了一个新的 commit。

commit 合并前后对比

(commit 合并前后对比)

# 用法二: 避免出现分叉合并

接下来,将通过实际示例和场景,来分析 rebase 是如何解决分叉合并的。在此之前,我先做如下规定:

  • 有两个分支: develop(主分支),feature(feature 分支)
  • 新需求按时间顺序叫 ab……等(a 需求最早,b 其次,以此类推)
  • 原 commit a 变基之后(hashId 改变)叫 a'

# 场景 1:合并时,最舒服的情况

这种场景是基于 develop 分支没有新的提交,feature 分支有新的提交后,把 feature 分支的改动合并到 develop 分支。

developfeatureaa合并

(最理想的合并情况)

此时的合并有两点好处:

  • 没有冲突
  • 没有多余的 commit 提交

其实这种情况下,rebase 和 merge 的效果是一样的。而后面所有的 rebase 都是奔着这个目标来的。

# 场景 2:各分支都有自己新的 commit

develop 新增需求 a: "feat: a"

develop 分支的 log

(develop 分支的 log)

feature 新增需求 b: "feat: b"

feature 分支的 log

(feature 分支的 log)

# 1)develop merge feature

develop 直接 merge feature:切换到 develop 分支执行命令 git merge feature

develop 直接 merge feature

(develop 直接 merge feature)

会出现以下结果:

  • 会保留所有的 commit(hashId 不变)
  • 按提交顺序排序
  • 产生新的 commit 点(Merge branch 'xxx' into develop)
developfeatureabbMerge branch 'xxx' into develop

(develop 直接 merge feature)

# 2)develop rebase feature

如果在 develop 分支没有直接执行 merge 命令,而是执行的 rebase 命令 git rebase -i feature

develop rebase feature

(develop rebase feature)

会出现以下结果:

  • develop 分支的 a 会被排在合进来的 feature 分支 b 的上面(尽管 a 是先完成的)
  • develop 的原 commit a 被移除,产生了新的 commit a'(hashId 已变)
  • 从 feature 合进来的 b 不变(不会对合进来的 commit 进行变基)
adevelopfeaturebba'

(develop rebase feature)

# 3)rebase 两步走 - 正确姿势

  • Step 1:切换到 feature 分支,去 rebase develop,即 git rebase -i develop
    • feature 的 commit b 会重新生成一个 b',排在 develop 的新需求 a 的后面。
    • 这一步相当于回到场景 1 的模式,我在当前 feature 先把自己的 b 拎出来,同步完最新的 develop,再把需求 b 放在最后面。
    • 接下来回到 develop 进行 merge 的时候就很舒服了。
  • Step 2:切换到 develop 分支,去 merge feature,即 git merge feature
    • 合并后查看 log,可以发现 develop 分支作为主分支,本次合并没有影响自己原来的 commit 历史,只在后面新增了 feature 的新内容,并没有多余的 commit。
×badevelopfeatureb'b'afeature rebase developdevelop merge feature 

(rebase 两步走)

以上就是 rebase 为什么不会产生多余 commit 记录的原因了。

# rebase 时如何解决冲突

如果两个分支修改了同一文件的同一位置,在 rebase 的时候会提示发生冲突,较为优雅的解决方案:

  • 先解决冲突,再保存。
  • git add .
  • git rebase --continue

# 使用 rebase 的注意点

注意

如果提交存在于你的仓库之外,而别人可能基于这些提交进行开发,那么不要执行变基。
如果你遵循这条金科玉律,就不会出差错。否则,人民群众会仇恨你,你的朋友和家人也会嘲笑你,唾弃你。 —— 引用自官网 (opens new window)

# 不要基于即将 rebase 的分支去切新分支

badevelopfeatureb'afeature_brebase develop此时 feature_b 还在 b 节点然而 feature rebase 完,已经没有 b 了

(不要基于 rebase 的分支,切新分支)

如上图所示:

  • feature 通过场景 2 中的 rebase 两步走之后,与 develop 实现了同步。
  • 但是原先基于 feature 切出去的新分支 feature_b 还是原来的 commit b。
  • 此时无论 develop 还是 feature,再合并 feature_b 的时候,都会产生冲突,形成两个相同的提交记录(其实就是 b 和 b')。

所以,首先要确保你的分支已经完成新需求,然后在 rebase 操作结束之后,再去切新分支,这时他们才是同步的。

# 不要对已经合并到主分支的本地修改进行变基

首先,自己的分支,如果想对已经推送的 commit 进行修改,可以在修改完后,使用 git push -f 强行 push 并覆盖远程对应分支。

但是如果这些修改已经被合到了其他分支(比如主分支),那又会出现冲突,因为其他分支保存的是你 rebase 之前合进去的 commit。

典型操作(应避免):

  • feature 分支有三个新需求(a,b,c)。
  • develop 合并 feature 后,保持同步完成。
  • 这个时候 feature 分支使用 rebase -i,对中间 b 进行修改,导致 b 和 c 的 commit-id 都发生了改变。
  • develop 再合并 feature 时,就会产生冲突,解决后,会多出两次重复的提交记录(以前就有 b,c,现在又多了 b',c')。

# 不要在预发布/正式分支上使用 rebase -i

从变基的那个节点开始往后的所有节点的 commit-id 都会发生变化,这个就不再赘述了。

所以可以想象一下,master 上有 100 个 commit,你悄悄改了第 50 个 commit,那从 50—100 的所有 commit 全部改变了。这时别人的分支合进来,就会有 51 个冲突,解决完冲突之后,就会产生 51*2 个相同的提交记录,恐怖如斯!

# 总结

总的原则是,只对尚未推送或未分享给别人的本地修改执行变基操作清理历史,永远不要对已推送至别处的提交执行变基操作。这样,你才能享受到两种方式(rebase 和 merge)带来的便利。

(完)