将 dev 合并到 master 的时候， 你们使用 merge 还是 rebase ?

[jeesk]

1. 如果使用 merge 会多出一条记录 ， Merge remote-tracking branch 'origin/dev' 的记录，比较难看.
2. 如果使用 rebase 的话， 就会成为一条线.


你们公司是怎么用的？

我自己一直很反感在 master 分支上去 rebase 时间线会乱掉看着很难受。

在我参考一些大型的开源项目，得到了一些经验。
一般 master 都是 merge 开发分支，接收 pr ，可以明确知道某些功能的引入点，对于产品把控能力更强。这是对于代码管理者的角度来看的。至于 merge 的角度这条记录，通过改记录可以查看到一个功能是什么时候引入的。

对于开发者的角度， 自己的代码在开发分支，到底是 master merge 还是 rebase.根本不在乎， 反正只需要知道代码合进去了，这对于个人项目貌似没问题。

所以我们能够看到，类似于 apache ，chromium ，firefox 多数采用第一种。 而普通人没有大型项目或者说产品规划的实鉴，更加倾向于使用 rebase 。

[gauzung]

rebase

[fgwmlhdkkkw]

我认为就不应该有 rebase 这种操作，，

[xiangliudev]

fast-forward merge 不是也可以是一条线吗？
然后其他分支 merge 进 master 之前 rebase master 即可。

[bruce0]

我都是 dev 同步 master 的时候 rebase, dev 弄好了, merge 到 master

[Sezxy]

merge --squash

[agagega]

如果你不是 leader ，纠结这个没有意义。如果你是 leader：假如合并代码这个人归你管，让他用 rebase/squash ；假如来自另一个团队不归你管，则用 merge

merge 应该反映开发团队的人员架构，rebase 的时间线错乱并不是什么问题，实在不喜欢 amend 下就行。在找 bug 的时候，清爽的提交历史会方便很多。但其实最重要的是每个提交得有意义，一大堆杂乱无章的提交不管用 rebase 还是 merge 都难受

[94]

dev 分支 rebase 到 master 最新的 commit 之后你用 merge 还是 rebase 都是一样的。

[jeesk]

@dfkjgklfdjg 其实是不一样的， 参考 github 的开源项目即可 。
很多开源项目能够通过 merge 明确知道一个什么时候引入分支得，但是 rebase 却不行。 对于产品功能把控很难搞。

[daozun]

如果你自己一人使用的分支，master 上有最新提交，rebase master 到自己分支上，如果你和别人共用一个分支，使用 merge 合并别人的提交，这样好追溯。

[cutiechi]

merge fast forward

[Navee]

merge ，降低心智负担

[94]

@jeesk #8 ，所以得看开发流程中提交合并是否有 PR/MR ，和 CR 的流程。
如果没有，那么 rebase 之后合并和 merge fast forward 合并是一样的。

并且很多人在 merge 里面解决冲突时可能会手动改动代码，而不是单纯选择当前代码 or 传入的代码，这样就会造成其他的问题。

其实完整的流程应该在本地分支 rebase 到 master 最新提交之后，再提交 PR/MR 。在分支解决完所有问题之后再合 PR 到主线。
但！实际开发过并不会有那么完善的流程，很多同事也不会遵守你设置的提交 PR 检查通过之后才能合并的规则，就会造成我上面说的隐患问题。

[94]

@dfkjgklfdjg #12 ，master 上面是不允许 rebase 的，rebase 的操作是开发人员对于自己的 dev 分支去基变，保证自己代码合并回主线时不会出现冲突（已经在自己的 dev 分支解决完了冲突代码，这样后续业务出现问题了也方便溯源）。
并不会出现在 master 上面 rebase 然后 push -f 这样的操作。

[dumbass]

一个人维护项目，我用 热巴色

[IvanLi127]

dev 分支如果是公用的，那就 rebase ；如果每个人或者每个功能点自用的，那就 merge 。

公用 dev 分支我觉得是没啥用。

[jeesk]

@bojackhorseman 是啥呀，我没搜索到

[xzysaber]

@jeesk #16 rebase ，^_^

[Katrol]

无法保证团队分支管理水平的话，还是 merge 吧

[tyrone2333]

rebase 等你出了一个线上事故就老实了,自己单人项目玩玩是可以用

[Rache1]

我就奇了怪了，总有人说 merge into ... 不好看，你们是没事儿就盯着这东西看吗。再说了，这也只是众多提交记录中的一条而已，你要是觉得这个默认的不行， 你还可以自己编辑这个 commit 信息

[happyxhw101]

压缩提交

[iceprosurface]

一般 rebase merge ，merge 只是为了到时候可以快速 revert 而已

[zhenjiachen]

直接用 git lab 自带的 rebase , 其它分支要合并必须先 merge main 分支最新代码。因为我们是用 merge request 来审核代码，审核会有多次提交，rebase 可以把这个分支所有的提交都合并为一个提交。这也可以优化 main 分支的提交数量，也能同时知道这个 request 改了哪些东西。

[EastLord]

master rebase 到 dev, 然后提 pr ，可能会用到压缩提交

[iintothewind]

用 merge, 别管区别,
总之一句话,
与其委屈自己,
不如为难别人.

[wu00]

rebase/merge 都不重要
重要的是如何让开发提交的每个 commit 都是单一且完整的，以及对一些大功能 commit 的粒度把控。

[4BVL25L90W260T9U]

不要让我看到 merge remote tracking branch master 这种智障操作就好……

[msg7086]

可以看出来上面有很多人都没搞清楚 rebase 到底是一个什么操作。
比如 @dfkjgklfdjg #13 就以为 rebase 必然会需要 force push 。

[kera0a]

merge 别人，rebase 自己

[msg7086]

@xiangliudev 在楼主给定的条件下，fast-forward merge 和 rebase 和 reset hard 其实是同一个操作。

[lhp96]

回滚的时候，排查问题的时候，哪个更好呢？

[leonshaw]

一般来说小的 feature, bugfix 分支合并前先 rebase ，大的分支 (dev->master) 不 rebase ，有冲突的时候很难保证 rebase 后每个 commit 都是好的。Merge commit message 写清楚改动和冲突解决情况，这点可以参考一下 linux 内核，Linus 还针对这个问题吐槽过 github. 即使 rebase 过，合并时也可以视情况 no-ff 来保留分支历史。

[jim9606]

私家分支用 rebase,公共分支用 merge,只要分支有被多个人使用，就不要用 rebase 。
如果你不拿远程仓库当同步盘用，私家分支是只会在你的本地仓库里的，也不需要用到 forcre push,这时用 rebase 没啥问题

[jeesk]

@lhp96 你问到点子上了。 如果是回滚，那么肯定是 merge 好。 比如你在今天 merge 了一个分支的操作，那么你可以直接通过时间线， 获取到这个功能的合入时间，那么 直接 revert 掉这个 coomit 就行了。 这个完全可以参考 chromium 项目 merge 和 revert 操作。

[94]

@msg7086 #28 ，所以你其实也没有理解我为啥会举一个 push -f 的例子。很多人以为 rebase 就一定会修改远端的 commit history 。
其实在本地 dev 分支做好 rebase 解决完本地的 dev 分支和和 master 的分支 之后再把 dev 通过 PR 或者直接合并（再次 rebase/merge ）回 master 的时候并不需要 push -f 。

其实只要给开源项目贡献过 PR 其实都知道在提交 PR 之后 rebase 分支是在干啥。

[rrfeng]

merge

rebase 只用在其他分支上，用于太落后 master 的时候（其他分支 merge 了导致大量冲突）。

[cirzear]

先在开发分支上 rebase, 再 merge 到主分支

[sagaxu]

我一般不用 rebase ，比较常用

git cherry-pick

git merge

git merge --squash

git reset --soft master && git commit -am 'xxx'

hotfix 和 feature 处理方式是不一样的

[msg7086]

@dfkjgklfdjg 不好意思一眼看岔了。

[mywjyw]

merge --no-ff ，某大厂强制要求

[srlp]

在 dev 上 rebase master ，然后从 master merge dev 进来。

[Pinealxx408]

git pull --rebase 就不会有 merge 了

[Cola98]

merge

[luckrnx09]

Rebase+Squash ，每个 PR 合并后只有一条 commit ，很清爽。

[Jet]

不管用哪个, 有人习惯把 git commit/push 当 save code 用就难崩。