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

[jeesk]

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


你们公司是怎么用的？

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

[gauzung]

rebase

[fgwmlhdkkkw]

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

[xiangliudev]

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

[bruce0]

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

[Goooooos]

merge --squash

[agagega]

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

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

[dfkjgklfdjg]

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

[jeesk]

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

[daozun]

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

[superchijinpeng]

merge fast forward

[Navee]

merge ，降低心智负担

[dfkjgklfdjg]

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

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

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

[dfkjgklfdjg]

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

[bojackhorseman]

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

[IvanLi127]

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

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

[jeesk]

@bojackhorseman 是啥呀，我没搜索到

[xzysaber]

@jeesk #16 rebase ，^_^

[Katrol]

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

[tyrone2333]

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

[Rache1]

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