git rebase 那么重要么???

@nightwitch #6 搜一下 git rerere

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

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

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

啥叫 rebase ?

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

而为什么 master 要 merge dev 分支？


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

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

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

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

有 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

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

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

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

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

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

@k9982874 kpi 精髓

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

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

有段时间挺喜欢用 rebase 的

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

参考：rebase -i

200 多个 commit 有点恐怖了

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