总结：全网最详细，Git分支合并、项目推拉的底层核心原理解析，看完不会你找我。

一·Git合并分支底层原理：

（1）优先比较两个分支提交的commit记录（即，分支的版本记录），根据是否有版本变化、以及谁合并谁，从而决定是否需要合并分支代码：

#“比较两个分支提交的commit记录”详情如下：
（1）分别将两个分支的commit记录，相对于当前需要合并的两个分支最近一次相同版本记录比较。
（2）若一个分支有新版本变化，一个分支没有新版本变化，则有新版本变化的分支直接胜出。
	
此时两个分支合并情况大致描述：
（1）若将有版本变化分支，合并到无版本变化分支上面，则git会直接将有变化分支的最新版本复制到无变化分支上面
（2）若将无版本变化分支，合并到有版本变化分支上面，则git不会发送合并，而是提示已经合并过该分支，相当于忽略了无版本变化分支内容。

（2）当两个分支的commit记录都有新变化。Git就会在当前分支项目中进行每个文件、每行代码比较；比较完之后就会分别显示出哪些文件有无版本控制、哪些文件已修改、哪些文件已删除、哪些文件新增等等。若是没有冲突就会直接合并。有冲突就会提示你，让你解决完冲突再合并。解决冲突之后就会直接合并。（一般都会产生冲突）

二·各种情况下合并分支流程演示：举例演示说明

如图所示：commit记录

演示前提：

1.假如当前本地存在一个项目P,当前分支为master，且当前初始版本为1；

2.此时在当前项目的master分支上，创建一个新分支hot-fix,且版本也为1；

注意：新建的分支，就相当于复制了一份原项目，所以版本会与原项目保持一致

情况一：此时在master的基础上，再次进行开发项目，并提交到本地仓库，成为版本2；此时hot-fix分支还处于版本1；

#若将hot-fix合并到master分支上面，Git合并流程如下：
（1）Git会比较两个分支的commit记录。

（2）发现master分支，相对于当前需要合并的两个分支最近一次相同版本1，有新版本变化；

（3）而hot-fix分支，相对于当前需要合并的两个分支最近一次相同版本1，没有版本变化。

（4）结果：此时就不会发生合并。Git会提示你，已经合并过hot-fix分支，当前master分支还是处于版本2，不会发生任何改变。

#若将master合并到hot-fix分支上面，Git合并流程如下：
（1）Git会比较两个分支的commit记录。

（2）发现master分支，相对于当前需要合并的两个分支最近一次相同版本1，有新版本变化；

（3）而hot-fix分支，相对于当前需要合并的两个分支最近一次相同版本1，没有版本变化。

（4）结果：会发生合并。当前hot-fix分支，会被覆盖为master的版本2代码，版本也会成为，master版本2。但是合并过程，不会发生任何代码冲突，因为是直接覆盖代码。

情况二：此时在master的基础上，再次进行开发项目，并提交到本地仓库，成为版本2；此时hot-fix分支也进行开发，成为版本3，或者版本5，6，7等任何版本；

#若将hot-fix合并到master分支上面，Git合并流程如下：
（1）Git会比较两个分支的commit记录。

（2）发现master分支，相对于当前需要合并的两个分支最近一次相同版本1，有新版本变化；

（3）而hot-fix分支，相对于当前需要合并的两个分支最近一次相同版本1，也有新版本变化；

（4）此时由于两个分支都有新版本变化，因此比较的时候，git会以master分支项目代码为基础，然后跟hot-fix分支项目进行比较，再将发现代码冲突的文件交给人为处理；至于hot-fix分支删除的原项目文件，也会给出提示让用户确认处理；至于hot-fix分支新增的文件，会在最后处理完冲突同意合并的时候，自动新增进项目分支。当然如果两个分支开发的业务逻辑功能完全是两个不相关的，也可能不会有任何冲突代码。（git会自动提醒开发人员解决冲突）

（5）结果：会发生合并。若有代码冲突以及删除确认等需要先解决完，才会合并代码。合并完后master分支还会自动提交到本地库，成为一个新版本。

#若将master合并到hot-fix分支上面，Git合并流程如下：
（1）Git会比较两个分支的commit记录。

（2）发现master分支，相对于当前需要合并的两个分支最近一次相同版本1，有新版本变化；

（3）而hot-fix分支，对于当前需要合并的两个分支最近一次相同版本1，也有新版本变化；

（4）此时由于两个分支都有新版本变化，因此比较的时候，git会从hot-fix项目代码中逐行比较，从其中某一行不同开始算起，一直到hot-fix分支项目的最后。这部分代码，都是冲突代码，需要人为处理一下。（git会自动提醒开发人员解决冲突）

（5）结果：会发生合并。但是需要先解决完冲突，才会合并代码。合并完后hot-fix分支还会自动提交到本地库，成为一个新版本。

注意：
（1）此时虽然看似hot-fix分支版本更高一些，但git并不会这么理解。无论你hot-fix分支版本迭代了多少次版本，git只会将hot-fix分支的当前最新版本，与当前需要合并的两个分支最近一次相同版本进行比较。有变化就直接视为新版本变化，无变化就是原版本。git并不会认为某个分支，比最近一次相同版本有很多版本变化。

（2）某个项目的不同分支，两两之间都会至少存在一次相同版本记录，不可能不存在。除非这完全是两个不同项目，但是那样合并就没有任何实际意义。那就相当于删除一个项目，保留另外一个项目了。人为手动删除不就得了，干嘛费劲开发一个版本控制工具git。

（3）所谓分支版本相同，就表示这两个分支里面的任何内容都完全一样。

情况三：此时在master的基础上，再次进行开发项目，成为实际版本2，但是没有commit提交到本地仓库；此时hot-fix分支仍然处于版本1；

#若将hot-fix合并到master分支上面，Git合并流程如下：
（1）Git会比较两个分支的commit记录。

（2）发现master分支，相对于当前需要合并的两个分支最近一次相同版本1，没有新版本变化；

（3）而hot-fix分支，相对于当前需要合并的两个分支最近一次相同版本1，没有新版本变化；

（4）结果：不会发生合并。git会提示已经合并过了

#若将master合并到hot-fix分支上面，Git合并流程如下：
（1）Git会比较两个分支的commit记录。

（2）发现master分支，相对于当前需要合并的两个分支最近一次相同版本1，没有新版本变化；

（3）而hot-fix分支，对于当前需要合并的两个分支最近一次相同版本1，没有新版本变化；

（4）结果：不会发生合并。git会提示已经合并过了

注意：git只会认识commit提交后的项目版本。如果你修改了代码，但是没有commit提交，git会仍然默认你是原来的版本，认为你没有经过任何修改。

情况四：此时在master的基础上，再次进行开发项目，成为实际版本2，但是没有commit提交到本地仓库；此时hot-fix分支也进行项目开发，并提交到本地仓库，成为版本3；

#若将hot-fix合并到master分支上面，Git合并流程如下：
（1）Git会比较两个分支的commit记录。

（2）发现master分支，相对于当前需要合并的两个分支最近一次相同版本1，没有新版本变化；

（3）而hot-fix分支，相对于当前需要合并的两个分支最近一次相同版本1，有新版本变化；

（4）结果：在IDEA中合并会发生，但是会失败。因为你master中间代码没有提交，IDEA为了防止覆盖你的代码，所以会拒绝自动合并。
	但是在git命令执行中，就不太清楚了。读者可以试一试（master分支代码，应该会被直接覆盖合并为hot-fix的版本代码）。

IDEA提示如下所示：

#若将master合并到hot-fix分支上面，Git合并流程如下：
（1）Git会比较两个分支的commit记录。

（2）发现master分支，相对于当前需要合并的两个分支最近一次相同版本1，没有新版本变化；

（3）而hot-fix分支，对于当前需要合并的两个分支最近一次相同版本1，有新版本变化；

（4）结果：IDEA中不会发生合并。在你强制切换分支的时候，未提交代码会丢失。然后git会提示已经合并过了。

IDEA提示如下，切换分支时，会出现如下提示。

三·为什么Git要先commit，再pull，最后才push？而不能直接commit，再push。

答：这个先 commit 再 pull 最后再push 的情况就是为了应对多人合并开发的情况,

（1）commit 是为了告诉 git 我这次提交改了哪些东西,不然你只是改了但是 git 不知道你改了,也就无从判断比较;

（2）pull的本质就是合并本地分支与远程分支；但是多人开发的时候，你永远不知道别人有没有在你前面提交一个新版本。因此每次推送前，需要pull一下远程分支，若有冲突，就需要解决冲突。（解决完冲突，会自动合并提交为一个新版本到本地仓库）此时，需要再拉取一下远程分支，防止在你处理冲突的过程中，又有人提交新版本。直到你本地仓库的commit记录中有合并过远程仓库的当前版本，才可以执行push推送。不然都会被远程仓库拒绝推送的，并提示你拉取最新代码且解决冲突。不信你就可以去试试！！！

（3）当本地分支版本与远程分支版本之间，不存在相同版本记录的时候，就无法推送到远程给仓库。（这种情况相当于就是两个不同类型的项目合并，没有任何实际意义）

（4）综上所述：多人合作开发项目时且使用同一个远程项目仓库，commit，pull，push这个执行顺序不能乱，不然就会出现被拒绝推送等各种问题。

（5）若你只是单纯使用个人远程仓库，那就可以直接commit，再push就ok了