2

rebase 还是 merge?

 2 years ago
source link: https://www.v2ex.com/t/802718
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

V2EX  ›  程序员

rebase 还是 merge?

  wiirhan · 3 小时 5 分钟前 · 1513 次点击

大家在项目里合并代码是用 rebase 还是 merge ? 两个远程分支合并,用 merge 会产生一个无意义的提交,次数多了分支线就很乱。

25 条回复    2021-09-18 14:01:30 +08:00

dcalsky

dcalsky   3 小时 5 分钟前

永远 rebase

dcalsky

dcalsky   3 小时 3 分钟前   ❤️ 5

@dcalsky sub-branches rebase on master, master merges sub-branches. 差不多是这样。

lingxi27

lingxi27   2 小时 57 分钟前

rebase +1

wiirhan

wiirhan   2 小时 47 分钟前

@dcalsky 远程分支咋办?假如我有两个远程分支:master 、dev 。master 作为主分支,dev 作为开发分支。在项目迭代中,master 分支可能会存在 bug 修复,这个 bug 修复完成后需要同步到 dev 分支。一个迭代结束后,dev 的代码需要合并到 master 分支。我现在对个人分支合并到远程分支采用的 rebase,两个远程分支的合并采用的是 merge 。现在纠结的是两个远程分支的合并,每次合并都会产生不必要的提交,如果 bug 修复次数很多,那分支就会显得很乱😂😂😂。

bjfane

bjfane   2 小时 46 分钟前

教程都是用 merge 的多,一般都写不能真实的反映“历史”,小项目随意。大项目的话 2 楼基本上是正解。


“历史是什么” :
<img src = 'https://i.bmp.ovh/imgs/2021/09/13b50db1bb1ef78f.png' />

zjsxwc

zjsxwc   2 小时 40 分钟前

merge 稳一点,虽然会多一次提交记录

zjsxwc

zjsxwc   2 小时 39 分钟前

同意 4 楼说的,自己有把握的两个分支用 rebase,对不熟悉的分支 merge

konakona

konakona   2 小时 24 分钟前

merge,因为 no-ff 后只带一条记录。
因为团队开发需要用一些 git 的 flow (任意),为了追述 MR 是 hotfix 还是 feature 、release 等,用 merge no-ff 。

peterswan

peterswan   2 小时 20 分钟前

个人开发和本地分支喜欢 rebase,涉及到远程多人开发的分支只能用 merge,rebase 会弄的协同困难。

Pipecraft

Pipecraft   2 小时 17 分钟前   ❤️ 1

一律采用 squash merge 。github PR 也只用 /允许 squash merge 。
太多的小的提交,或反复的修改后提交,会使历史记录很乱。合并成一个 squash merge,既简洁又能看到一个 feature merge commit 里的多次提交的记录。
尽可能在 Github 上面先创建 PR,再合并。

monkeyWie

monkeyWie   2 小时 13 分钟前

wellsc

wellsc   1 小时 50 分钟前

统一比选择难

weiwenhao

weiwenhao   1 小时 47 分钟前

说一次去年的线上的故障。
开发了 a 功能在 9 月 15 号(cimmit 在 9 月 15 号,测试了一周,9 月 22 号上线(合到 master)

修复了 b bug 在 9 月 17 号,当天上线。(合到 master)

9 月 22 号发版遇到 bug 需要回退。因此新的故障是 15 号提交的,所以此时需要回退到 15 号之前的 master 分支才能修复, 所以导致 17 号的修复分支没了( 15 号到 22 号其实不止 17 号一个功能没了,7,8 个 feature/或者 fix 都没了)。

dilu

dilu   1 小时 44 分钟前

要 rebase 就全部 rebase,要 merge 就全部 merge

有人 rebase 有人 merge 才最伤

weiwenhao

weiwenhao   1 小时 42 分钟前

老大一开始就跟我说过要用 rebse 或者 git reset --soft,但是我没在乎,毕竟我看 廖雪峰阮一峰的教程都没说 rebase.. 出了故障才学会我可真是亏了。

plko345

plko345   1 小时 37 分钟前 via Android

@weiwenhao rebase 能解决这个问题吗?只 reset 15 号的可行吗?

karott7

karott7   1 小时 32 分钟前 via iPhone

@weiwenhao 你这种情况可以因检出一个分支,然后把主分支回退,再把 17 好发布的那些更改用 cherry-pick 命令放到主分支上,发布主分支

weiwenhao

weiwenhao   1 小时 31 分钟前

如果 master 已经这样了就无解了,最后解决方法就是一直故障,然后立刻定位问题解决,足足持续了 2 个小时才解决。。。

weiwenhao

weiwenhao   1 小时 30 分钟前

@karott7 我们当时发布工具比较垃圾,就是选择 master 上的 一个一个 commit 然后打包发布。 然后也没有打 tag 的习惯,如果有 tag 应该也是可以解决的,不确定。

karott7

karott7   1 小时 23 分钟前 via iPhone

@weiwenhao #18 无解是因为乱用 merge 命令,应该所有的更改都从主分支检出新分支,每一个 commit 尽可能小,合并的时候照二楼说的先 rebase,再到主分支 merge(为什么要这样做?你可以在你的项目主分支和开源项目分别执行下 git log —oneline —graph 命令看看区别),最后发布完成给最新 commit 打版本 tag,更甚至建一个 changelog.md 文件记录每次版本号和更改内容

karott7

karott7   1 小时 22 分钟前 via iPhone

楼里不知道 git flow 流程的赶紧去学习一下

xlsepiphone

xlsepiphone   1 小时 21 分钟前

rebase,上一次 merge 应该是 2016 年了。

daolanfler

daolanfler   32 分钟前

rebase +1,rebase 的提交记录更好理解

bingyiyu

bingyiyu   5 分钟前

reabse+1

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK