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 。