Git rebase 和 merge 是不是没办法混着用？

merge

rebase

commit

git

34 条回复 • 2020-03-30 14:30:36 +08:00

1

tedzhou1221

2020-03-29 15:08:37 +08:00 via Android

我也是一直 rebase,团队有某几个人 commit 前都没有先 pull，所以他们每次都是 merge 。

所以一直都是混用，暂时没有遇到大的问题.就是那条线比较乱。

还有就是要求团队每个人按一定规范去提交代码比较困难。目前没有强制。

2

Haujilo

2020-03-29 15:14:39 +08:00

没理解，你们现在不就等于是混着用吗？

3

leafre

2020-03-29 15:21:59 +08:00

4

变基 vs. 合并
至此，你已在实战中学习了变基和合并的用法，你一定会想问，到底哪种方式更好。在回答这个问题之前，让我们退后一步，想讨论一下提交历史到底意味着什么。

有一种观点认为，仓库的提交历史即是记录实际发生过什么。它是针对历史的文档，本身就有价值，不能乱改。从这个角度看来，改变提交历史是一种亵渎，你使用谎言掩盖了实际发生过的事情。如果由合并产生的提交历史是一团糟怎么办？既然事实就是如此，那么这些痕迹就应该被保留下来，让后人能够查阅。

另一种观点则正好相反，他们认为提交历史是项目过程中发生的事。没人会出版一本书的第一版草稿，软件维护手册也是需要反复修订才能方便使用。持这一观点的人会使用 rebase 及 filter-branch 等工具来编写故事，怎么方便后来的读者就怎么写。

现在，让我们回到之前的问题上来，到底合并还是变基好？希望你能明白，这并没有一个简单的答案。Git 是一个非常强大的工具，它允许你对提交历史做许多事情，但每个团队、每个项目对此的需求并不相同。既然你已经分别学习了两者的用法，相信你能够根据实际情况作出明智的选择。

总的原则是，只对尚未推送或分享给别人的本地修改执行变基操作清理历史，从不对已推送至别处的提交执行变基操作，这样，你才能享受到两种方式带来的便利。

4

wellsc

2020-03-29 15:22:26 +08:00

最好只用一种

5

Haujilo

2020-03-29 15:27:42 +08:00

我曾经做过尝试，结论是除非你自己是代码管理员，有权利可以拒绝别人的提交，否则你就只能自己玩 rebase，别人 merge 你自己 rebase 是没关系的。rebase 比 merge 稍微难理解，很多码农不肯去学习，很难强推。如果你通过重写历史的方式把别人的 merge 弄掉，整条分支线会变更，其他人都需要删掉分支重新 pull，就看你们团队人员多不多了。

6

murmur

2020-03-29 15:28:52 +08:00

看你们的习惯，只要是科学管理都行，rebase 会扔掉一些修改痕迹，但是合出来一条笔直的线贼拉漂亮

7

Xbluer

2020-03-29 15:54:49 +08:00

我猜，如果你们服务器上禁止 push --force, 那么你和你的同事应该没有使用同一个服务器分支。

版本结点 A rebase 到版本 B 结点上，则会查找 A 、B 的共同祖先版本结点 C，然后将 C...A 所有操作都在版本结点 B 上重新操作一遍，不论 C...A 之间的操作是不是当前用户。

如果是使用同一个服务器分支开发，并禁止 push --force ,那 rebase 就只会包含你没有 push 到服务器上的 commit 。

8

hantsy

2020-03-29 15:57:12 +08:00

rebase 会重整 Commit 记录，项目提交记录看起来比较舒服，有时有一些无效的提交（比如少了什么问题，后来加一个 Commit 添加缺少的文件）可以合并。国外的很多开源项目，基本都是要 Rebase，比如一个 PR，经过多次 Code Review 修改，最终会合并到一个 Commit 上去。
Merge 能比较能真实的反应提交记录，比较简单，对于习惯不好的团队，整个团队的提交时间长了 Graph 看起来就是一团麻。

9

Shawlaw

2020-03-29 16:28:40 +08:00

rebase 和 merge 操作在团队协作时并没有冲突关系，仅仅是代码合入稳定的协作分支（例如 master 或者 develop ）的那一时刻需要做的一个选择——是要以 non-fast-forward 方式直接 merge （生成一个 merge 提交），还是 rebase 后 non-fast-forward 方式 merge （生成一个 merge 提交），还是 rebase 后 fast-forward 方式 merge （不生成一个 merge 提交，直接保留记录到新分支）。
至于提到的 rebase 后会带有之前已 merge 的提交的情形，大概率是之前已 merge 的提交里修改的内容在 merge 后又被改动了，这时候需要判定是否真的还会带有这个提交，通常来说，这些提交应该在 rebase 过程中被跳过。

10

swulling

2020-03-29 16:48:45 +08:00 via iPhone

可以混着用而且没啥问题

11

creanme

2020-03-29 16:55:08 +08:00 via Android

想请教一下，rebase 可不可能造成不可修复的错误？我之前听一个朋友大致说如果犯蠢，rebase 可能造成不可修复的问题，所以他在小组中禁止用 rebase 。

12

1423

2020-03-29 17:38:51 +08:00

在提交前，先在本地 master 分支 pull 更新代码，然后在特性分支 rebase master，解决冲突
然后在 master 分支 merge -squash commit 信息会生成特性分支的所有提交记录

13

jinliming2

2020-03-29 18:08:12 +08:00 via iPhone

我个人是不建议随时随地 rebase 的，3 楼解释的比较完整，历史记录是有用的，不是为了好看的。只有当必须 rebase 的时候（比如历史提交了敏感信息，需要退回去删掉），才 rebase 。
分支是需要被保护的，就限制了 push -f 这个万恶之源。

14

leo108

2020-03-29 18:10:45 +08:00

@creanme
1. master/develop/release 等公共分支禁止 force push ；
2. git reflog 了解一下，除非是未 commit 的代码，或者是年代太久远被 git 自动 gc，不然可以恢复到任意状态。

15

creanme

2020-03-29 18:27:27 +08:00

@leo108 好的,谢谢.

16

wangyzj

2020-03-29 19:56:41 +08:00

rebase 可能会出错
merge 不会出错
rebase 看着好看
rebase 适合单人多分支复杂任务开发

17

weixiangzhe

2020-03-29 20:07:23 +08:00

个人感觉，多个开发的话，走类 gitflow 那套的话，feature 分支可以 rebase,其它分支 rebase 不了

18

DelayNoMay

2020-03-29 20:08:03 +08:00

混着用，哪个用不了就用另外一个

19

DelayNoMay

2020-03-29 20:09:38 +08:00

@tedzhou1221 不是应该先 commit，然后 pull，再 push 吗

20

qbmiller

2020-03-29 20:16:47 +08:00 via iPhone

接住 gitlab squash 大多保证每个功能一条提交记录。
合并前，是自己 merge 其他还是 rebase 无所谓

21

youxiachai

2020-03-29 20:17:25 +08:00

自己用 rebase
多人用 merge 。。主要 merge 记录多。。出问题。。找起来直观。。。

22

dbskcnc

2020-03-29 22:31:15 +08:00

我是 merge,历史记录是有用的，可以看到曾经的工作细节，了解过程跟知道结果一样重要

23

laoheshanjigong

2020-03-29 23:54:02 +08:00

仓库上设置只可以 fastforward merge 就行了。

24

szdubinbin

2020-03-30 00:17:39 +08:00

@1423 我司也是这种模式，感觉这样结合着 rebase 和 merge 没啥问题。

25

PainAndLove

2020-03-30 00:36:12 +08:00

rebase 适合自己同时开发多个分支

26

scnace

2020-03-30 01:33:10 +08:00 via Android

@1423 yep，这是很常见的 GitHub flow 模式。

这样在 merge 到 master 的 MR/PR 需要回滚时可以直接 revert 。但是如果使用 rebase 的话要 reset 就比较麻烦了，除非是 squash 成了一个 commit 。我的 rebase 但是经常来整理 commit 就是了，在有时间空余的情况下，尽量让之前匆匆写的 commit message 可读可追溯。