分支管理
在版本库当中有一个head指针，指向master分支。master存储的是最新一次提交的commit id（版本号） ==>对应的是版本库当中对象库的一个对象的索引
在版本回退⾥，每次提交，Git都把它们串成⼀条时间线，这条时间线就可以理解为是⼀个分⽀，目前为止：只有⼀条时间线，在Git⾥，这个分⽀叫主分⽀，即master分⽀
再次理解HEAD
HEAD严格来说不是指向提交，⽽是指向master，master才是指向提交的，所以，HEAD指向的就是当前分⽀。每次提交，master分⽀都会向前移动⼀步，这样，随着你不断提交，master分⽀的线也越来越⻓,⽽HEAD只要⼀直指向master分⽀即可指向当前分⽀
创建分支
查看当前本地所有的分支：git branch
- 注意：如果想要查看远程分支，需要加上 -r 选项，但前提是要pull⼀下拉取最新的远端仓库，才能看到最新的内容
创建新分支：git branch 新分支名
创建新的分⽀后，Git新建了⼀个指针叫dev，*表示当前HEAD指向的分⽀是master分支。可以通过⽬录结构发现新的dev分支
⽬前dev和master指向同⼀个修改，因为创建dev分支的时候，是基于最新的一次提交创建出来的，所以其指向最新的提交，并且也可以验证下HEAD⽬前是指向 master 的
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-TbLt8ci5-1690538256500)(https://mangoimage.oss-cn-guangzhou.aliyuncs.com/202306142112305.png)]
画图分析：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-lZE1NZsz-1690538256501)(https://mangoimage.oss-cn-guangzhou.aliyuncs.com/202306142112876.png)]
切换分支
切换分支：git checkout 分支名
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-y0muZiYt-1690538256501)(https://mangoimage.oss-cn-guangzhou.aliyuncs.com/202306142115956.png)]
HEAD已经指向了dev分支，就表示我们已经成功的切换到了dev分支上
HEAD可以指向其它分支，被HEAD指向的分支就是当前正在工作的分支
回忆：该命令也可以进行工作区的文件回退，前提是该文件已经add和commit。
git checkout -- 文件名：让⼯作区的对应文件回到最近⼀次add 或者 commit时的状态**
情形1：在dev分支做修改，master分支如何？
1°：在 dev 分⽀下修改ReadMe⽂件，新增⼀⾏内容，并进⾏⼀次提交操作
2°：回到master分支，此时并不能看到ReadMe新增的内容
3°：但是如果切到dev分支查看ReadMe文件，仍然可以看到新增的内容
原因就是两者指向的提交是不⼀样的
图解：由于是在dev分⽀上提交的，⽽master分⽀此刻的提交点并没有变，此时的状态如图如下所⽰
当切换到master分⽀时，HEAD就指向了master，当然看不到提交了
补充：使用git branch -b 分支名：完成创建并切换分支的动作
合并分支
为了在master主分⽀上能看到新的提交，就需要将 dev 分⽀合并到 master 分⽀，合并后，master就能看到dev分⽀提交的内容了
git merge 分支名：合并指定分支到当前分支
合并的时候：采取的是Fast-forward：快进模式，直接把master分支指向dev分支的当前提交，所以合并速度⾮常快。当然也不是每次合并都能Fast-forward
整体步骤：
删除分支
删除分支命令：git branch -d 分支名
合并完成后,dev分⽀对于我们来说就没用了，那么dev分支就可以被删除掉，但是注意：如果当前正处于某一个分支，那么就不能删除当前所在的分支，但是可以在其它分支下删除当前分支。
此时的状态图如下：
创建、合并和删除分支非常快，所以Git更建议我们使⽤分⽀完成某个任务，合并后再删掉分⽀，这和直接在master分⽀上⼯作效果是⼀样的，但过程更安全
分支冲突
在实际分⽀合并的时候，并不是想合并就能合并成功的，有时候可能会遇到代码冲突的问题。例如下述的情况：
步骤：
- 1.创建⼀个新的分⽀dev，并切换⾄⽬标分⽀ =>可以使用
git checkout -b 分支名完成创建并切换的动作 - 2.在dev分支下修改ReadMe文件，更改⽂件内容之后，并进⾏⼀次提交
- 3.切换至master分支下观察ReadMe文件内容的变化，此时可以发现：⽂件内容还是⽼的版本，原因就是：此时master分支和dev分支，两者指向的提交是不⼀样的
- 4.如果此时在master分支上对ReadMe⽂件再进⾏⼀次修改，并进⾏提交，那么此时master分支和dev分支都分别有新的提交，状态如下：
在这种情况下：Git只能试图把各⾃的修改合并起来，但这种合并就可能会有冲突
发现ReadMe⽂件有冲突后，可以直接查看⽂件内容，Git会⽤<<<<<<<，=======，>>>>>>来标记出不同分⽀的冲突内容，此时我们必须要⼿动调整冲突代码，并需要再次提交修正后的结果！！然后就可以删除dev分支了
查看分支的合并情况：git log --graph --pretty=oneline --abbrev-commit
此时的状态如下
