Skip to content

0821对git的学习

ziyouzy edited this page Aug 21, 2020 · 2 revisions

对纯粹的git的学习,目前还没有掌握的是进行(递交)commit操作时,对于分支之间冲突如何处理,以及在某些场景之下,为何需要修改递交信息

文章中提到:

git冲突的场景

情景一:多个分支代码合并到一个分支时;
情景二:多个分支向同一个远端分支推送代码时;
实际上,push操作即是将本地代码merge到远端库分支上。

关于push和pull其实就分别是用本地分支合并到远程分支 和 将远程分支合并到本地分支

所以这两个过程中也可能存在冲突。

git的合并中产生冲突的具体情况:

  <1>两个分支中修改了同一个文件(不管什么地方)   <2>两个分支中修改了同一个文件的名称 两个分支中分别修改了不同文件中的部分,不会产生冲突,可以直接将两部分合并。

由此可以总结出,冲突是基于某个源文件产生的,如xxx.cpp或yy.go,而不是源文件中的某一行

如果不存在分支,而是"一条路(master)走到黑"则不会存在冲突

当基于master开发出分支a后,基于分支设计出了新的版本,再回到分支起点,创建了分支b,只要分支a没有合并过,则也不会存在冲突的可能

而当基于分支b诞生了新的版本,又基于分支b的这个新版本与master合并了,当这一时刻,首先相当于分支b消失了

合并后回到分支a,然分支a也去与master进行合并,则在此刻很可能会发成冲突

文章中对冲突场景的说明:

本地库中两个不同分支,修改同一个文件同一代码块,两分支先后将修改合并到master分支上,master在合并第二个分支代码时,报错:合并冲突。

冲突一定是基于这种所存在的“合并的先后顺序”而诞生的

冲突其实也相当于隐式的让程序员强行遵守了“最为正确,也是最核心的合并规则”

其实主流用法一般不会涉及到两个子分支之间的合并,但是无论是否允许,抖不妨碍这一核心规则

分支的合并必然伴随某个分支的消失,如子分支合并到主分支,则子分支消失,如两个子分支合并在一起,在逻辑上相当于两个子分支都消失,同时诞生一个新分支

这里探讨一个极端的情况,如果同时存在三个子分支,让他们合并,则先会合并a与b,这里也是可能发生冲突,因为这虽然属于当前事件节点的第一次合并,但是依然会存在两个分支同时修改了某一个源文件的情况,一旦这种情况发生,那么就会产生冲突,将这次冲突解决后,当再去与c合并时,如过c也修改了同样的源文件,则还是会重蹈负责。

所以说,合并虽然存在时间层面的先后顺序,但是这先后顺序并不是很重要,重要的是当某个节点,无论是第一次还是第n次,无论是否设计到与主线的合并,只要两个分支涉及到修改了同一个源文件或者文件名,就会产生冲突

冲突其实也是git的精髓所在,让整体流程虽然可以实现多重,平行的线性发展,但也保证了整体进程每个节点的原子性

20200821-12:14以通过亲身实践验证了即使是master分支与子分支之间,依然会遵循这一规则,如违背依然会产生冲突

Clone this wiki locally