用了二周开发了一个需求, 提交了 200 多个 commit, 到主分支的时候. 被告知太不专业了. 为什么不 rebase 一下再上传.
我试着 Rebase 了一下 master, 各种冲突解决的要命, 所以问问大家. 你们合代码看重 rebase 么?

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

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

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

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

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

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

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

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

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

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

你如果 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 的理解成本。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

确实不专业

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