「这是我参与2022首次更文挑战的第13天，活动详情查看： 2022首次更文挑战 」
我们选择Git的一个重要原因就是其分支创建和切换的快捷便利，在前面Git原理的基础上，我们今天再来学习下Git分支相关的原理。
HEAD的本质是个指针，指向当前分支
ref: refs/heads/master
我们实际也可以将分支理解为一个指针，其指向某个commit
初始化时会默认创建master分支，此时master没有指向任何commit
分支的创建
分支的创建实际就是新建指针，指向某个commit（一般为当前分支）
git branch dev
分支的切换
分支的切换实际就是将HEAD指向新分支
git checkout dev
在当前分支提交
提交将产生新的commit并将当前HEAD指向的分支移动到前端
git add .
git commit -m dev
分支的合并也就是我们通常说的
git merge barnch_name
分支的合并实际包括多种不同的策略，我们介绍常见的几种
Fast-foward
如果待合并分支和当前分支处于同一条commit链条上，Git会帮我们选择Fast-foward，仅仅移动更新当前分支指针指向
git merge dev
我们可以添加参数来产生新的commit
git merge --no-ff
Recursive
Git合并中最常见的合并策略，我们将其称为Tree-Way Merge。当待合并分支及当前分支都有不同于彼此的commit时候，会采用Recursive策略。
找到最近的公共祖先节点
根据Diff差异生成合并commit（我们常见的merge commit）
如果没有冲突的情况下，Git会自动完成合并并生成新的合并commit并结束merge。但是如果遇到冲突，我们需要解决冲突并手动添加冲突文件并执行continue。
git add .
git merge --continue
对于冲突文件，我们也可以添加参数来自动解决突出。不过我们实际并不提倡这么做。
git merge -Xours dev # 冲突部分以当前分支为准
git merge -Xtheirs dev # 冲突部分以待合并分支为准
如何寻找最近公共祖先commit
我们可以通过命令寻找最近公共祖先节点
git merge-base --all branch_1 branch_2
在实际的开发工作中，由于不同分支的相互合并是很有可能出现多个最近祖先commit的。
在这种情况下，实际会将两个commit合并一个虚拟commit作为我们合并的base
Ours策略和上文提到的-Xours参数非常相像，但在这边的Ours对所有文件生效，无论是否发生突出都以当前分支为准，实际上是丢弃了待合并分支的所有内容。一般用在一个功能分为两种方案进行开发，最终保留其中一种，但是可以将另一种方案的commit合并进来待日后查看。
为什么Git的分支创建及切换能那么快？
因为其分支的创建及切换实际是对指针的创建及移动，将其指向到对应的commit中，而由于Git的commit中是保存全量数据的，所以将某个commit的文件应用于当前工作区也会非常快，不需要通过diff来对比更新。
为什么合并需要三方合并（Tree-Way Merge）？
合并的目的是将B分支的修改应用到A分支，所以我们需要一个base节点来对比B分支得到B分支的实际修改，当然也要通过A分支和base节点的对比来得到A分支的修改。如果两个分支对某个文件都有修改的话，应该给予冲突提示，否则应用两个分支的最新修改就行。
小伙伴们平常可能会遇到这么个情况，明明某个分支的A文件代码和当前分支的A文件代码不同，但就是merge不过来？
这种情况一般是因为上次解决合并冲突导致的。我们通过例子来说明
我们开始有两个分支A和B
我们将B合并到A1生成A2，此时A1和B是有冲突的，我们保留了A1的修改而舍弃B的修改
我们往B中进行新的提交生成B1，此时再合并B1到A2
根据我们前面的分析，此时会寻找最近公共祖先节点也就是B节点作为BASE，此时B B1 A2进行三方合并.
B1相对于B的修改不包括我们刚才冲突的部分，A2相对于B的修改包括刚才冲突的部分，此时将视为A2为最新提交自动合并。
所以刚才冲突的部分既没有再产生冲突，也没有任何提示，直接就应用了A2的代码。
本篇文章分析了Git中分支的本质及一些常见的合并策略以加深我们对于Git的认知。
git合并原理
前端开发 @ 无业
93.3k