目录
- 实践是检验真理的唯一标准
- git merge 合并代码
- 创建分支和提交记录
- 进行合并
- 解决冲突
- 回滚代码
- 补充操作
- 再来看看使用 git rebase 合并分支
- 创建分支和提交记录
- 进行合并
- 处理冲突
- 版本回滚
- git rebase 还有什么优化的空间吗?
- 为什么要对版本进行合并?
- 如何对代码进行合并呢?
- git merge 合并代码
- git merge VS. git rebase 总结
- 相同的地方
- 不同的地方
- 为什么要推荐使用 git rebase 呢?
- 这里还有几点重要的说明
我们现在分支合并想到最多的就是git merge，还有一个合并代码的命令git rebase，而这个命令在工作中优先被推荐使用，下面先通过两个例子体会一下两个命令合并代码的差别：
实践是检验真理的唯一标准
git merge 合并分支
创建分支和提交记录
- 从
master分支创建一个merge1分支，进行第一次提交
git checkout master
git checkout -b merge1
git add .
git commit -m 'merge1'
- 从
master分支创建一个merge2分支，修改代码，进行第一次提交
git checkout master
git checkout -b merge2
git add .
git commit -m 'merge2'
- 切换到
merge1分支，修改代码，进行第二次提交
git checkout merge1
git add .
git commit -m 'merge1-2'
- 切换到
merge2分支，修改代码，进行第二次提交
git checkout merge2
git add .
git commit -m 'merge2-2'
进行合并
5.将merge2分支merge到merge1分支中，解决冲突之后会有一个新的 merge 的 commit 分支。
git checkout merge1
git merge merge2
- 如果想取消合并，直接使用
git merge --abort
git merge --abort
解决冲突
- 解决冲突之后(这里选择保留双方更改)，这里选择直接提交代码
git add .
git commit -m 'merge1 merge merge2'
回滚代码
- 如果想要回到
merge1-2，执行操作git reset
补充操作
- 在第7步的时候，如果直接使用
git merge --continue会进入面板，可以修改提交分支的信息
git merge --continue
这个时候i插入，修改merge1 merge merge2 continue之后按ESC键，然后按:wq保存，可以看出，这边还是会新保留一个commit
- 9步之后想要回到
merge1-2，操作git reset
git reset <commitID>
再来看看使用 git rebase 合并分支
创建分支和提交记录
- 从
master分支创建一个merge1分支，进行第一次提交
git checkout master
git checkout -b merge1
git add .
git commit -m 'merge1'
- 从
master分支创建一个merge2分支，修改代码，进行第一次提交
git checkout master
git checkout -b merge2
git add .
git commit -m 'merge2'
- 切换到
merge1分支，修改代码，进行第二次提交
git checkout merge1
git add .
git commit -m 'merge1-2'
- 切换到
merge2分支，修改代码，进行第二次提交
git checkout merge2
git add .
git commit -m 'merge2-2'
进行合并
- 切换到
merge1分支，进行rebase操作git rebse merge2
git checkout merge1
git rebase merge2
首先这里可以看到要和两个提交进行rebase，
- 此时想要退出合并，写
git rebase --abort
git rebase --abort
处理冲突
- 我们要手动修改第一个提交，因为这个提交不是最后一个提交，所以内容可以不保留，选择采用当前更改
- 然后提交修改，这里先使用
git add .，然后使用git rebase --continue时说没有修改，是否强制使用git rebase --skip跳过
git add .
git rebase --skip
- 这个成功之后进入下一个提交，这里可以看到，这里与
merge的当前更改和传入更改的位置是有改变的，传入的更改反而是merge1，这个时候选择保留双方更改。
- 然后提交修改
git add .
git rebase --continue
- 此时查看
git log，发现合并后的log展示
- 并没有再生成新的提交记录
- 这里的
log顺序和merge不同 - 因为刚才我们使用
skip跳过了一个commit，所以这里并没有merge1。
版本回滚
- 此时要回滚到
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记录按照版本提交时间进行排列，并不是版本的真实顺序。 image
|
按照合并顺序进行排列，实际版本的真实顺序 image
|
| 原理图 | 这个是分支存在的真实结构图 image
|
这个图描述了，merge1的rebase操作，是将merge2代码拉过来之后将自己合并到其后面 image
|
为什么要推荐使用 git rebase 呢?
- 避免在总分支上手动处理冲突的危险操作
我们实际开发的时候，都会有一个总的dev分支，和一个自己的分支work，正确的操作是我们应该先将dev的分支拉过来，然后将我们的代码合并上去，首先在我们自己的work代码中，有一个处理完冲突的最新代码，其次再去dev分支merge我们的work分支，这样，就不会出现在dev分支上手动处理冲突的危险操作。
# 在work分支
git rebase dev
# 处理完分支，切换到dev分支
git checkout dev
# 合并work分支的代码
git merge work
- 得到一个干净整洁的版本树
通过上面的原理图我们可以看到，在分支存储的时候，两个分支的内容还是实际还是分开的，而rebase之后的版本树，是一条真实干净的版本树。这个对以后正式版本的维护是很可的一件事，也是推荐大家用的。
这里还有几点重要的说明
千万不要用
dev分支去rebase我们自己的分支。rebase dev的时候，尽量先将自己所有的commit合并成1个，然后再进行rebase操作。对于
dev分支来说，使用rebase更好一些。如果进行回滚操作了，那么当前分支修改之后还需要再次与dev进行一次merge操作。如果是rebase，直接可以在最新的代码中进行修改。重重重要的说明! 重重重要的说明! 重重重要的说明!有些人会说
rebase的操作复杂，而且回滚操作很不方便，我们都知道合并是一件很慎重的事情，所以我们在进行合并操作的时候，也要进行慎重思考。之前也有遇到过，有同时滥用merge将别人代码冲掉的情况，所以对于开发来说，上线的东西质量保证是很重要的。
