git rebase 那么重要么???

[hanxu317138]

用了二周开发了一个需求, 提交了 200 多个 commit, 到主分支的时候. 被告知太不专业了. 为什么不 rebase 一下再上传.

我试着 Rebase 了一下 master, 各种冲突解决的要命, 所以问问大家. 你们合代码看重 rebase 么?

[hetal]

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

[chesha1]

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

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

[k9982874]

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

[kera0a]

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

[liangdi]

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

[nightwitch]

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

[hanxu317138]

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

[zeromake]

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

[hanxu317138]

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

[povsister]

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

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

[houshuu]

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

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

[zeromake]

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

[hanxu317138]

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

[qxooqx]

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

[hetal]

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

[jiangshanmeta]

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

[povsister]

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

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

[aliipay]

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

[dcsuibian]

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

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

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

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

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

[IvanLi127]

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