• 大家觉得Pull Request允许包含merge commit 吗?
  • 发布于 11小时前
  • 8 热度
    13 评论
  • Flower
  • 0 粉丝 28 篇博客
  •   
如题,在我职业生涯里这种情况很少见,不过在现在公司的工作流中居然很常见,各种奇葩的 merge ,但凡碰到我是 reviewer 应该就会毙掉了。 同事的解释基本是直接在 SourceTree 里操作拉取的,默认是 merge 操作,所以就这样了。我看了一下其实是支持 rebase 选项的,应该只是不会用而已。纯吐槽了,反正我不是 reviewer 。我并不是完全反对 git merge ,比如在一个 feature 分支完成后准备合并发版的的时候,feature 分支 merge 到 develop 再到 master 是完全可以接受的。除此之外都是不可理喻的。
用户评论
  • 飛雲
  • 感受一下 merge history 的恐惧吧,这是我在 SourceTree 里把 Graph 列拉到最大的效果,有些还没显示出来。

  • 2025/7/3 16:20:00 [ 0 ] [ 0 ] 回复
  • 若如初见
  • 小需求,直接 rebase master
    大需求,如果是模块化的,一步到位的,squash 后再 rebase master 。如果不是模块化的,冲突很多的,直接 merge master ,这样也保留原始提交信息。
  • 2025/7/3 16:17:00 [ 0 ] [ 0 ] 回复
  • 摇滚枷锁
  • 取决于 merge commit 是不是反映必要的客观现实吧。如果你带进来的 merge commit 真就是因为多个人合作而产生的,或者有些 pipeline 有一些自动的处理,那就带进去。如果仅仅是因为你自己没用好工具造成的,比如改完后 git pull 一下在本地生成的 merge commit ,那是完全不应该的。总体来说,我认为 PR 里面带进来必要的 merge commit ,是不多见的。我以往的工作经验中,绝大部分都是因为本地的 git pull 生成的 merge commit ,这种我都会打回去。
  • 2025/7/3 16:16:00 [ 0 ] [ 0 ] 回复
  • 追梦魂
  • 好早之前曾经在一个有一点 Google 脉络的组上班,其中 CodeReview 用的是 Gerrit 。也就是说这种提交模式( pre-commit )会导致我们一个提交会因为等待打分,导致做好多次 rebase 。rebase 的结果导致提交线直直一根很漂亮。可能会丢失实际开发信息,但是从成果角度看,丢失的信息也无所谓,丢失也是一种整理过程。

    当然如前面有人说的,这种模式一旦遇到冲突,可能要多次反复解决冲突。比较麻烦。至于 Merge Request 这种 post-commit ,几乎是非 Gerrit 管理的项目的实际上的唯一可靠的模式。Gerrit 需要组里有足够的熟手。而 MR 只需要一个老手加若干新手就能转起来。所以别纠结。

    术语 Merge Request 和 Pull Request 实质几乎是一样的,主要是 Gitlab 用前者,Github 用后者。所以 IDE/Tools 在生成 commit log 时,用词可能比较随意。(回想当时用 Gerrit 之前,我们的库就是托管在 Github 上,但是不使用 PR ,所有人都有权限直接往库里 push 。有的人会 rebase 一下,有的人直接来。)

    后来再也没有在有 CR 的团队里上班 !
  • 2025/7/3 9:22:00 [ 0 ] [ 0 ] 回复
  • 枪蹦狗友
  • 没感觉到 rebase 在多人协作中的优点,除了 commit 看起来纯净,还有啥好处呢? merge commit 可以看到所有的操作记录,不是更好吗?
  • 2025/7/3 9:13:00 [ 0 ] [ 0 ] 回复
  • 青墨断笺
  • 可以 pr 合并的时候在 squash merge 吧,merge commit 经常是不好避免的,比如 review 已经开始了之后 pr 跟 main 有冲突,这时候 merge main 比 rebase main 更合适,rebase 就把 review 的历史搞乱了
  • 2025/7/3 9:10:00 [ 0 ] [ 0 ] 回复
  • 白笙枫客
  • rebase 有个问题,一旦某个文件每个 commit 都有冲突,那 rebase 就需要多次解决冲突
    我现在的办法是 合并这些 commit ,然后再 rebase ,但其实我是希望保留 commit 记录的,各位彦祖有啥好办法么?
  • 2025/7/3 9:08:00 [ 0 ] [ 0 ] 回复
  • 白衣煮茶
  • 特性 git merge git rebase
    是否保留分支历史 ✅ 是(有合并节点) ❌ 否(会“平铺历史”,重写 commit )
    是否修改 commit hash ❌ 否 ✅ 是,commit 会重写
    是否生成 merge commit ✅ 默认生成 ❌ 不会生成
    是否易于理解协作历史 ✅ 是(真实历史) ❌ 否(历史被改写,适合单人开发)
    是否容易冲突 🔁 重复合并可能冲突 ⚠️ 频繁 rebase 更容易遇到冲突
    应用场景 分支合并(多人协作常用) 清理分支历史(个人分支、PR 前整理)
    多人协作不是 merge 更好吗,保留了真实历史
  • 2025/7/3 9:04:00 [ 0 ] [ 0 ] 回复
  • 温酒书生
  • GitHub 默认行为吧。所以绝大部分人 merge 的时候,都会包含 merge commit 。
    只要少数对这方面有想法的人,才会使用 rebase 或者 squash
  • 2025/7/3 8:44:00 [ 0 ] [ 0 ] 回复
  • 今夕何夕
  • 你觉得不合理的可以提出来,大家一起讨论如何优化。这就是你的绩效亮点之一。回到这个事情上来看,你的想法没错。
  • 2025/7/3 8:43:00 [ 0 ] [ 0 ] 回复