rebase 还是 merge？

[wiirhan]

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

[dcalsky]

永远 rebase

[dcalsky]

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

[lingxi27]

rebase +1

[wiirhan]

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

[bjfane]

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


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

[zjsxwc]

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

[zjsxwc]

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

[konakona]

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

[peterswan]

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

[Pipecraft]

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

[monkeyWie]

同意 2L

[wellsc]

统一比选择难

[weiwenhao]

说一次去年的线上的故障。
开发了 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]

要 rebase 就全部 rebase，要 merge 就全部 merge

有人 rebase 有人 merge 才最伤

[weiwenhao]

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

[plko345]

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

[karott7]

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

[weiwenhao]

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

[weiwenhao]

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

[karott7]

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