目录

• 实践是检验真理的唯一标准
  • git merge 合并代码
    • 创建分支和提交记录
    • 进行合并
    • 解决冲突
    • 回滚代码
    • 补充操作
  • 再来看看使用 git rebase 合并分支
    • 创建分支和提交记录
    • 进行合并
    • 处理冲突
    • 版本回滚
  • git rebase 还有什么优化的空间吗?
    • 为什么要对版本进行合并?
    • 如何对代码进行合并呢?
• git merge VS. git rebase 总结
  • 相同的地方
  • 不同的地方
• 为什么要推荐使用 git rebase 呢?
• 这里还有几点重要的说明

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

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

git merge 合并分支

创建分支和提交记录

1. 从master分支创建一个merge1分支，进行第一次提交

git checkout master
git checkout -b merge1
git add .
git commit -m 'merge1'

2. 从master分支创建一个merge2分支，修改代码，进行第一次提交

git checkout master
git checkout -b merge2
git add .
git commit -m 'merge2'

3. 切换到merge1分支，修改代码，进行第二次提交

git checkout merge1
git add .
git commit -m 'merge1-2'

4. 切换到merge2分支，修改代码，进行第二次提交

git checkout merge2
git add .
git commit -m 'merge2-2'

进行合并

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

git checkout merge1
git merge merge2

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

git merge --abort

解决冲突

7. 解决冲突之后(这里选择保留双方更改)，这里选择直接提交代码

git add .
git commit -m 'merge1 merge merge2'

回滚代码

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

补充操作

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

git merge --continue

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

10. 9步之后想要回到merge1-2，操作git reset

git reset <commitID>

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

创建分支和提交记录

1. 从master分支创建一个merge1分支，进行第一次提交

git checkout master
git checkout -b merge1
git add .
git commit -m 'merge1'

2. 从master分支创建一个merge2分支，修改代码，进行第一次提交

git checkout master
git checkout -b merge2
git add .
git commit -m 'merge2'

3. 切换到merge1分支，修改代码，进行第二次提交

git checkout merge1
git add .
git commit -m 'merge1-2'

4. 切换到merge2分支，修改代码，进行第二次提交

git checkout merge2
git add .
git commit -m 'merge2-2'

进行合并

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

git checkout merge1
git rebase merge2

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

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

git rebase --abort

处理冲突

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

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

git add .
git rebase --skip

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

10. 然后提交修改

git add .
git rebase --continue

11. 此时查看git log，发现合并后的log展示

• 并没有再生成新的提交记录
• 这里的log顺序和merge不同
• 因为刚才我们使用skip跳过了一个commit，所以这里并没有merge1。

版本回滚

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

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

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

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

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

如何对代码进行合并呢?

请看这篇博客：方法二：合并需要的commit

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

2. 得到一个干净整洁的版本树

通过上面的原理图我们可以看到，在分支存储的时候，两个分支的内容还是实际还是分开的，而rebase之后的版本树，是一条真实干净的版本树。这个对以后正式版本的维护是很可的一件事，也是推荐大家用的。

这里还有几点重要的说明

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

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

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

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