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