Pull Request 允许包含 merge commit 吗

[xingheng]

在我职业生涯里这种情况很少见，不过在现在公司的工作流中居然很常见，各种奇葩的 merge ，但凡碰到我是 reviewer 应该就会毙掉了。 同事的解释基本是直接在 SourceTree 里操作拉取的，默认是 merge 操作，所以就这样了。我看了一下其实是支持 rebase 选项的，应该只是不会用而已。

纯吐槽了，反正我不是 reviewer 。

[94]

我看别人会不会用 git ，或者操作的 git 的熟练度，就是看一个人对于 rebase 的理解。

PR 要不要保留最后的 merge commit ，是看仓库作者的想法。这个在仓库里面是可以设置的。不是贡献 PR 的人该考虑的问题。

-----

如果是日常工作中的出现的 `Merge remote-tracking branch 'origin/master'` 或者 `Merge branch 'master' of 'http://xxxxx'` ，恕我直言：不是菜，就是懒。

[greycell]

@dfkjgklfdjg 本来 repo 设置的问题，被搞成 merge 和 rebase 的矛盾我是没看懂。设成 pr 必须没有 conflict ，必须 squash merge 是不会吗。

[thulof]

好多人说 rebase 模式下多 Commit 解决冲突很麻烦云云。那既然都 rebase 了，就小步 Merge Request 、频繁提交呗。
为啥非得自己搞个大分支，和主干分叉很久之后再 rebase 主干解冲突，然后提个超大 MR ？恶心自己也恶心别人

[94]

@greycell #42 ，挺多人其实不怎么会用 git ，也不会看仓库设置里面有一些什么东西，或者就是嫌麻烦。

听到最多的就是："我这样用着挺好的，凭什么要听你的？"。

[xingheng]

感受一下 merge history 的恐惧吧，这是我在 SourceTree 里把 Graph 列拉到最大的效果，有些还没显示出来。

[xubingok]

develop 向 master 这种的,分支之间用 merge.
develop 或者 feture 分支内部的,多人开发用 rebase.

[weiwenhao]

正确的做法是什么呀？

公司现在协作的方式是基于 master 创建 feature 分支(根据测试情况包括多次 commit ，持续几天)，然后会在合并到 master 之前，会 merge master 中最新的代码到 feature 分支，处理一下冲突，然后再提交 pr 到 master 。

[suiyun39]

我的做法是：其他分支怎么玩都无所谓，爱怎么折腾怎么折腾，但 master 必须保持线性提交（这个是有分支保护规则的）。当最终合并到 master 的时候，只允许使用 Squash Merge 把提交压缩成一条。特殊情况允许 Rebase Merge 来保留一定的提交历史（但必须提前 rebase 一次剔除掉杂音）。

[wenrouxiaozhu]

@suiyun39 "只允许使用 Squash Merge 把提交压缩成一条"
rebase 后再 merge -no-ff 更好一点？这样主分支上只有线性的 merge commit+可以保留 feat 分支历史记录
https://zhuanlan.zhihu.com/p/616897004