Git | 分支管理
文章目录
- Git | 分支管理
- 1、理解分支
- 2、创建分支&&切换分支
- 3、合并分支
- 4、删除分支
- 5、合并冲突
- 6、分支管理策略
- 合并分支模式
- 实际工作中分支策略
- bug分支
- 删除临时分支
1、理解分支
分支就类似分身。
-
在版本回退中，每次提交Git都会将修改以git对象的形式串联成一条时间线/分支。
-
只有一条默认的时间线，这个分支就叫master分支
-
HEAD并不严格指向提交，而是指向分支，如果当前的分支是master，那么就会有下边的情况
-
每次提交master都会向前移动
2、创建分支&&切换分支
-
查看当前本地分支：
git branchHEAD指针指向:master
-
新建分支dev：
git branch dev -
查看当前分支：
git branch -
切换到master分支：
git checkout devHEAD指针指向:dev
3、合并分支
比如dev分支中ReadMe后边追加了一行，i am coding，之后想要合并到Master上。
说明：为了避免合并冲突，一般会先提交，之后将master分支合并到dev上边，看是否有冲突，有则解决，无则继续操作。
4、删除分支
合并完成后dev分支没用就可以被删除掉。
如果想要删除，我们需要在其他分支上，如master分支
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
