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

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

OP

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

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

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

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

OP

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

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

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

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

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

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

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

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

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

OP

啥叫 rebase ?

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

而为什么 master 要 merge dev 分支？

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

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

有 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 ）

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

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

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

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

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

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

参考：rebase -i

我的观点
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 。

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

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

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

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

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

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

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

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

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

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

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

至于什么时候提交：

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

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

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

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

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