Git | 分支管理
文章目录
- [Git | 分支管理](#Git | 分支管理)
1、理解分支
分支就类似分身。
-
在版本回退中,每次提交Git都会将修改以git对象的形式串联成一条时间线/分支。
-
只有一条默认的时间线,这个分支就叫master分支
-
HEAD并不严格指向提交,而是指向分支,如果当前的分支是master,那么就会有下边的情况
-
每次提交master都会向前移动
2、创建分支&&切换分支
-
查看当前本地分支:
git branch
HEAD指针指向:master
-
新建分支dev:
git branch dev
-
查看当前分支:
git branch
-
切换到master分支:
git checkout dev
HEAD指针指向:dev
3、合并分支
比如dev分支中ReadMe后边追加了一行,i am coding,之后想要合并到Master上。
说明:为了避免合并冲突,一般会先提交,之后将master分支合并到dev上边,看是否有冲突,有则解决,无则继续操作。
4、删除分支
合并完成后dev分支没用就可以被删除掉。
如果想要删除,我们需要在其他分支上,如master分支
- 查看当前分支:
git branch
- 切换到Master分支:
git checkout master
- 删除分支:
git branch -D dev
- 再次查看分支,发现已被删除:
git branch
5、合并冲突
在实际分支合并的时候,可能存在代码冲突的问题。
例如,现在master分支和dev分支分别对ReadMe文件进行修改并提交,dev分支在原文本后边添加i am coding,master 在文本后边添加finish并且分别add和commit,再尝试将dev分支合并至master分支时就会出现合并冲突的情况:
-
dev分支下修改并提交:
-
切换至master分支下修改并提交:
-
在Master分支下合并dev分支:可以看到冲突在ReadMe文件
-
我们查看ReadMe文件
其中<<<到===之间就是当前分支上的代码,后边的是dev分支上的代码,冲突的都在这里。
我们需要手动决定到底要怎么决定
-
假设我们保留i am coding,把其他不需要的删除,还需要add和commit操作
此时master分支是最新的提交,dev还是原来的
可以看一下日志:
git log --graph --pretty=oneline --abbrev-commit
也可以证明我们刚刚的提交是merge的提交
另外合并完成之后,dev分支不使用了就可以删除:(删除dev分支就需要让HEAD指针指向别的分支)
6、分支管理策略
合并分支模式
合并分支模式有两种
- Fast forward模式 :merge默认情况,这次模式下,我们删除分支,查看分支历史时,就会丢掉分支信息,不知道最新提交是merge进来的还是正常提交的
- --no-ff方式:即强制禁用Fast forward模式。使用时注意要让master指向新的提交即使dev分支已经删除,也可以看到当前的提交是merge进来的还是由其他分支合并得到的
例如:
-
创建dev2分支,修改ReadMe,commit一次,切换至master分支,合并
-
查看日志
-
删除dev2分支再次查看日志
会发现使用禁用ff模式,仍然能看得到怎么来的
分支合并建议:
最好先在自己分支下合并master,有冲突在dev分支解决掉,再去master分支下进行merge【bug分支演示】
注意:合并完之后要进行一次提交
实际工作中分支策略
bug分支
master分支上有bug时,解决bug的流程:在git中,每个bug都可以通过一个新的临时分支来修复,修复完成之后合并分支,并将临时分支删除。
如果我们正在dev2分支上开发了部分代码,但是还没有提交,遇到bug怎么解决?
不要使用dev进行修理bug,否则就违背了dev分支初衷。
-
准备工作:创建dev2分支,并进行修改但不add和commit,切换到master
-
如果不想看到,同时防止影响之后bug分支的修复,可以使用git stash命令将它暂时隐藏:
会发现多了stash【只存储已经被git追踪管理的文件】
再次查看状态,发现不再受原来dev2分支影响
-
修复bug
-
合并到master上
-
切回dev2分支,恢复工作区,再次查看工作区内容:
-
开发完dev2,提交后,在dev2分支合并master分支,并解决冲突
-
切换到master分支上,进行merge
\解决带有修复bug冲突的文件时,把当前的最好放在解决bug之后
删除临时分支
git branch -d dev2
强制删除:git branch -D dev2