rebase 还是 merge？

[wiirhan]

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

[karott7]

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

[xlsepiphone]

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

[daolanfler]

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

[icylogic]

https://www.mail-archive.com/[e-mail]/msg39091.html

[bingyiyu]

reabse+1

[Kobayashi]

Merge 多出来的提交不是无意义，它记录了一种合并关系，显式表明这个提交来自于一个分支。这也是 Git 分支的一大特性：Git 历史非一条直线，其中可以有岔路，或者说一个提交可以有多个父节点。Rebase 后再 fast forward 合并的话丢失了这种关系记录。

一个好的分支名直接解释了这个分支在做什么，如修复某个 bug 、新增了某个功能。而分支内每个提交则记录了实现的步骤。从这个角度来看，分支也可以视作一个大的提交。

Merge 而不是 rebase + fast forward 。更不要随意 merge --squash，而是根据情况使用。保留多个提交的实现步骤，如果这个功能出了问题，方便以后细分，定位问题。

楼上很多人对 Git 的理解水平真的不大行，只是在把 Git 当 SVN 来用……
建议了解了解 git-flow，理解一下分支。多翻翻 pro git book.

https://nvie.com/posts/a-successful-git-branching-model/
https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
https://git-scm.com/book/zh/v2

[yalin]

merge

[vjnjc]

#10 +1 “一律采用 squash merge 。 ”
大型项目也要考虑 merge，为了追溯真实提交情况。

假设一个场景，你想找 6 个月前有人做的 feature1 涉及到哪些文件改动。
1. rebase，你需要翻很多 commit 。比如 03/14 ～ 03/18 之间 user1 的所有 commit
2. merge 的话你只要看一个 commit 。或者是 gitlab/github 上的 mr

[bingyiyu]

我会先把本地分支 rebase 到远程 master 分支，然后再发起 merge request 合并到 master 分支。

[acidsweet]

merge;
1. 超大项目合码时 rebase 处理冲突的难度你不想体验
2. rebase 本身破坏了真实 commit 之间的逻辑顺序，粗暴的采用时间序其实非常蛋疼不直观

[2i2Re2PLMaDnghL]

历史可以分叉是很恶的（双关：恶心且邪恶），但是因为爱因斯坦的关系不得不这么干。
凡 git 的事想一想用邮件怎么玩。

1. 什么时候 rebase ？
你以别人的软件的 v1.0 为基础开始写一个 feature，还没写完的时候 v1.1 发布了，你把新代码 pull 下来并把你的修改全都 rebase 到 v1.1 上去。

2. 什么时候 merge ？
别人为你的软件写了一个 feature，然后 send-email 给了你。你拿到了他的 patch 并 merge 进你的代码。

[chaleaoch]

rebase 只在本地操作.

要不然很容易出问题.

[OliveGlaze]

2 楼的原则，加上 29 楼的具体实践说明，其实就是现在业界的标准玩法了。

工作那么多年的老油条了，各种 git flow 用下来，你最后总会发现必须得有 MR/PR 这个环节。这一类的 flow 才是更适合实际工作的 flow，而且所谓的 rebase 和 merge 也没法完全割裂开来单独用的。

[kxuanobj]

@wiirhan master 比较稳定，更改较少的情况下，可以试试 cherry-pick 到 dev 分支。

[index90]

特性分支 rebase 主干分支，然后再 merge 主干

[2i2Re2PLMaDnghL]

@2i2Re2PLMaDnghL 话说起来顾名思义都行
变基，是指『变更』提交的『基础』
合并，是指将两个分支的提交进行『合并』（我知道，循环定义了）
也就是说，当且仅当这些提交是那些提交的『基础』时才进行变基。

@vjnjc 你可以 diff <merge 的主支>...<merge 的分支>
据说 fossil 合并后分支会变成 tag 永久保留，你也可以轻易地看到这个 branch 的历史。
squash 似乎不太适合在时域上进行 bisect，这对于大型项目还是挺重要的。

[maplerecall]

微软这边的 git 项目合并 master 基本都 squash merge，保证 master 的记录是单线性的。至于合并前自己的分支爱怎么搞就怎么搞，PR 跑 build 和 test 能通过，不 conflict 就好了。

不过我基本都只用 rebase，只有极少数情况出现多人同时开发具有互相依赖性的东西才会 merge 。很多 mono repo 每天 master 要进几十上百个不同 team 做的东西，用 merge 会很糟心。

[MrGoooo]

rebase 没有按时间排序,merge 按时间顺序

[oneisall8955]

@weiwenhao #13 有两点疑问
1. 22 号的 bug，不能从 master 创建新分支修复吗？
2. 22 号的 bug 是 15 号提交的，那在 15 号的分支上修复也可以吧？先 pull master 到 15 号分支，处理冲突，修复完 bug 再 merge 到 master

[Felldeadbird]

我是个人和团队也用 merge 。分支线是会显得乱，但是不会出问题。