Git(七)分支(二)分支的本质

一    一条分支的情况

++++++++++++++'下面讲解整个版本库只有一个分支的情况'++++++++++++++

1）一条'工作记录线'也就是一条'时间线'

2）四条'commit'共同组成一个'branch'

3）第'n'次提交的 'parent commit_id'刚好等于第'n-1'次的'commit_id',正是'这个关系'将所有的提交'连接起来',最终呈现为'git log'

二   分支的两个核心概念

1）'HEAD'是一个指针,'大写',指向的是'当前分支'

说明： 一个项目中有'若干个分支',某一时刻'一定处于某个分支',HEAD就会'指向'当前所处的分支

2）'分支(master、dev)'指向的是提交

①  一个分支

+++++++++++'解读下面图的含义'+++++++++++

只有一个'master'分支,下面'三个圈'表示3次提交

②  两个分支

+++++++++'下面图的解读'+++++++++

1）红色的'dev'分支是在'master'的基础上调用-->'git checkout -b dev'创建并切换分支

git branch dev

git checkout dev

2）效果：只是'新建了一个指针',指针的名字叫做dev,'它-->dev'在'当前时刻'和master指向'同一个提交',所以二者的'文件相同'

'验证'： git branch -d dev 就能感觉到

+++++++++'更具体的理解'

（1）dev指向了'master'最近的一次'提交' -->   'git branch dev'

（2）HEAD'指向了'dev分支              -->   'git checkout dev'

③  思考：HEAD存在哪？

④  继续演进

具体措施： 在'dev'分支上'修改文件'做了'一次提交'

注意： 文件的'修改方式' -->'添加了一行'

1）dev上修改进行提交 

1）对比log

说明： 合并前对比'dev'和'master'最近的三条的'git log -3'

2）尝试合并

1）合并并'没有'冲突-->'Fast Forward'

+++++++'上面的操作和下面图示理解'+++++++

1）合并之后master指向了'第四次提交'-->'git log'也能看出

++++++++++++'动态图的理解'++++++++++++

说明： 将'test'换成'dev'理解即可

⑤  冲突问题

+++++++++++'假设这样一种场景'+++++++++++

1) 'dev'和'master'都指向'同一次'提交

2） 'dev'修改了ceshi.txt的'第三行'后进行提交

Hello Java
Hello Maven
Hello Dev

3） 'master'也修改了ceshi.txt的'第三行'后进行'提交'

Hello Java
Hello Maven
Hello Master

4） 此时尝试将'dev'上修改合并到'master'上会发生什么现象？

合并过程conflict('冲突原因')：不同分支修改'同一个文件的同一行','git'不知道以'谁为基准',所以把'选择权'交给用户

5）此时'查看文件状态'  -->  'git status'

6）解决'冲突'-->首先看下'conflict file'-->'ceshi.txt'

7）解决'冲突',通过'git status'的输出'辅助'操作

注意： 这里的'git add file'区别之前的'git add file'

之前的含义： 将之前'未追踪'的文件加入到'暂存区'

备注： 解决'冲突'之后  -->'git add file'  -->虽然'冲突已经解决',但是仍然'处于merging状态'  -->'git commit'

8）'解决冲突'后观察'两分支的log'

+++++++++++'对比得知'+++++++++++

1）'dev分支'已经落后于'master分支','解决冲突'进行合并实际'master'又完成一次提交

2）'master'分支的提交历史包含'dev 分支'的提交历史

⑥  继续探究

思考： 此时如果将'master'分支合到'dev'分支上是否会'发生冲突'?

答案： '不会'发生冲突

原因： 相当于master分支'往回合并','dev'分支已经落后'master',git认为是一个'Fast Forward快进',直接'跳过去'

合并处理冲突