狐七的个人博客

# 五、使用git rebase合并分支

我们现在分支合并想到最多的就是git merge，还有一个合并代码的命令git rebase，而这个命令在工作中优先被推荐使用，下面先通过两个例子体会一下两个命令合并代码的差别：

# 实践是检验真理的唯一标准

# git merge 合并分支

# 创建分支和提交记录

  1. 从master分支创建一个merge1分支，进行第一次提交
git checkout master
git checkout -b merge1
git add .
git commit -m 'merge1'
1
2
3
4
  1. 从master分支创建一个merge2分支，修改代码，进行第一次提交
git checkout master
git checkout -b merge2
git add .
git commit -m 'merge2'
1
2
3
4
  1. 切换到merge1分支，修改代码，进行第二次提交
git checkout merge1
git add .
git commit -m 'merge1-2'
1
2
3
  1. 切换到merge2分支，修改代码，进行第二次提交
git checkout merge2
git add .
git commit -m 'merge2-2'
1
2
3

# 进行合并

5.将merge2分支merge到merge1分支中，解决冲突之后会有一个新的 merge 的 commit 分支。

git checkout merge1
git merge merge2
1
2

  1. 如果想取消合并，直接使用git merge --abort
git merge --abort
1

# 解决冲突

  1. 解决冲突之后(这里选择保留双方更改)，这里选择直接提交代码
git add .
git commit -m 'merge1 merge merge2'
1
2

# 回滚代码

  1. 如果想要回到merge1-2，执行操作git reset

# 补充操作

  1. 在第7步的时候，如果直接使用git merge --continue会进入面板，可以修改提交分支的信息
git merge --continue
1

这个时候i插入，修改merge1 merge merge2 continue之后按ESC键，然后按:wq保存，可以看出，这边还是会新保留一个commit

  1. 9步之后想要回到merge1-2，操作git reset
git reset <commitID>
1

# 再来看看使用 git rebase 合并分支

# 创建分支和提交记录

  1. 从master分支创建一个merge1分支，进行第一次提交
git checkout master
git checkout -b merge1
git add .
git commit -m 'merge1'
1
2
3
4
  1. 从master分支创建一个merge2分支，修改代码，进行第一次提交
git checkout master
git checkout -b merge2
git add .
git commit -m 'merge2'
1
2
3
4
  1. 切换到merge1分支，修改代码，进行第二次提交
git checkout merge1
git add .
git commit -m 'merge1-2'
1
2
3
  1. 切换到merge2分支，修改代码，进行第二次提交
git checkout merge2
git add .
git commit -m 'merge2-2'
1
2
3

# 进行合并

  1. 切换到merge1分支，进行rebase操作git rebse merge2
git checkout merge1
git rebase merge2
1
2

首先这里可以看到要和两个提交进行rebase，

  1. 此时想要退出合并，写git rebase --abort
git rebase --abort
1

# 处理冲突

  1. 我们要手动修改第一个提交，因为这个提交不是最后一个提交，所以内容可以不保留，选择采用当前更改

  1. 然后提交修改，这里先使用git add .，然后使用git rebase --continue时说没有修改，是否强制使用git rebase --skip跳过
git add .
git rebase --skip
1
2

  1. 这个成功之后进入下一个提交，这里可以看到，这里与merge的当前更改和传入更改的位置是有改变的，传入的更改反而是merge1，这个时候选择保留双方更改。

  1. 然后提交修改
git add .
git rebase --continue
1
2

  1. 此时查看git log，发现合并后的log展示
  • 并没有再生成新的提交记录
  • 这里的log顺序和merge不同
  • 因为刚才我们使用skip跳过了一个commit，所以这里并没有merge1。

# 版本回滚

  1. 此时要回滚到merge1-2的时候，即没有rebase之前，是无法回退的，因为我们的版本树里面，已经找不到合并之前的两次提交了，这个时候需要使用git reflog操作日志进行回滚，这里使用第几步可以回滚的更好。

# git rebase 还有什么优化的空间吗?

一般使用git rebase的时候，都会将当前的版本进行commit合并。

# 为什么要对版本进行合并?

刚才实验的时候，其实我们已经看到了，git rebase的流程是，将merge2的代码拉到merge1中，然后和merge1中提交的代码一次一次进行diff，但是一般情况下，我们一般会将merge1中最后一次提交的代码视为最终代码，并不需要再和之前的代码进行diff，这个时候就需要先将之前的版本合并，然后再与merge2进行diff，此时只需要diff一次即可。

# 如何对代码进行合并呢?

请看这篇博客：方法二：合并需要的commit (opens new window)

# git merge VS. git rebase 总结

# 相同的地方

对git版本进行管理，功能是合并代码，都需要手动解决冲突。

# 不同的地方

比较 git merge git rebase
原理 git merge是两个分支最新commit进行diff比较，解决冲突之后生成一个新的commit记录 git rebase是将目标分支拉取，并与当前分支的每一个提交逐一进行diff，将当前分支合并到目标分支代码的后面，解决冲突之后更新commitID，当前分支原来的commitID不保留在log记录中
查看log commit记录按照版本提交时间进行排列，并不是版本的真实顺序。
 按照合并顺序进行排列，实际版本的真实顺序
原理图 这个是分支存在的真实结构图
 这个图描述了，merge1的rebase操作，是将merge2代码拉过来之后将自己合并到其后面

# 为什么要推荐使用 git rebase 呢?

  1. 避免在总分支上手动处理冲突的危险操作 我们实际开发的时候，都会有一个总的dev分支，和一个自己的分支work，正确的操作是我们应该先将dev的分支拉过来，然后将我们的代码合并上去，首先在我们自己的work代码中，有一个处理完冲突的最新代码，其次再去dev分支merge我们的work分支，这样，就不会出现在dev分支上手动处理冲突的危险操作。
# 在work分支
git rebase dev
# 处理完分支，切换到dev分支
git checkout dev
# 合并work分支的代码
git merge work
1
2
3
4
5
6
  1. 得到一个干净整洁的版本树 通过上面的原理图我们可以看到，在分支存储的时候，两个分支的内容还是实际还是分开的，而rebase之后的版本树，是一条真实干净的版本树。这个对以后正式版本的维护是很可的一件事，也是推荐大家用的。

# 这里还有几点重要的说明

  1. 千万不要用dev分支去rebase我们自己的分支。

  2. rebase dev的时候，尽量先将自己所有的commit合并成1个，然后再进行rebase操作。

  3. 对于dev分支来说，使用rebase更好一些。如果进行回滚操作了，那么当前分支修改之后还需要再次与dev 进行一次merge操作。如果是rebase，直接可以在最新的代码中进行修改。

  4. 重重重要的说明! 重重重要的说明! 重重重要的说明!有些人会说rebase的操作复杂，而且回滚操作很不方便，我们都知道合并是一件很慎重的事情，所以我们在进行合并操作的时候，也要进行慎重思考。之前也有遇到过，有同时滥用merge将别人代码冲掉的情况，所以对于开发来说，上线的东西质量保证是很重要的。

更新时间: 2021-02-25 00:05

← 六、摘樱桃模式——git cherry-pick →