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

2024-08-15 21:10:32 +08:00
 jeesk
1. 如果使用 merge 会多出一条记录 , Merge remote-tracking branch 'origin/dev' 的记录,比较难看.
2. 如果使用 rebase 的话, 就会成为一条线.


你们公司是怎么用的?

我自己一直很反感在 master 分支上去 rebase 时间线会乱掉看着很难受。
4165 次点击
所在节点    问与答
45 条回复
happyxhw101
2024-08-16 10:12:36 +08:00
压缩提交
iceprosurface
2024-08-16 10:13:40 +08:00
一般 rebase merge ,merge 只是为了到时候可以快速 revert 而已
zhenjiachen
2024-08-16 10:14:17 +08:00
直接用 git lab 自带的 rebase , 其它分支要合并必须先 merge main 分支最新代码。因为我们是用 merge request 来审核代码,审核会有多次提交,rebase 可以把这个分支所有的提交都合并为一个提交。这也可以优化 main 分支的提交数量,也能同时知道这个 request 改了哪些东西。
EastLord
2024-08-16 10:18:04 +08:00
master rebase 到 dev, 然后提 pr ,可能会用到压缩提交
iintothewind
2024-08-16 10:19:24 +08:00
用 merge, 别管区别,
总之一句话,
与其委屈自己,
不如为难别人.
wu00
2024-08-16 10:21:42 +08:00
rebase/merge 都不重要
重要的是如何让开发提交的每个 commit 都是单一且完整的,以及对一些大功能 commit 的粒度把控。
4BVL25L90W260T9U
2024-08-16 11:14:43 +08:00
不要让我看到 merge remote tracking branch master 这种智障操作就好……
msg7086
2024-08-16 12:07:25 +08:00
可以看出来上面有很多人都没搞清楚 rebase 到底是一个什么操作。
比如 @dfkjgklfdjg #13 就以为 rebase 必然会需要 force push 。
kera0a
2024-08-16 12:09:29 +08:00
merge 别人,rebase 自己
msg7086
2024-08-16 12:09:50 +08:00
@xiangliudev 在楼主给定的条件下,fast-forward merge 和 rebase 和 reset hard 其实是同一个操作。
lhp96
2024-08-16 12:16:00 +08:00
回滚的时候,排查问题的时候,哪个更好呢?
leonshaw
2024-08-16 12:31:28 +08:00
一般来说小的 feature, bugfix 分支合并前先 rebase ,大的分支 (dev->master) 不 rebase ,有冲突的时候很难保证 rebase 后每个 commit 都是好的。Merge commit message 写清楚改动和冲突解决情况,这点可以参考一下 linux 内核,Linus 还针对这个问题吐槽过 github. 即使 rebase 过,合并时也可以视情况 no-ff 来保留分支历史。
jim9606
2024-08-16 13:10:57 +08:00
私家分支用 rebase,公共分支用 merge,只要分支有被多个人使用,就不要用 rebase 。
如果你不拿远程仓库当同步盘用,私家分支是只会在你的本地仓库里的,也不需要用到 forcre push,这时用 rebase 没啥问题
jeesk
2024-08-16 13:19:02 +08:00
@lhp96 你问到点子上了。 如果是回滚,那么肯定是 merge 好。 比如你在今天 merge 了一个分支的操作,那么你可以直接通过时间线, 获取到这个功能的合入时间,那么 直接 revert 掉这个 coomit 就行了。 这个完全可以参考 chromium 项目 merge 和 revert 操作。
dfkjgklfdjg
2024-08-16 14:26:43 +08:00
@msg7086 #28 ,所以你其实也没有理解我为啥会举一个 push -f 的例子。很多人以为 rebase 就一定会修改远端的 commit history 。
其实在本地 dev 分支做好 rebase 解决完本地的 dev 分支和和 master 的分支 之后再把 dev 通过 PR 或者直接合并(再次 rebase/merge )回 master 的时候并不需要 push -f 。

其实只要给开源项目贡献过 PR 其实都知道在提交 PR 之后 rebase 分支是在干啥。
rrfeng
2024-08-16 14:29:53 +08:00
merge

rebase 只用在其他分支上,用于太落后 master 的时候(其他分支 merge 了导致大量冲突)。
cirzear
2024-08-16 14:34:59 +08:00
先在开发分支上 rebase, 再 merge 到主分支
sagaxu
2024-08-16 14:45:42 +08:00
我一般不用 rebase ,比较常用

git cherry-pick

git merge

git merge --squash

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

hotfix 和 feature 处理方式是不一样的
msg7086
2024-08-16 15:19:25 +08:00
@dfkjgklfdjg 不好意思一眼看岔了。
mywjyw
2024-08-16 15:50:29 +08:00
merge --no-ff ,某大厂强制要求

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/1065328

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX