git rebase 那么重要么???

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

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

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

bisect

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

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

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

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

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

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

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

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

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

别的不说，挺卖力的

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

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

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

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

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

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

至于什么时候提交：

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

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

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

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

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

我 4 年都没 200 多个 commit 。

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

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

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

我们只允许 squash, and rebase

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