2
rebase 还是 merge?
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.
大家在项目里合并代码是用 rebase 还是 merge ? 两个远程分支合并,用 merge 会产生一个无意义的提交,次数多了分支线就很乱。
25 条回复 • 2021-09-18 14:01:30 +08:00
wiirhan 2 小时 47 分钟前
@dcalsky 远程分支咋办?假如我有两个远程分支:master 、dev 。master 作为主分支,dev 作为开发分支。在项目迭代中,master 分支可能会存在 bug 修复,这个 bug 修复完成后需要同步到 dev 分支。一个迭代结束后,dev 的代码需要合并到 master 分支。我现在对个人分支合并到远程分支采用的 rebase,两个远程分支的合并采用的是 merge 。现在纠结的是两个远程分支的合并,每次合并都会产生不必要的提交,如果 bug 修复次数很多,那分支就会显得很乱😂😂😂。
bjfane 2 小时 46 分钟前
教程都是用 merge 的多,一般都写不能真实的反映“历史”,小项目随意。大项目的话 2 楼基本上是正解。
“历史是什么” :
<img src = 'https://i.bmp.ovh/imgs/2021/09/13b50db1bb1ef78f.png' />
“历史是什么” :
<img src = 'https://i.bmp.ovh/imgs/2021/09/13b50db1bb1ef78f.png' />
konakona 2 小时 24 分钟前
merge,因为 no-ff 后只带一条记录。
因为团队开发需要用一些 git 的 flow (任意),为了追述 MR 是 hotfix 还是 feature 、release 等,用 merge no-ff 。
因为团队开发需要用一些 git 的 flow (任意),为了追述 MR 是 hotfix 还是 feature 、release 等,用 merge no-ff 。
Pipecraft 2 小时 17 分钟前 1
一律采用 squash merge 。github PR 也只用 /允许 squash merge 。
太多的小的提交,或反复的修改后提交,会使历史记录很乱。合并成一个 squash merge,既简洁又能看到一个 feature merge commit 里的多次提交的记录。
尽可能在 Github 上面先创建 PR,再合并。
太多的小的提交,或反复的修改后提交,会使历史记录很乱。合并成一个 squash merge,既简洁又能看到一个 feature merge commit 里的多次提交的记录。
尽可能在 Github 上面先创建 PR,再合并。
monkeyWie 2 小时 13 分钟前
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 都没了)。
开发了 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 都没了)。
weiwenhao 1 小时 42 分钟前
老大一开始就跟我说过要用 rebse 或者 git reset --soft,但是我没在乎,毕竟我看 廖雪峰阮一峰的教程都没说 rebase.. 出了故障才学会我可真是亏了。
karott7 1 小时 32 分钟前 via iPhone
@weiwenhao 你这种情况可以因检出一个分支,然后把主分支回退,再把 17 好发布的那些更改用 cherry-pick 命令放到主分支上,发布主分支
weiwenhao 1 小时 30 分钟前
@karott7 我们当时发布工具比较垃圾,就是选择 master 上的 一个一个 commit 然后打包发布。 然后也没有打 tag 的习惯,如果有 tag 应该也是可以解决的,不确定。
karott7 1 小时 23 分钟前 via iPhone
@weiwenhao #18 无解是因为乱用 merge 命令,应该所有的更改都从主分支检出新分支,每一个 commit 尽可能小,合并的时候照二楼说的先 rebase,再到主分支 merge(为什么要这样做?你可以在你的项目主分支和开源项目分别执行下 git log —oneline —graph 命令看看区别),最后发布完成给最新 commit 打版本 tag,更甚至建一个 changelog.md 文件记录每次版本号和更改内容
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK