git rebase 命令

前言

来啦老铁！

时间过得真快啊，2个多礼拜的时间又过去了，又到了不见不散的学习时间~
技术来源于工作（总感觉有点怪怪的），今天我们再来学个非常有魅力的，也是最近经常用到的 git 命令：

• git rebase

笔者在之前也记录了另外 2 个非常重要的 git 命令，有兴趣的朋友可前往阅读：

• git merge 与 git cherry-pick 命令

1. 背景；

假设我们现有 2 个分支：develop 分支和 feature/test_1 分支，feature/test_1 是程序员 A 从 develop 分支创建出来的。

程序员 B 在某天由于某些原因，如程序员 A 在 feature/test_1 分支写了一个非常牛逼的代码，于是程序员 B 从 feature/test_1 创建出了 feature/test_2 分支，然后继续开发。

过了几天，程序员 B 觉得自己的工作也做得差不多了，想将 feature/test_2 合并到 feature/test_1 然后一起合并到 develop，然而程序员 A 早已将 feature/test_1 合并到了 develop。于是程序员 B 发起了 pull request：

从 feature/test_2 合并到 develop！

于是程序员 B 发现在发起的 pull request 中程序员 A 的 commit 赫然在列，自己可能只提交了 2~3 次，但 commit 列表中却有高达几十次的程序员 A 的 commit，pull request 很不清爽，并且极有可能存在代码冲突。

怎么办？

换成是笔者，笔者有可能执行几种做法：

• 从 develop 重新创建一条分支 feature/test_3，然后将代码重新提交（也可使用git cherry-pick）到 feature/test_3，最后再次发起 pull request，注意，这里多了一个新的 pull request；
• 将 develop merge 到 feature/test_2，解决冲突；

然而，还有一个命令更适合做这个工作，那就是 git rebase。

2. 实操；

1. git remote update

2. git rebase origin/develop

3. 有冲突时，解决冲突，这块 vs code 挺好用的，它会在冲突处提供几个选项，accept yours、accept incoming changes、accept both之类的，一般是accept incoming changes，直到所有冲突解决完毕；

4. git add .

5. git rebase --continue

6. 有冲突时重复步骤 3 ~ 步骤 5

7. 完成时是类似样子的：

git rebase 解决冲突

我们会看到有一个信息：Successfully rebased and updated ...

8. 最后 git push 或 git push -f 即可；

操作完成后，我们会看到，其他人的 commit 都没了，只有自己的 commit 和解决冲突的 commit，也比 git merge 更清爽；

3. 多走一步；

上面介绍的场景，只是笔者日常工作用到的，对于 git rebase 命令，我们还可以多找一些资料，学习学习，例如这位网友的文章挺简单、清晰的：https://www.jianshu.com/p/4a8f4af4e803

• 合并多个commit为一个完整commit；

假设我们在本地仓库做了3次 commit 提交，分别为 B(假设 commit id 为 va48aneurh)、C（假设 commit id 为 7fw78ehdfnwe）、D（假设 commit id 为 9h78afa7fkfa），但还没执行 git push，那么我们可以通过以下几种方式，将 B、C、D 提交合并为 1 个提交，如 B'，这样我们既可以随时将本地的改动缓存起来，也可以将提交更简洁明了：

合并多个 commit

• git rebase -i va48aneurh
• git rebase -i va48aneurh 9h78afa7fkfa
• git rebase -i HEAD~3

基本格式为：git rebase -i [startpoint] [endpoint]，endpoint 不写时代表 startpoint 之后的所有 commit 都合并为 1 个提交，与其他 2 个命令意思一样；

• 将某一段commit粘贴到另一个分支上：

。。。
还是看网友的文章吧，不抄了~

如果本文对您有帮助，麻烦动动手指点点赞？

谢谢！