git rebase 那么重要么???

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

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

确实不专业

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@zeromake #8 搜一下 git rerere

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