如题,在我职业生涯里这种情况很少见,不过在现在公司的工作流中居然很常见,各种奇葩的 merge ,但凡碰到我是 reviewer 应该就会毙掉了。 同事的解释基本是直接在 SourceTree 里操作拉取的,默认是 merge 操作,所以就这样了。我看了一下其实是支持 rebase 选项的,应该只是不会用而已。纯吐槽了,反正我不是 reviewer 。我并不是完全反对 git merge ,比如在一个 feature 分支完成后准备合并发版的的时候,feature 分支 merge 到 develop 再到 master 是完全可以接受的。除此之外都是不可理喻的。
感受一下 merge history 的恐惧吧,这是我在 SourceTree 里把 Graph 列拉到最大的效果,有些还没显示出来。
大需求,如果是模块化的,一步到位的,squash 后再 rebase master 。如果不是模块化的,冲突很多的,直接 merge master ,这样也保留原始提交信息。
当然如前面有人说的,这种模式一旦遇到冲突,可能要多次反复解决冲突。比较麻烦。至于 Merge Request 这种 post-commit ,几乎是非 Gerrit 管理的项目的实际上的唯一可靠的模式。Gerrit 需要组里有足够的熟手。而 MR 只需要一个老手加若干新手就能转起来。所以别纠结。
术语 Merge Request 和 Pull Request 实质几乎是一样的,主要是 Gitlab 用前者,Github 用后者。所以 IDE/Tools 在生成 commit log 时,用词可能比较随意。(回想当时用 Gerrit 之前,我们的库就是托管在 Github 上,但是不使用 PR ,所有人都有权限直接往库里 push 。有的人会 rebase 一下,有的人直接来。)
后来再也没有在有 CR 的团队里上班 !
我现在的办法是 合并这些 commit ,然后再 rebase ,但其实我是希望保留 commit 记录的,各位彦祖有啥好办法么?
是否保留分支历史 ✅ 是(有合并节点) ❌ 否(会“平铺历史”,重写 commit )
是否修改 commit hash ❌ 否 ✅ 是,commit 会重写
是否生成 merge commit ✅ 默认生成 ❌ 不会生成
是否易于理解协作历史 ✅ 是(真实历史) ❌ 否(历史被改写,适合单人开发)
是否容易冲突 🔁 重复合并可能冲突 ⚠️ 频繁 rebase 更容易遇到冲突
应用场景 分支合并(多人协作常用) 清理分支历史(个人分支、PR 前整理)
多人协作不是 merge 更好吗,保留了真实历史
只要少数对这方面有想法的人,才会使用 rebase 或者 squash