git merge的原理和过程，merge conflict产生的原因、处理的逻辑
一、git merge的原理和过程
检测合并基础+三方合并+工作副本更新（生成一个新节点提交）
例子：
如上图所示，我们有两个分支，master 分支和 test 分支，test 分支是基于 master 分支在B处的提交节点创建的，在创建后 master 分支又经过迭代提交了两次，从C到D节点，test 分支也基于B往前继续更新了两次，到了F节点。两者从B开始就走向了分叉。
这时如果我们想将 test 分支合并到 master 分支，则会生成一个节点G，它是将基础节点也就是B，两个分支的最新提交D和F进行三方合并，生成节点
再解释一下与git merge类似作用的git rebase：
官方解释： 当执行 rebase 操作时，git 会从两个分支的共同祖先开始提取待变基分支上的修改，然后将待变基分支指向基分支的最新提交，最后将刚才提取的修改应用到基分支的最新提交的后面。
如上图所示：
git就会从两者的共同祖先B开始，提取 master 分支上的修改，也就是 C,D 两个 commit ,提取到之后 git 会先保存起来，然后将master 分支指向 test 分支最新提交的节点，也就是F节点，然后把提取到的 C,D 接到F后面，在这个过程当中，会删除原来的C,D commit 记录，生成新的C‘，D'，虽然C',D'和原来的C,Dcoommit的内容是一样的，但是 commit id 是不同的。
rebase 操作如果用一句话进行解释就是改变基底。master 分支原来的基底是A，现在变成了以 test 分支最新的提交F做为新的基底了。
二、merge conflict产生的原因、处理的逻辑
Merge Conflict产生的原因：
首先在merge时对于每个文件，Git会对比这三个提交点（三路）中的内容。如果双方对某个文件的修改不冲突（修改的内容是一致的），Git则能自动将这些更改合并在一起。如果在共同祖先之后，两个分支对同一文件做出了不同的修改，那么就会出现冲突，Git会在合并过程中标记出这些冲突，并暂停合并，等待用户手动解决。
通常发生在以下情况会产生冲突：
同一个文件的同一个位置被不同的分支修改：如果两个分支都在一个文件的同一行进行了修改，Git将无法确定哪个修改是正确的。
删除与修改冲突：一个分支删除了一个文件或行，而另一个分支修改了同一个文件或行。
分支整体的改变：如果某个文件的整个区域发生了较大的修改，这也可能导致Git无法自动合并。
Merge Conflict处理的逻辑：
查看冲突：Git标记发生冲突的文件，并在文件中添加冲突标记，以供开发者手动解决。冲突部分会显示如下：
<<<<<<< HEAD Your changes ======= Incoming changes from the other branch >>>>>>> branch-name手动解决冲突：开发者需要手动编辑文件，选择保留哪部分的更改或者进行合并，确保最终文件内容的正确性。
标记为解决：解决冲突后，使用
git add将解决后的文件标记为已解决。完成合并：在所有冲突解决后，使用
git commit提交合并结果。