git rebase 合并提交与避免分叉合并

这篇具有很好参考价值的文章主要介绍了git rebase 合并提交与避免分叉合并。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

本文让你熟练使用 rebase,学会以下两种操作,从此拒绝杂乱无章的 git 提交。

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

你可能出现过对同一处代码进行多次处理的场景。这会导致如下提交记录:

$ git log --pretty=format:'%h: %s'
d2399da: feat: modify c
0134695: feat: modify b
eb63848: feat: modify b
51c0bca: feat: modify b
4cb600e: feat: modify a
d29f331: Initial commit

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

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

git rebase -i 4cb600e

注意 git rebase -i [startPonit] [endPoint]

  • 前开后闭 区间 这里的 [startPonit] 是指需要合并的 commit 的前一个 commit (即当前示例中的 “4cb600e: feat: modify a”)。 因为, 三个 commit 肯定要基于上一个 commit 合并成了新的 commit。
  • 谨慎使用[endPoint] 省略, 即默认表示从起始 commit 一直到最后一个,但是一旦你填写了, 则表示 [endPoint] 后面的 commit 全部不要了!

step2. 进入 Interact 交互界面

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

说明

  • 最上面三行, 就是刚刚选中的三个 commit, 按时间顺序依次往下排序(和 git log 的展示顺序是反的, 大家查看的时候要注意)
  • 前面的三个 Pick 其实就是下面 Commands 展示的7种命令中的第一个p, 也就是使用 commit。

step3. 使用 s 命令 合并到上一个 commit

  1. i 进入操作, 将第二、三个 commit 的 pick 改成 s
  2. Esc 退出操作
  3. 输入:wq保存并退出
    git rebase,git

step4. 修改 commit 记录

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

这里三个信息都是一样的,我们选用第一个的提交信息,将其余的全部注释掉,重复上述步骤, 保存退出即可。
git rebase,git

step5. 查看最新合并情况

会发现原三个一样的提交现在合并成了一个新的 commit 。git rebase,git

rebase 的其他用法

命令 缩写 含义
pick p 保留该 commit
reword r 保留该 commit,但需要修改该 commit 的注释
edit e 保留该 commit, 但我要停下来修改该提交(不仅仅修改注释)
squash s 将该 commit合并到前一个 commit
fixup f 将该 commit合并到前一个 commit,但不要保留该提交的注释信息
exec x 执行 Shell 命令
drop d 丢弃该 commit

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

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

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

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

git rebase,git
此时的合并有两点好处:

  1. 没有冲突
  2. 没有多余的 commit 提交
    其实这种情况下, rebase 和 merge 的效果是一样的。

请大家记住这个场景, 后面所有的 rebase 都是奔着这个目标来的。

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

develop 新增需求 a: “feat: a”

feature 新增需求 b: “feat: b”git rebase,git

● develop 直接 merge feature

git rebase,git
会出现以下结果:

  1. develop 会保留 feature 的所有 commit(hashId不变);
  2. 按提交顺序排序;
  3. 产生新的 commit 点(Merge branch ‘XXX’ into develop)
    git rebase,git
● develop 直接 rebase feature

git rebase,git
会出现以下结果:

  1. develop 分支的 a 会被排在合进来的 feature 分支 b 的上面(尽管 a 是先完成的)
  2. develop的原 commit a 被移除 产生了新的 commit a’(hashId 已变)
  3. 从 feature 合进来的 b 不变 (不会对合进来的 commit 进行变基)
    git rebase,git
● rebase 终极版

上述两种操作虽然都能完成合并,但是结果却不是我们想要的。直接 merge 会产生多余提交,而直接 rebase 虽不会产生多余提交,但是会改变自身原有的 commit,这对上游的主分支来说是灾难性的。试想一下,如果上游的 master 主分支被你悄悄修改了 commit,而其他所有人还是基于原来的 commit 进行的开发,可想而知,到时候合代码就会如同车祸现场一样,遍地冲突…

所以,正确的操作是:先提前将 master 主分支的新代码 rebase 到自己的分支,再在主分支上 merge 自己的分支。

这样有两点好处:

  • rebase 的时候,虽然自己的新 commit,但是我们还没有提交上去,所以 commit 的变动对我们没有影响;
  • 如果有冲突,可以提前在自己的分支解决掉, 不会带到主分支上。

我们来看下完整示例:

step1: feature rebase develop
# feature分支
git fetch origin
git rebase develop

# 或者 直接一个命令
git pull develop --rebase

git rebase,git
会出现以下结果:

  1. develop 的新需求 a 会先排在 b’ 的前面(a 先提交上去了嘛);
  2. feature 的 commit b 会重新排在第一个 变成 b’(a 插队了嘛,顺序就变了)。

到这里, 你应该有所察觉了!: 没错! 这一步相当于 回到了场景1的模式, 我当前的 feature 相当于先把需求b 拎出来, 同步完最新的 develop, 再把需求b放在了最后面。

所以, 接下来 merge 的时候 就很舒服了~!

step2: develop merge feature
# develop分支
git merge rebase_new

git rebase,git
git rebase,git
而这, 也是 rebase 为什么不会产生多余的 commit 记录的原因了。

rebase时如何解决冲突

  1. 先解决冲突 再保存
  2. git add .
  3. git rebase --continue
    注意! 不是commit ! 不是commit ! 不是commit !

使用 rebase 的注意点

警告!

先引用官网上的一段话:

如果提交存在于你的仓库之外,而别人可能基于这些提交进行开发,那么不要执行变基。

如果你遵循这条金科玉律,就不会出差错。 否则,人民群众会仇恨你,你的朋友和家人也会嘲笑你,唾弃你。

因为变基最强大也是最危险之处, 就在于, 它能改变原 commit 的 hashId, 而一旦你对历史提交做出改变, 那么 从变基那个节点开始往后的所有节点的 commit id 都会发生变化。 这对线上环境来说, 是不可控的!

注意一:不要基于 rebase 的分支 切新分支

git rebase,git
如果 feature 在写完新需求 b 后,切了新分支 feature_B,然后又 rebase 了 develop,那么新分支feature_B 无论是合进 develop 还是 合进 feature 都会有冲突, 出现重复的 b(其实是 b 和 b’)
git rebase,gitgit rebase,git
除非 你能百分百确保 你的分支已经完成新需求, rebase 操作结束之后, 再切新分支, 这时 他们才是同步的。

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

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

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

注意三:不要在预发布、正式分支上使用 rebase -i

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

总结

git rebase 是一条集增删改查于一体的强大命令,它既可以对自己的分支进行修修剪剪,也可以在合并其他分支的时候缝缝补补,让我们的 commit 提交看上去干净清爽。

记住一条原则:只对尚未推送或未分享给别人的本地修改执行变基操作,清理历史, 从不对已推送至别处的提交执行变基操作

这样,你才能享受到两种方式(rebase 和 merge)带来的便利。文章来源地址https://www.toymoban.com/news/detail-610245.html

到了这里,关于git rebase 合并提交与避免分叉合并的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • git rebase (合并代码和整理提交记录)图文详解

    建议在看这篇文章之前一定要看完:git reset 命令详解 git revert命令详解。 看完上面的文章后,在rebase操作(成功/失误)后还可以进行回退。不至于咱们再去费劲创建那些提交记录。 git rebase 有两种作用 合并代码 整理提交记录 可以看到有两个分支,2023的分支是在master的基础

    2024年02月09日
    浏览(53)
  • 使用Git rebase合并多条提交记录commit。以及使用 git commit amend本地提交直接合并到远程已有commit的用法

    需求场景一 : 对某个小的功能点进行多次反复的修改提交,且已经提交到远程,导致commit记录过多,太过于杂乱无章,想要精简合并一些提交记录。 场景还原: 比如下图4个git commit记录,log1-log4,需要将他们合并成一个提交记录 解决方案: 要处理的是log1-log4 这四条commit记

    2024年02月08日
    浏览(59)
  • Git进阶之代码回滚、合并代码、从A分支选择N次提交,合并到B分支【revert、merge、rebase、cherry-pick】

    B站视频地址: https://www.bilibili.com/video/BV1KX4y1a7N9 Git学习文档:https://d9bp4nr5ye.feishu.cn/wiki/PeDPw3mm3iFA36k9td9cVeignsZ 在很长一段时间里,我对Git的操作只限于:提交代码,拉取代码,合并代码。 虽然上面这些操作在日常工作中也足够了,但不会点高级知识不利于装X,今天我们来学

    2024年02月08日
    浏览(80)
  • Git 使用 rebase 修改历史提交记录

    运行以下这条命令之后,它会打开一个vim编辑器,我们就可以修改上一次commit时输入的提交信息。 接下来你要是想修改描述信息的话,直接键入: i ,此时进入了输入模式。 可用键盘上下键转到描述所在的那一行,然后进行修改。 修改完成后,按下 Esc  键退出编辑模式,在

    2024年02月02日
    浏览(54)
  • git rebase合并多个commit记录

    在做一个需求的时候,会出现多次提交记录,如下: 其中,发现中间有三次提交的记录一致,是可以合并成一次commit的 下面开始合并: 1.找到要合并的commit 命令 其中 -i 的意思是–interact,即弹出交互式的界面让用户编辑完成合并操作 [startpoint] [endpoint]是前开后闭的区间 [

    2024年02月07日
    浏览(42)
  • 使用 git rebase 合并多个 commit

    首先我们查看一下当前提交历史: 我们通过 git rebase -i 61e7d87 将 44f23cb 、 9d2725f 和 da3ba01 这三个提交合并,这里的 61e7d87 为 待合并的提交区间的前一个提交的哈希值 。 执行之后会进入到 vim 编辑器中,每一行代表一个 todo 项。我们这里需要 pick 第一个提交并将后面两个提交

    2024年01月25日
    浏览(51)
  • 使用git rebase合并多次commit

    可以对某一段线性提交历史进行编辑、删除、复制、粘贴;因此,合理使用rebase命令可以使我们的提交历史干净、简洁! 但是需要注意的是: 不要通过rebase对任何已经提交到公共仓库中的commit进行修改(你自己一个人玩的分支除外) 基本格式如下 其中-i的意思是–interacti

    2024年02月09日
    浏览(54)
  • 【随笔】Git 基础篇 -- 分支与合并 git rebase(十)

    💌 所属专栏:【Git】 😀 作  者:我是夜阑的狗🐶 🚀 个人简介:一个正在努力学技术的CV工程师,专注基础和实战分享 ,欢迎咨询! 💖 欢迎大家:这里是CSDN,我总结知识的地方,喜欢的话请三连,有问题请私信 😘 😘 😘 您的点赞、关注、收藏、评论,是对我最大

    2024年04月14日
    浏览(38)
  • git:使用git rebase合并多次commit为一个

    git log:找到需要合并的最早 commit 的父级 git rebase -i 73a5cd8597 除第一个 pick 外,将其它改成 s,改完后保存退出 保存完后弹出 commit message 合并提示,根据这次合并的目的,重写commit message,改完后保存 修改为: 做完上述操作后,自动合并多个 commit 合并成为一个并提交,并生

    2024年01月25日
    浏览(51)
  • 【git merge/rebase】详解合并代码、解决冲突

    目录 1.概述 2.merge 3.rebase 4.merge和rabase的区别 5.解决冲突 在实际开发中,一个项目往往是多个人一起协作的,头天下班前大家把代码交到远端仓库,第二天工作的第一件事情都是从服务器上拉最新的代码,保证代码版本的一致性。在这种团队协作中大家修改到同一份文件是难

    2024年02月08日
    浏览(56)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包