rebase 还是 merge？

[wiirhan]

大家在项目里合并代码是用 rebase 还是 merge ？ 两个远程分支合并，用 merge 会产生一个无意义的提交，次数多了分支线就很乱。

[charlie21]

为什么 ‘包含完整的提交历史记录’ 会是一个需要避免的问题？ 你瞎搞之后丢记录了怎么办 行为艺术吗

[mdyy777]

我选择 rebase

[MinonHeart]

一般原则 public branch 用 merge，private branch 用 rebase 。

但是用 rebase 后要怎么 revert/reset 这次 rebase 呢？

[cco]

我用的 merge，因为场景并不复杂，merge 和 rebase 都差不太多。

[dyxLike]

两个远程分支用 rebase 反而会乱吧

[libook]

我只知道当需要撤回合并操作的时候，特别是公司项目上线计划临时调整的时候，直接 revert merge 提交很方便，不知道 rebase 怎么处理，懂的可以分享一下。

个人觉得版本控制系统的核心价值是体现整个版本变更历史，使用 rebase 仅会留下提交，无法区分是合并操作还是提交操作，所以“merge 产生无意义的提交”可能连 Linus 本人都不赞同。

整理分支是另一码事，希望整理得多么“干净”取决于能接受丢失多少历史信息，就好比服务器每周五备份，周三的时候你想恢复周二的数据，对不起没有，只能恢复到上周五。

你可以不在一个分支上体现任何 merge 记录，但也同时放弃了利用 merge 记录做审计或操作的能力，如果综合权衡是适合当前项目管理的方案的话，也是可以的。

[securityCoding]

@libook 线上发版会基于 tag 来构建

[libook]

@securityCoding #47 不是每个 feature 一个 tag 吧，总会有合并操作的，打 tag 也是在合并完的分支上打 tag 。

[securityCoding]

@libook 我的意思是用 tag 作为版本号,这样就隔离了版本与代码合并操作过程

[leafre]

"merge 会产生一个无意义的提交" rebase 只是重播一遍，并不能解决无意义提交 的问题

[msg7086]

并入更改用 merge，散播更改用 rebase 。

人人都懂 Git 的小公司 merge 的时候可以用普通的 merge commit，不是人人都懂 Git 的公司（特别是参差不齐的大公司）或者合并非常频繁的大公司，可以善用 squash merge 。（我司一般都是 squash merge，因为合并太频繁了，经常 Rebase 不现实。）



↑ 理想的 timeline 应该是类似这样的。



↑ 大多数公司代码的 timeline 是这样的。

[reactna1ve]

感觉 2#的说法是合理的
本地分支同步 dev 用 rebase 保证本地的提交和顺序是清楚的
dev 同步 hotfix 、合入 feature 用 merge，保证操作的节点顺序以及方便 revert

我之前也比较喜欢用 squash merge，后来发现对于一个开发周期比较长的 feature，squash 到一起太容易丢 context 了。比如某几行修改是为了解决需求中的某个 bug，这时候提单个 commit，后续再看知道这个修改是干啥的；几千行的大修改，squash 到一个 commit 里，过几个月完全不知道这几行为啥要这么改……

[Biwood]

以前很少用 rebase，完全不知道有用 rebase 把提交历史记录整理一遍的说法，可能是每个人的习惯不同吧

不用 rebase 的好处是，每一个操作细节都清清楚楚的留下记录，提交记录重要的不是“简洁”、“好看”，而是可追溯性

[wangbenjun5]

merge 简单易懂，rebase 不是人人都会，另外 merge 包含完整的提交历史，这样出问题容易找人负责，谁改的谁写的一目了然，99%的公司都是 merge

[libook]

@securityCoding #49 这里讨论的问题是 merge 和 rebase，发生在打 tag 之前，似乎和 tag 关系不大。

[weiwenhao]

@oneisall8955 可以从 master 创建新的分支修复呀，也就是这么做的，但是定位问题然后修复上线用了 2 个小时。此时线上已经故障了两个小时了呀。 是比较严重的故障，需要立刻版本回退那种。

[Biwood]

由 2 楼的说法想到，这其实是一个思维模式问题，如果一直在主分支操作所有合并行为，包括解决冲突，那么可以一直用 merge 。如果操作主分支的人不希望承担解决冲突的责任，那么子分支用 rebase 的必要就来了。当然，直接把主分支往子分支合并也能解决一些问题，但这显然让分支流程变乱了，不管你坚持 merge 还是 rebase，都不推荐这么干。

[wingtao]

@weiwenhao 这种直接把 9.22 号的 pr revert 掉不好使么

[penghong]

主干开发+小批量提交+squash merge

[weiwenhao]

@wingtao 应该是好使的，但是都没用过呀。。。当时 gitlab 的 revert 试了一下没成功就没试了，主要是不熟悉。