git合并代码原理

背景：

最近在做体测，当我将prod-wmj合并到我新建的test-physical分支上的时候，出现超出我认知范围的现象，所以我认为git的原理我们没有搞懂，还要搞搞。merge的时候红色部分并不是我理解的目标分支的代码，那就让我们来想想吧~

操作：

1、首先提出来问题，代码更改有几种形式？git又是怎么做的？如果你是git工作人员，你会如何设计？

2023年4月9日10:53:58
如图，只有都改变的时候才会出现冲突，那git是如何给我们自动解决冲突的呢？显示的红色代码和绿色代码又是什么呢？

基于上边的认知，我应该去找谁呢？找这么多次提交的源文件是什么样子吗？画一个问号？（暂时搁置，先跳过去，这个问题每天花半个小时思考）

总结：

Git合并的原理是将两个或多个分支的修改集成到一个新的提交中。在Git中，合并操作主要通过三方面的内容来实现：共同祖先、三方合并和冲突解决。

首先，合并操作需要找到两个分支的共同祖先。Git使用一个称为"commit graph"的有向无环图来记录提交历史。通过比较两个分支的提交历史，Git可以找到它们的共同祖先。这个共同祖先是一个基准点，用于确定要合并的变更。

其次，Git使用三方合并算法来将两个分支的修改合并到一个新的提交中。三方合并算法比较共同祖先和要合并的两个分支之间的差异，然后尝试自动合并这些差异。这个算法会自动合并那些没有冲突的修改，并生成一个新的合并提交。

最后，如果在合并过程中存在冲突，Git会将冲突标记出来，需要手动解决这些冲突。冲突通常发生在两个分支对同一文件的同一部分进行了不兼容的修改。在冲突解决过程中，Git会将冲突的文件标记为包含冲突的状态，开发人员需要手动编辑这些文件，解决冲突并选择要保留的修改。

Git合并的过程可以用以下步骤来概括：

1. 找到要合并的两个分支的共同祖先。
2. 比较共同祖先和要合并的两个分支之间的差异。
3. 如果没有冲突，自动合并差异，生成一个新的合并提交。
4. 如果存在冲突，将冲突标记出来，需要手动解决冲突。
5. 手动解决冲突后，将解决后的文件添加到暂存区。
6. 提交合并结果，生成一个新的合并提交。

在实际使用Git进行合并操作时，可以使用git merge命令来执行合并操作。该命令会自动找到要合并的分支，并执行上述的合并过程。

总结起来，Git合并的原理是通过找到共同祖先、使用三方合并算法和手动解决冲突这三个步骤来将两个或多个分支的修改集成到一个新的提交中。这个过程可以保留分支的独立性，同时将不同分支的修改整合到一起，使得团队协作更加高效。

注意点

Merge和Rebase是Git中两种常用的分支合并方式，它们有相同点和不同点。

相同点：

1. 目的：Merge和Rebase都是用于将一个分支的修改合并到另一个分支上。
2. 分支保留：无论是Merge还是Rebase，都会保留原始分支的提交历史。
3. 冲突解决：无论是Merge还是Rebase，都可能会导致冲突，需要手动解决。

不同点：

1. 合并方式：Merge采用的是三方合并算法，将两个分支的差异合并到一个新的合并提交中。Rebase则是将一系列提交从一个分支移动到另一个分支上，通过将提交逐个应用到目标分支上来实现合并。
2. 提交历史：Merge会保留原始分支的提交历史，将合并的结果作为新的提交。而Rebase会将原始分支的提交历史重新应用到目标分支上，形成一条线性的提交历史。
3. 分支图形：Merge会在分支图形中生成一个新的合并提交节点，形成一个分支合并的图形结构。而Rebase会将提交应用到目标分支上，不会生成新的合并提交节点，分支图形会更加线性。
4. 分支清理：由于Rebase会将原始分支的提交历史重新应用到目标分支上，所以原始分支上的提交会被"移走"，只保留目标分支上的提交。这样可以保持分支历史的整洁性，但也可能导致其他人在原始分支上的基于旧提交的工作失效。

选择Merge还是Rebase取决于具体的情况和需求。一般来说，如果要合并的分支是公共分支，多人共同开发的，推荐使用Merge，因为它可以保留分支的独立性和清晰的提交历史。如果要合并的分支是私有分支，个人开发的，可以考虑使用Rebase，因为它可以产生更加整洁的提交历史。但需要注意的是，使用Rebase时要谨慎处理，避免对他人的工作造成影响。