git rebase 那么重要么???

[hanxu317138]

用了二周开发了一个需求, 提交了 200 多个 commit, 到主分支的时候. 被告知太不专业了. 为什么不 rebase 一下再上传.

我试着 Rebase 了一下 master, 各种冲突解决的要命, 所以问问大家. 你们合代码看重 rebase 么?

[hetal]

我们只允许 git merge ，不允许 git rebase~~~

[chesha1]

rebase 之后 git 历史看上去更线性一点，更好看，你不 rebase 的话，唯一的好处就是多保留一点点从哪分叉出来的历史记录，但是这个历史记录也没啥用，而且 git 记录会很丑

而且 200 多个 commit 也太吓人了，建议还是先 squash 一下，不然你解决冲突要一个个解决，会更不好处理冲突

[k9982874]

2 周？ 200 多个 cimmit ？你需要拆分需求缩小提交粒度

[kera0a]

rebase 和 merge 解决的冲突不是一样的么？

[liangdi]

我觉得还是要看一下你的 log

[nightwitch]

你往主分支合并的时候不是应该压缩成 1 个 commit 再提 pr 么。
而且你不压缩的话 rebase master ，解决冲突要 200 个 commit 一个一个解决过去，这就是你说的解决的要命..

[hanxu317138]

我在 rebase 的时候. 要从头走一遍历, 中间好多冲突....在 continues 过程中. 都要处理.
@nightwitch

[zeromake]

@kera0a #4
不一样 rebase 需要一个一个 commit 去解决的……，如过在某个地方不停的更改提交有你爽的……

[hanxu317138]

master 的冲突已经解决完了. 可以直接 Merge 的~~但是要 rebase 就很痛苦

[povsister]

你如果 rebase 会冲突 那合并一样会冲突，这有什么好吐槽的？

另外如果谁两周做一个需求合并主分支 200 多个提交，容我先找把扫把你就在这不要走动，搁保洁阿姨都知道倒垃圾是倒一次还是倒两百多次。

[houshuu]

如果不 squash merge 的话，在 commit merge 强烈推荐 rebase 。

不过话说回来，除非 200 个 commit 都是独立的模块化改动，否则 200 多个 commit 加入主 branch 说实话意义不大。
就算事后出问题总不能单独 revert 其中一个 commit 吧，200 多个大部分 commit 估计修改部分都互相依存了。
结果上看还是要大规模批量 revert 然后修改后再重新 release ，对比来说 revert 一个 squash 的 commit 还便捷一点。
所以我个人习惯上尽量保持一个功能改动 squash merge 一次。如果很复杂的话拆成几个 PR ，还能降低 code review 的理解成本。

[zeromake]

倒是可以把自己本地的分支变更全部压成一个 commit ，但是这样就和之前的开发分支冲突了……，如果你之前已经合并到开发服里就爽到了……

[hanxu317138]

@povsister 对一个非常大的历史代码, 进行重构处理. 2600+行的代码. 二周压缩到 800 行内. 中间多次 commit

[qxooqx]

1.在第 290 个提交上创建一个新分分支防止操作失误
2.把 200 个提交 rebase 成一个 commit
3.然后将分支 rebase 到 master 上最新 commit
4.处理冲突
5.提交需求

[hetal]

一般超过 1 周的开发，就应该拉单独的分支了

[jiangshanmeta]

rebase 后整整齐齐，避免出现 merge xxx into xxx
一个分支的新代码 squash 成一个 commit ，和 jira 单颗粒度对起（原谅我用这个词）
而且一个两周的工作 story point 有点大，可以考虑拆分
rebase 应该比较频繁，例如每天和主分支同步，避免最终提交时一堆冲突

[povsister]

@hanxu317138
开发周期长才应该尽可能使用 rebase ，同时保持提交记录语意清晰，同步主干分支修改时尽量使用 rebase ，你一直 merge master 去同步苦果就是这样。

鉴于你现在情况，直接 squash commits 到一个然后 rebase 吧，反正都这样了，你大概也没拆语义化提交

[aliipay]

这么多问号感觉是在质问别人，感受不是很好

[dcsuibian]

有一种观点认为，仓库的提交历史即是 记录实际发生过什么。 它是针对历史的文档，本身就有价值，不能乱改。 从这个角度看来，改变提交历史是一种亵渎，你使用 谎言 掩盖了实际发生过的事情。 如果由合并产生的提交历史是一团糟怎么办？ 既然事实就是如此，那么这些痕迹就应该被保留下来，让后人能够查阅。

另一种观点则正好相反，他们认为提交历史是 项目过程中发生的事。 没人会出版一本书的第一版草稿，软件维护手册也是需要反复修订才能方便使用。 持这一观点的人会使用 rebase 及 filter-branch 等工具来编写故事，怎么方便后来的读者就怎么写。

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

以上内容来自《 pro git 》，个人更赞同第一种观点。所以我比较讨厌 rebase 。

我比较喜欢用 git merge --no-ff --no-commit

[IvanLi127]

rebase 很重要，自己分支的代码要尽快 rebase 开发主干分支，避免落后太多导致最后要合入主干时一直在解决冲突。你这 200 多太要命了。

[povsister]

@dcsuibian
事实上是
no one gives a shit about what you have done in your place

[otakustay]

如果你 200 多个 commit 做的是一个事，本地先 squash 以后，再 rebase 一次，再 push 就好了啊

[zmxnv123]

确实不专业

[jqtmviyu]

我喜欢 rebase, 有时间上的线性.

[unco020511]

我觉得你这个场景的分歧是「 feaure 」分支往 dev 合并时，是否需要 squash 。并不是 MR 之前功能分支要不要 rebase 主干，有啥区别？如果主干和你有冲突，那你的 MR 本来就合并不了，你的 MR 能合并，就说明不存在冲突，那么你在提 mr 之前 rebase 了主干，对于主干来说，没有任何区别呀

[11232as]

rebase 相当于将你的代码从原来老版本的主干迁移到最新的主干，解决代码冲突的同时，也能发现和解决在你开发的这两周里与已提交到主干的代码的业务冲突。
我们这边的流程是从当前生产 master 建需求分支开发需求，完成后提到测试分支上，如果是跨版本级别的需求，要求每个新版本都进行 rebase 后再测试与合并。

[bingoso]

我用 git 管理笔记，两周都做不到 200 个提交。你这提交太多了

[StephenHe]

rebase 也好，merge 也好，都是为了把主分支内容同步到自己分支。楼主的问题是太长时间不同步代码导致了很多冲突。

[StephenHe]

test ，master 向子分支 rebase ，子分支向 test ，master 只通过 merge ，让时间线看起来是一个正向操作。

[mark2025]

@hetal 我是全局 git config --global pull.rebase true ，拉取合并之前就 rebase

[angryfish]

1.你是如何做到 2 周 commit 200 多次的？
2.我习惯 merge
3.rebase 还是 merge ，看团队规范，大家怎么做，你就怎么做。

[c0t]

才 2600 行就 200 次感觉 commit 里都是无效信息…写了点就 commit ？中间可能压根就没法用吧？喜欢这么用的话就用 branchless 的方法，detach 然后准备合并再 squash

[c0t]

git branchless 这样的工具应该就是给你现在这种用法设计的

[XiLemon]

比较好的做法是在开发过程中，每次开发前和每次 commit 后都 rebase 一下 master 分支。最后提交合并的时候，可以将开发分支的 commit log 进行合理的 squash 。

[thevita]

我的习惯，如果预期自己本地的分支会持续很长时间不能合并的话，此时应该考虑

1. 看能不能拆成多个 提交分批合并, 对 review 的人也友好点
2. 每天上班第一步 pull --rebase
3. 最后 提交 mr 前, 对提交进行 squash 整理，保证每个 commit 都是完整且正确的

[gesse]

其实我想说，OP 提交两百个 commit 到 master/main ，已经不是 rebase 和 merge 的事情了。

[lrh3321]

如果你 200 多个 commit 都对应 1 个 Feature 的话，应该先把提交合并了。rebase 的时候就没那么痛苦了。

[hanxu317138]

最新进展~~~把 rebase 搞了一下. 成功回到了 1 个 commit,同步到最新的功能.

[zbowen66]

@zeromake #8 搜一下 git rerere

[magic3584]

@nightwitch #6
@zeromake #8
我想我可能知道为啥同样地方冲突我要解决多次了。
之前我都是 pull rebase ，后来发现 merge 的时候要重复解决一个地方，后来就换 pull merge 了

[zbowen66]

@nightwitch #6 搜一下 git rerere

[goldenAndGreen]

我们强制要求 squash,想想看万一有一个搞出一个 bug 需要 revert ，如果后续还有别人的提交,那简直灾难

[newtype0092]

啥需求需要 200 个 commit ？你纯把 commit 当历史记录用呗？

[Vegetable]

那是你没搞明白，确实很不专业。如果你是基于 master 分支开发，且能直接 merge ，rebase 是不应该有冲突的。

[jeesk]

啥叫 rebase ?

一个 dev 分支为什么要 rebase master ? 这点搞明白没？

而为什么 master 要 merge dev 分支？


chromium 项目为什么在分支持合并代码都是 merge , 而开发分支都是 rebase master ?

学习大型项目的管理办法， 比听阿猫阿狗的，进步太快了。

[NarutoAsh]

一看就是 git 都用不明白的人……

[DefoliationM]

看中，连 rebase 都不会用，太不专业了，你自己看着乱七八糟的 commit 历史不难受吗，稍微有点代码规范的公司都不会让你随便写 commit 历史的。

[memorycancel]

有 2 个问题：
1. commit 太大了，拆分为几个小的，或就 1 个？
2. 没有 code review 吗 直接 merge 进 master ？

你需要：
1. 切换到你的开发 feature 分支
2. 更新最新 master/main 的代码到开发分支
3. 把你的代码 squash 为 1 个 commit （ resolve conflict)
4. 提交 MergeRquest （ or Pull Request ）

[finian]

你这种情况就别 rebase 了，搞不好会丢改动。先抛开最佳实践问题不谈，你现在其实可以：

```
git merge --no-ff --no-commit
```

将你的所有改动 merge 到 master ，但先不做 commit ，解决冲突（不管 merge 还是 rebase ，该解决的冲突逃不掉），然后 commit 成一个新的特性分支，再接着往下走流程。现在你的改动就只有一个 commit 了（不谈规范和最佳实践问题），然后按你团队的规范，该 merge merge ，该 rebase rebase

[msg7086]

先 squash 再 rebase 再 merge 就行。
每一个操作都有自己该用和不该用的场景，正确的做法是在正确的场景用正确的操作。

[msg7086]

@dcsuibian #19
这两种观点并不是完全冲突的。
保留历史的细节程度和历史的尺度有关。比如说你遇到了生产事故，需要写事故处理记录，你当然要把每一分每一秒每一次事件都记录下来。但如果你是在写上下五千年的史书，那会有人关心你某一天下午 2 点的时候打翻了一杯水吗。
我司在开发的比较大的项目，尺度基本是上下十年，一个工程师一个月交两个功能，一个 team 下 50 个人一个月就是 100 个功能，一年 1200 个，十年 12000 个，假如平均实现一个功能有 10 个提交，那就是 12 万个提交，你光是要查两三个月前某个提交的 bug 就得翻不知道多少页才能找到，就非常不方便。这还是 master 分支，你要再加上 release 分支测试分支就更多了。所以我们要求所有合并到主线的提交都是 squash merge 。开发分支提 PR 的时候随便你多少个提交，最后全合一起。
如果是小项目，比如说 one man 项目或者一个 team 里两三个人协作，那可以把提交做得细一点，合并 feature 分支的时候用 merge commit 就没问题。

记录实际发生过什么这个也是有粒度的。严格来讲，每一次输入删除都是一次更改，但你肯定不会觉得每打一个单词都要提交吧。那么到底打多少个单词才需要提交一次呢，删了多少代码才需要提交一次呢。这个粒度把控，不同的人也有不同的观点的。

[msg7086]

（续）
总之 git 本身也不是一本史书，git 是一个 Source code management ，这个软件的核心目的是管理源代码，最终这个管理是要为软件开发和发布服务的，对软件开发和软件发布有益的做法就是正确的做法，如果一种做法导致软件开发变得困难，这种做法就应该被认定为是不合适的。如果提交历史一团糟，这个一团糟到底是改善了软件开发环境，还是影响了软件开发环境，你这样去判断，就能知道保留一团糟的历史是否是一件正确的事情。不要为了准确而准确，为了记录而记录，这是一个软件开发工具，不是史书编撰工具。

[wnpllrzodiac]

b 站一个视频，让 rebase 变重要了。没强迫症，感觉还好吧。就是 git 🌲有点乱。好的分支管理还是重要多了

[wnpllrzodiac]

@k9982874 kpi 精髓

[jzphx]

直接在自己分支 rebase ，然后基于 master 拉取新特性分支，将 rebase 完的一个 commit cherry pick 到特性分支，解决完冲突之后重新填 commit 信息，然后 push 提交 mr 。稍微有点繁琐，但是管用

[leconio]

调试舔 ci 脚本时候，没 rebase 简直灾难

[passon]

有段时间挺喜欢用 rebase 的

[kidlj]

这里 rebase 的意思是你把 200 个 commits rebase/squash 成一个 commit ，再 rebase/merge 到主分支。

参考：rebase -i

[EndlessMemory]

200 多个 commit 有点恐怖了

[leonshaw]

进永久性分支的一个基本原则是每个 commit 都自洽（能编译运行）。

[pkokp8]

说实话你做了一个功能，留了 200 多个 commit
下个星期问你第 121 个 commit 为什么这么写，鬼知道啊
不如把 200 个 commit rebase 成一个，然后 merge 到 master 上

[wu67]

你可以不用, 但是不能没有

[zpf124]

我的观点
1 、善用 rebase ，但不要滥用。

我不喜欢用 rebase 来合并分支，尤其是合并到 dev 和 master 这种关键节点，对于是否--no-fast-forward 我都可以接受，但拉取时还有从 dev 合并最新更新到我的分支时我还是会优先考虑 rebase 的。

因为很多时候你从什么位置 fork 以及你从远程分支拉取最新前有提交都是无关紧要信息。
比如你和别人各自开发功能然后他先合并至主线了，那你合并的时候，保留你和他是并行开发还是你在他的基础上开发其实对于多数产品没那么重要。

比如：
dev-> dev+a -> dev+a+c -> dev +a+c+b 或 （ dev merge(a + b)+c ）两种差异重要吗？ 你 b 分支需要别人关注吗？
dev -> dev + b ->↑


2 、善用 rebase -i （ squash / fixup ），尤其是 push 和合并到主要分支前，将零碎杂乱的无用提交都整合。

开发时 commit 提交无所谓毕竟 statsh 确实用着让人不安心，把 commit 但保存无所谓，但合并前最好将提交整理一下，尽量按功能模块让每个 commit 包含一小部分完整功能，没人关心你写一半的代码代码和之前有什么差异。

而你这 200 多个提交确实有点太多了.... 当然如果每个提交都有前后对比的价值那确实不应该合并。

比如:
feature-newxxx -> funA.setp1-> funA. step2-> funB.step1 -> merge(dev) ->funB.step2 -> funA.bugfix
feature-newxxx (rebase(dev)) -> feat: funA -> feat: funB

在这两种提交线路图里我更倾向于用最后 push 那个 rebase 修改过的第二种，你开发 A 功能中间自己思考草稿时的增删改对最终成品意义不大。


---------
最后，你们领导的意思是不是指我说的第二种啊， 希望你用 rebase 来将那些无用的中间过程的 commit 用 squash 或者 fixup 合成一个 Commit 。

[zhigang1992]

bisect

[zpf124]

第一个示意图勘误， 排版没搞好折行了。

dev-> dev+a -> dev+a+c -> dev +a+c+b 或 （ dev merge(a + b)+c ）
dev -> dev + b ->↑

[xylxAdai]

几百个的话还是推荐 rebase 一下。确实直接 mr 会扰乱 timeline

[xiaokangz]

确实不妥，一个需求 200 个 commit 对后面查看变更历史时会造成很大的困扰。更好的做法是在 merge 回主分支之前将对 master 做 rebase 并将所有 commits squash 为一个 commit 。

注重 Git 提交历史本身就是一种专业的态度

[devfeng]

自己的分支用 rebase -i ，处理一些方案变动导致的反复，合进主分支或多人协作的需求分支，用 merge

[tcper]

2 周工作日是 10 天，200 多个 commit ，平均一天 20 个 commit 。

你这一天 20 个 commit ，用 rebase 还是 merge 区别都不大了吧？

一天算你干 10 小时，半小时 commit 一次？

[uds9u32br]

别的不说，挺卖力的

[Edsie]

请使用 rebase - i 并使用 squash 将你那 200 多个 commit 整理好，不会有人想在 master 上看到你这么多 commit

[U2Fsd]

git 都用不明白的小白，为什么要网暴自己？

[dcsuibian]

@msg7086 你这个是工作流和提交的历史粒度的问题。

我没有把他当成史书来写，只是我觉得提交历史的整理不应以“模糊真实变更”为代价，过于简化的历史可能反而增加复杂性。

具体到你的场景，如果是我的话，我会创建一个中间分支，比如`dev`吧，将个人分支合并上去的时候用`merge --no-ff`，这样这个分支上看起来就只前进了一个提交。

当然具体选择什么样的工作流随你，你觉得什么样的工作流适合你都行。我只是说我比较喜欢`merge`。

至于什么时候提交：

我的观点是一个提交实现一个逻辑单元：

每次提交都应对应一个独立且完整的逻辑改动，例如：

- 实现一个功能。
- 修复一个 Bug 。
- 添加测试用例。
- 改善代码的性能或样式。

[est]

我试着 Rebase 了一下 master, 各种冲突解决的要命

如果你不 rebase 就没冲突了？？？

[idragonet]

我 4 年都没 200 多个 commit 。

[olderfe]

@hetal 可以先 rebase ，合并一些提交再 merge

[YienX]

@hanxu317138 #7 先压缩，再 rebase ，或者直接使用 merge ，不过我都建议先压缩成一个 commit ，也看你们公司的规定了，你合并到主分支的时候，肯定会有冲突，这些冲突肯定是要在你本地开发分支解决了才能合并到主分支的。

[cnhongwei]

哈哈，楼主被喷了。我来支持一下，我就喜欢 merge ，而不喜欢 rebase ，就喜欢看一棵大树。
二来，我也喜欢小幅提交，只是要一个完整的修改（不是一个完整的需求），就喜欢提交一下，因为现在使用 AI 软件，如果文件没有提交，点到一个地方，AI 会提示代码，键盘有时不注意碰到了，就把 AI 生成的代码带进去了，我喜欢保持 1 个小修改就提交，这样提交的时候看 diff 就很简单。
当然我是小团队，如果是大团队，自己没有话语权的话，还是改变自己的习惯，不要让自己痛苦。

[dayeye2006199]

我们只允许 squash, and rebase

[zhengwenk]

200 个提交，想想都不敢想，master 一下就被淹没了。

[changz]

小分支 rebase 上游不是基操吗

[janus77]

2 周 200 个=1 周 100 个=1 天 20 个，假如是 10 小时工作，那就是半小时一个，你真闲啊。。。

[guanzhangzhang]

自己一个分支上 rebase 后再提 merge 阿，主干更新太频繁，你自己本地分支太老就要

[guanzhangzhang]

@guanzhangzhang 给我发出去了，接上：git pull --rebase origin 主干分支名然后本地解决冲突，不然到时候提 merge 界面会显示冲突还得解决

[LanLiang]

先将自己的 commit 压缩成一个或几个有效的 commit, 然后 rebase 主分支, 最终效果是 PR 里面只会有一个或几个有效的 commit

[dfkjgklfdjg]

反正我看一个人会不会用 git ，就看他是怎么理解和使用 rebase 的。你说 rebase 重不重要……很明显能区分出来是不是熟练运用 git

[jackleeforce3615]

你自己先要把 200 个 commit squash 到一个 然后在 rebase 了再 push 啊

[rink9oled3]

@chesha1 果然我看《 loki 》 没理解错，tva 就是强制不断 rebase ，为了线性神圣时间线，不断删剪分叉和所谓不合理的代码变体。哈哈哈🤣