git rebase 命令主要啥作用

[echooo0]

有 2 个分支，分别是 dev 和 master ，各有线下和线上的配置文件，

以前一般用的都是 check out 到 master 分支后，把 dev 改动的部分 merge 进来，

刚刚不小心在 dev 分支误点了 Rebase dev onto master , 会有啥问题吗？

[sampdoria]

https://www.atlassian.com/git/tutorials/rewriting-history/git-rebase#:~:text=What%20is%20git%20rebase%3F,of%20a%20feature%20branching%20workflow.

git 命令不熟悉的话把这个教程好好读一下就差不多了

[ysc3839]

一般是在分支 A 某个 commit fork 出了分支 B 进行开发，同时分支 A 又有新提交，用 rebase 可以把分支 B 的那些提交“叠”到分支 A 最新的提交上面

[f5a599]

让别人能 ff-only ，很安心

[gtexpanse]

我是用来保持分支线整洁，代码 review 或者追溯历史 commit 的时候清晰明了

[ysc3839]

还有一个很好用的功能是 interactive rebase ，可以很方便地修改某一个分支，或者执行 squash 操作

[optional]

可以保持主干清爽，单人单功能开发的时候非常清晰。
但是功能分支也是协作开发的时候，冲突会比较麻烦，反而不好追溯历史。

[wangxiaoaer]

有个项目基于开源项目定制，是从 master 切换到某个 tag ，然后拉出来一个 dev 分支做自己的开发。同时还要定期同步上游的最新更新，目前就是当上游有新 tag 发布时，切换到 master ，pull ，就拉下来，然后回到 dev 分支 rebase 最新 tag 。

[ampedee]

核心作用是重写提交历史，之前写过一篇讲解原理的博客： https://waynerv.com/posts/git-rebase-intro/

[javlib]

只有 2 个分支，恐怕不能用 rebase ，容易搞出问题。

举一个 rebase 实用的场景：如果每个 feature / bug 都是用一个分支，而且只有一个开发人员在这条分支开发，开发完成后，准备往 mater/dev 合并，如果之前做了多次 commits ，会显得很凌乱，这时候可以用 rebase ，把多个 commits 合并成 1 个。

[grit136907108]

我主要用来合并本地提交记录

[echooo0]

@ysc3839 #2 这样的话，A 就不会按照提交时间顺序排列，而是 "叠" 的顺序排列对吧

[ysc3839]

@echooo0 是的，不过 B 分支的 commit 最初的提交时间是会保留的，可能会出现 A 分支中 commit 晚提交在下面，B 分支中 commit 早提交在上面

[andyJado]

其实就是重复执行 cherrypick

[cnoder]

简单说 直接 merge 是菱形线，rebase 是一条线。一条线方便看写

[lessMonologue]

主要是其中无 merge 时，多次提交合并成一个提交，保持 commit 清晰

[f6x]

你的树好难看啊
你的提交把我的树弄丑了
你每次合并为什么总是这么慢
你这堆中间版本压缩一下
曾经有一个拼写错误被我 commit 了, 没 push 的话还有补救机会么?

[liquid207]

git rebase： 修改分支的起点

git rebase -i: 合并 commit, 修改 commit, 调整 commit 的顺序

[unco020511]

你可以理解为在你原来的 commit 改写并生成新的 commit,然后提交

[dqzcwxb]

变基😏

[libook]

rebase 可以把一个分支上的提交复制出来并挨个重新提交到另一个分支上，也就是说虽然修改内容一样，但提交的 commit id 会不同，新提交的时间也会变成 rebase 的时间。
merge 就是把一个分支上的提交原样合并到另一个分支上去，同时创建一个合并提交来记录这个合并操作。
我个人建议不要滥用 rebase 。版本控制系统的价值在于回溯代码修改版本，merge 能记录更多有用的信息，特别是在多人合作的时候，但 rebase 不行，你可以在自己的分支对自己的提交进行 rebase ，但是最好不要跨多人的工作使用 rebase 。

[crab]

https://www.bilibili.com/video/BV19e4y1q7JJ?t=393

[pengtdyd]

rebase 这个还不明显吗，--help 看一下不就行了吗，有这时间发帖，一个命令早就知道了。

[ClericPy]

拉 PR 时候其中一种方式, 还有俩是 merge 和啥来着

反正挨骂几次分支不小心整出圈儿来就记住要 rebase 了... 一根儿的分支树确实好看很多

git flow 还是 Github flow 是不是提到过相关规范

[icylogic]

rebase 是一个整理历史的工具，在*私人分支*里使用 rebase 去整理历史（不管是直接 rebase onto ，rebase -i ，还是 pull —rebase ）是非常合理而且甚至在多人合作中是应该被鼓励的。

因为这代表你最后能给别人贡献一个干净的、非常易于理解、以后也很方便追溯的 patch series/pr ，这代表了你想告诉别人（包括一个月后的你自己），我的每一个 commit 都是有意义、可以被 checkout 出来构建和测试、甚至是做 bisect 的阶段性工作成果，而不是草稿纸上的来回涂鸦，所谓的 graph 好看其实是最次要的

而且这没有听上去那么麻烦，大部分切分合理的快速小分支应该是直接 squash 成一个 commit 的，它就是这次全部的改动，删掉了你在某些地方反复调整的过程（几乎没有人包括你自己需要回顾这个过程），这也是一些团队会直接不管三七二十一把 pr 全都 squash merge 掉的情况（你去看主流的 git 服务器都会提供这个选项）；只有一些确实比较大的改动需要花点时间去认真整理一下。

但是 rebase 正常情况下只应该用于整理私人分支，而不能用于修改公开历史，公开历史包括别人的分支，以及你已经发布出去让别人 checkout 过的分支，这会严重影响协作。

https://www.mail-archive.com/[email protected]/msg39091.html
Linus on git rebase and merge (2009)

[zhengzhongzhao]

@f5a599 啥功能 咋就安心了

[charlie21]

@icylogic
"你最后能给别人贡献一个干净的、非常易于理解、以后也很方便追溯的 patch series/pr "
对于这一目的，两个办法做到：

在 pr 提交方的做法是 rebase 出一个 commit 历史（方便 pr 被并入方 执行 "Create a merge commit" 拿到被遴选出的几个 commit 历史）

在 pr 被并入方的做法是 Squash and merge （拿到一个 commit 历史，即: 故意将 pr 提交方的若干 commit 都压缩为一个 commit ）。这是 “兜底” 考虑的

// 以上两个选择一个就可以了，在 pr 被并入方的做法是更 “兜底” 的