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

[lidjxy]

团队里其它人用的 merge，我用的 rebase，发现好像 rebase 会带上其它人产生的 merge commit 之前自己合进去的 commit，有什么办法能混着用吗？还是只能一起用 merge

[tedzhou1221]

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

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

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

[Haujilo]

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

[leafre]

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

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

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

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

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

[wellsc]

最好只用一种

[Haujilo]

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

[murmur]

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

[Xbluer]

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

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

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

[hantsy]

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

[Shawlaw]

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 过程中被跳过。

[swulling]

可以混着用而且没啥问题

[creanme]

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

[1423]

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

[jinliming2]

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

[leo108]

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

[creanme]

@leo108 好的,谢谢.

[wangyzj]

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

[weixiangzhe]

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

[DelayNoMay]

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

[DelayNoMay]

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

[qbmiller]

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

[youxiachai]

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

[dbskcnc]

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

[laoheshanjigong]

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

[szdubinbin]

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

[PainAndLove]

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

[scnace]

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

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

[ericgui]

我是反对 rebase 的,
因为它改变历史

[tedzhou1221]

我看上面很多说多分支的情况下操作 rebase 、merge 。我觉得都无所谓了

问题是我们团队的人喜欢在同一个分支下操作 merge,反正就是看的很不舒服

[Justin13]

别混用，个人项目无所谓，多人协作的最好选定一种，混用容易丢失记录和修改

[xiaoxinxiaobai]

难道是为了好看？？？

[frostming]

master 以及多人协作的分支，不是最好，不是推荐，是必须禁止 rebase


自己一个人工作的分支可以用 rebase

[Kerwin1202]

我一般喜欢 merge 因为 每次大的改动 merge 可以看到对方或者自己改的什么东西. 不管之前怎么改 反正就关注最后就可以了.

[kuro1]

反对 rebase +1

[cco]

常用 merge~ 还好吧，也没那么麻烦