目录
-
实际是测验真谛的唯一标准
-
git merge 合并代码
- 创立分支和提交记录
- 进行合并
- 解决抵触
- 回滚代码
- 补充操作
-
再来看看应用 git rebase 合并分支
- 创立分支和提交记录
- 进行合并
- 解决抵触
- 版本回滚
-
git rebase 还有什么优化的空间吗?
- 为什么要对版本进行合并?
- 如何对代码进行合并呢?
-
-
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 记录依照版本提交工夫进行排列,并不是版本的实在程序。<br/> | 依照合并程序进行排列,理论版本的实在程序 <br/> |
原理图 | 这个是分支存在的实在结构图 <br/> | 这个图形容了,merge1 的 rebase 操作,是将 merge2 代码拉过来之后将本人合并到其前面 <br/> |
为什么要举荐应用 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
将他人代码冲掉的状况,所以对于开发来说,上线的货色质量保证是很重要的。