git rebase 命令主要啥作用

[echooo0]

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

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

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

[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/[e-mail]/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 被并入方的做法是更 “兜底” 的

[sparky]

在这里玩玩就明白了 https://learngitbranching.js.org/?locale=zh_CN&NODEMO=