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

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

  • 一·Git合并分支底层原理:
    • (1)分别比较两个分支提交的commit记录(即,分支的版本记录):会优先进行
    • (2)当两个分支的commit记录都有新变化。Git就会在当前分支项目中,进行逐行比较代码。若是没有冲突就会直接合并。有冲突就会提示你,让你解决冲突。解决冲突之后就会直接合并。(一般都会产生冲突)
  • 二·各种情况下合并分支流程演示:举例演示说明
    • 演示前提:
      • 1.假如当前本地存在一个项目P,当前分支为master,且当前初始版本为1;
      • 2.此时在当前项目的master分支上,创建一个新分支hot-fix,且版本也为1;
    • 情况一:此时在master的基础上,再次进行开发项目,并提交到本地仓库,成为版本2;此时hot-fix分支还处于版本1;
    • 情况二:此时在master的基础上,再次进行开发项目,并提交到本地仓库,成为版本2;此时hot-fix分支也进行开发,成为版本3,或者版本5,6,7等任何版本;
    • 情况三:此时在master的基础上,再次进行开发项目,成为实际版本2,但是没有commit提交到本地仓库;此时hot-fix分支仍然处于版本1;
    • 情况四:此时在master的基础上,再次进行开发项目,成为实际版本2,但是没有commit提交到本地仓库;此时hot-fix分支也进行项目开发,并提交到本地仓库,成为版本3;
  • 三·为什么Git要先commit,再pull,最后才push?而不能直接commit,再push。
    • (1)commit 是为了告诉 git 我这次提交改了哪些东西,不然你只是改了但是 git 不知道你改了,也就无从判断比较;
    • (2)pull的本质就是合并本地分支与远程分支;但是多人开发的时候,你永远不知道别人有没有在你前面提交一个新版本。因此每次推送前,需要pull一下远程分支,若有冲突,就需要解决冲突。(解决完冲突,会自动合并提交为一个新版本到本地仓库)此时,需要再拉取一下远程分支,防止在你处理冲突的过程中,又有人提交新版本。直到你本地仓库的commit记录中有合并过远程仓库的当前版本,才可以执行push推送。不然都会被远程仓库拒绝推送的,并提示你拉取最新代码且解决冲突。不信你就可以去试试!!!
    • (3)当本地分支版本与远程分支版本之间,不存在相同版本记录的时候,就无法推送到远程给仓库。(这种情况相当于就是两个不同类型的项目合并,没有任何实际意义)
    • (4)综上所述:多人合作开发项目时且使用同一个远程项目仓库,commit,pull,push这个执行顺序不能乱,不然就会出现被拒绝推送等各种问题。
    • (5)若你只是单纯使用个人远程仓库,那就可以直接commit,再push就ok了

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

(1)分别比较两个分支提交的commit记录(即,分支的版本记录):会优先进行

#“分别比较两个分支提交的commit记录”详情如下:
	分别将两个分支的commit记录,相对于当前需要合并的两个分支最近一次相同版本记录比较。
	若一个分支有新变化,一个分支没有新变化,则有新变化的分支直接胜出。
	此时,若两个分支合并,合并结果就是有新变化的那个分支内容,另外一个分支的内容会直接忽略掉。

(2)当两个分支的commit记录都有新变化。Git就会在当前分支项目中,进行逐行比较代码。若是没有冲突就会直接合并。有冲突就会提示你,让你解决冲突。解决冲突之后就会直接合并。(一般都会产生冲突)

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

如图所示:commit记录
总结:全网最详细,Git分支合并、项目推拉的底层核心原理解析,看完不会你找我。_第1张图片

演示前提:

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提示如下所示:
总结:全网最详细,Git分支合并、项目推拉的底层核心原理解析,看完不会你找我。_第2张图片

#若将master合并到hot-fix分支上面,Git合并流程如下:
(1)Git会比较两个分支的commit记录。

(2)发现master分支,相对于当前需要合并的两个分支最近一次相同版本1,没有新版本变化;

(3)而hot-fix分支,对于当前需要合并的两个分支最近一次相同版本1,有新版本变化;

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

IDEA提示如下,切换分支时,会出现如下提示。
总结:全网最详细,Git分支合并、项目推拉的底层核心原理解析,看完不会你找我。_第3张图片

三·为什么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了

你可能感兴趣的:(总结,git,git,merge,pull,push,git底层原理,git合并分支)