这是一个创建于 473 天前的主题，其中的信息可能已经有所发展或是发生改变。
1. 如果使用 merge 会多出一条记录 ， Merge remote-tracking branch 'origin/dev' 的记录，比较难看.
2. 如果使用 rebase 的话， 就会成为一条线.
你们公司是怎么用的？
我自己一直很反感在 master 分支上去 rebase 时间线会乱掉看着很难受。
2. 如果使用 rebase 的话， 就会成为一条线.
你们公司是怎么用的？
我自己一直很反感在 master 分支上去 rebase 时间线会乱掉看着很难受。
第 1 条附言 2024-08-16 09:10:38 +08:00
在我参考一些大型的开源项目，得到了一些经验。
一般 master 都是 merge 开发分支，接收 pr ，可以明确知道某些功能的引入点，对于产品把控能力更强。这是对于代码管理者的角度来看的。至于 merge 的角度这条记录，通过改记录可以查看到一个功能是什么时候引入的。
对于开发者的角度， 自己的代码在开发分支，到底是 master merge 还是 rebase.根本不在乎， 反正只需要知道代码合进去了，这对于个人项目貌似没问题。
所以我们能够看到，类似于 apache ，chromium ，firefox 多数采用第一种。 而普通人没有大型项目或者说产品规划的实鉴，更加倾向于使用 rebase 。
一般 master 都是 merge 开发分支，接收 pr ，可以明确知道某些功能的引入点，对于产品把控能力更强。这是对于代码管理者的角度来看的。至于 merge 的角度这条记录，通过改记录可以查看到一个功能是什么时候引入的。
对于开发者的角度， 自己的代码在开发分支，到底是 master merge 还是 rebase.根本不在乎， 反正只需要知道代码合进去了，这对于个人项目貌似没问题。
所以我们能够看到，类似于 apache ，chromium ，firefox 多数采用第一种。 而普通人没有大型项目或者说产品规划的实鉴，更加倾向于使用 rebase 。
 | 1 gauzung 2024-08-15 21:15:02 +08:00  2 rebase |
 | 2 fgwmlhdkkkw 2024-08-15 21:17:21 +08:00 via Android 我认为就不应该有 rebase 这种操作，， |
 | 3 xiangliudev 2024-08-15 21:26:28 +08:00 fast-forward merge 不是也可以是一条线吗？ 然后其他分支 merge 进 master 之前 rebase master 即可。 |
 | 4 bruce0 2024-08-15 21:29:40 +08:00 我都是 dev 同步 master 的时候 rebase, dev 弄好了, merge 到 master |
 | 5 Goooooos 2024-08-15 21:30:43 +08:00 via Android merge --squash |
 | 6 agagega 2024-08-15 21:33:10 +08:00 1 如果你不是 leader ，纠结这个没有意义。如果你是 leader：假如合并代码这个人归你管，让他用 rebase/squash ；假如来自另一个团队不归你管，则用 merge merge 应该反映开发团队的人员架构，rebase 的时间线错乱并不是什么问题，实在不喜欢 amend 下就行。在找 bug 的时候，清爽的提交历史会方便很多。但其实最重要的是每个提交得有意义，一大堆杂乱无章的提交不管用 rebase 还是 merge 都难受 |
 | 7 94 2024-08-16 08:10:38 +08:00 dev 分支 rebase 到 master 最新的 commit 之后你用 merge 还是 rebase 都是一样的。 |
 | 8 jeesk OP @dfkjgklfdjg 其实是不一样的， 参考 github 的开源项目即可 。 很多开源项目能够通过 merge 明确知道一个什么时候引入分支得，但是 rebase 却不行。 对于产品功能把控很难搞。 |
 | 9 daozun 2024-08-16 09:02:25 +08:00 如果你自己一人使用的分支，master 上有最新提交，rebase master 到自己分支上，如果你和别人共用一个分支，使用 merge 合并别人的提交，这样好追溯。 |
 | 10 superchijinpeng 2024-08-16 09:21:48 +08:00 merge fast forward |
 | 11 Navee 2024-08-16 09:27:57 +08:00 merge ，降低心智负担 |
| 12 94 2024-08-16 09:33:19 +08:00 @jeesk #8 ，所以得看开发流程中提交合并是否有 PR/MR ，和 CR 的流程。 如果没有，那么 rebase 之后合并和 merge fast forward 合并是一样的。 并且很多人在 merge 里面解决冲突时可能会手动改动代码，而不是单纯选择当前代码 or 传入的代码，这样就会造成其他的问题。 其实完整的流程应该在本地分支 rebase 到 master 最新提交之后，再提交 PR/MR 。在分支解决完所有问题之后再合 PR 到主线。 但！实际开发过并不会有那么完善的流程，很多同事也不会遵守你设置的提交 PR 检查通过之后才能合并的规则，就会造成我上面说的隐患问题。 |
| 13 94 2024-08-16 09:36:42 +08:00 @dfkjgklfdjg #12 ，master 上面是不允许 rebase 的，rebase 的操作是开发人员对于自己的 dev 分支去基变，保证自己代码合并回主线时不会出现冲突（已经在自己的 dev 分支解决完了冲突代码，这样后续业务出现问题了也方便溯源）。 并不会出现在 master 上面 rebase 然后 push -f 这样的操作。 |
 | 14 dumbass 2024-08-16 09:43:26 +08:00 一个人维护项目，我用 热巴色 |
 | 15 IvanLi127 2024-08-16 09:50:15 +08:00 dev 分支如果是公用的，那就 rebase ；如果每个人或者每个功能点自用的，那就 merge 。 公用 dev 分支我觉得是没啥用。 |
| 16 jeesk OP @bojackhorseman 是啥呀，我没搜索到 |
 | 18 Katrol 2024-08-16 10:00:11 +08:00 无法保证团队分支管理水平的话，还是 merge 吧 |
 | 19 tyrone2333 2024-08-16 10:03:06 +08:00 rebase 等你出了一个线上事故就老实了,自己单人项目玩玩是可以用 |
 | 20 Rache1 2024-08-16 10:10:55 +08:00 我就奇了怪了，总有人说 merge into ... 不好看，你们是没事儿就盯着这东西看吗。再说了，这也只是众多提交记录中的一条而已，你要是觉得这个默认的不行， 你还可以自己编辑这个 commit 信息 |
 | 21 happyxhw101 2024-08-16 10:12:36 +08:00 压缩提交 |
 | 22 iceprosurface 2024-08-16 10:13:40 +08:00 一般 rebase merge ，merge 只是为了到时候可以快速 revert 而已 |
 | 23 zhenjiachen 2024-08-16 10:14:17 +08:00 直接用 git lab 自带的 rebase , 其它分支要合并必须先 merge main 分支最新代码。因为我们是用 merge request 来审核代码，审核会有多次提交，rebase 可以把这个分支所有的提交都合并为一个提交。这也可以优化 main 分支的提交数量，也能同时知道这个 request 改了哪些东西。 |
 | 24 EastLord 2024-08-16 10:18:04 +08:00 master rebase 到 dev, 然后提 pr ，可能会用到压缩提交 |
 | 25 iintothewind 2024-08-16 10:19:24 +08:00 用 merge, 别管区别, 总之一句话, 与其委屈自己, 不如为难别人. |
 | 26 wu00 2024-08-16 10:21:42 +08:00 rebase/merge 都不重要 重要的是如何让开发提交的每个 commit 都是单一且完整的，以及对一些大功能 commit 的粒度把控。 |
 | 27 4BVL25L90W260T9U 2024-08-16 11:14:43 +08:00 不要让我看到 merge remote tracking branch master 这种智障操作就好…… |
 | 28 msg7086 2024-08-16 12:07:25 +08:00 2 可以看出来上面有很多人都没搞清楚 rebase 到底是一个什么操作。 比如 @dfkjgklfdjg #13 就以为 rebase 必然会需要 force push 。 |
 | 29 kera0a 2024-08-16 12:09:29 +08:00 via iPhone merge 别人，rebase 自己 |
| 30 msg7086 2024-08-16 12:09:50 +08:00 @xiangliudev 在楼主给定的条件下，fast-forward merge 和 rebase 和 reset hard 其实是同一个操作。 |
 | 31 lhp96 2024-08-16 12:16:00 +08:00 回滚的时候，排查问题的时候，哪个更好呢？ |
 | 32 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 来保留分支历史。 |
 | 33 jim9606 2024-08-16 13:10:57 +08:00 via Android 私家分支用 rebase,公共分支用 merge,只要分支有被多个人使用，就不要用 rebase 。 如果你不拿远程仓库当同步盘用，私家分支是只会在你的本地仓库里的，也不需要用到 forcre push,这时用 rebase 没啥问题 |
| 34 jeesk OP @lhp96 你问到点子上了。 如果是回滚，那么肯定是 merge 好。 比如你在今天 merge 了一个分支的操作，那么你可以直接通过时间线， 获取到这个功能的合入时间，那么 直接 revert 掉这个 coomit 就行了。 这个完全可以参考 chromium 项目 merge 和 revert 操作。 |
| 35 94 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 分支是在干啥。 |
 | 36 rrfeng 2024-08-16 14:29:53 +08:00 merge rebase 只用在其他分支上，用于太落后 master 的时候（其他分支 merge 了导致大量冲突）。 |
 | 37 cirzear 2024-08-16 14:34:59 +08:00 先在开发分支上 rebase, 再 merge 到主分支 |
 | 38 sagaxu 2024-08-16 14:45:42 +08:00 1 我一般不用 rebase ，比较常用 git cherry-pick git merge git merge --squash git reset --soft master && git commit -am 'xxx' hotfix 和 feature 处理方式是不一样的 |
| 39 msg7086 2024-08-16 15:19:25 +08:00 @dfkjgklfdjg 不好意思一眼看岔了。 |
 | 40 mywjyw 2024-08-16 15:50:29 +08:00 1 merge --no-ff ，某大厂强制要求 |
 | 41 srlp 2024-08-16 17:51:59 +08:00 via iPhone 在 dev 上 rebase master ，然后从 master merge dev 进来。 |
 | 42 Pinealxx408 2024-08-16 17:53:21 +08:00 git pull --rebase 就不会有 merge 了 |
 | 43 Cola98 2024-08-16 19:25:46 +08:00 merge |
 | 44 luckrnx09 2024-08-16 21:44:06 +08:00 via iPhone Rebase+Squash ，每个 PR 合并后只有一条 commit ，很清爽。 |
 | 45 Jet 2024-08-18 07:44:09 +08:00 不管用哪个, 有人习惯把 git commit/push 当 save code 用就难崩。 |
Select Language