CN114237688A - 分支版本合并方法、装置、系统及电子设备 - Google Patents
分支版本合并方法、装置、系统及电子设备 Download PDFInfo
- Publication number
- CN114237688A CN114237688A CN202111480768.XA CN202111480768A CN114237688A CN 114237688 A CN114237688 A CN 114237688A CN 202111480768 A CN202111480768 A CN 202111480768A CN 114237688 A CN114237688 A CN 114237688A
- Authority
- CN
- China
- Prior art keywords
- version
- branch
- target
- merged
- file
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/71—Version control; Configuration management
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
本申请提供了一种分支版本合并方法、装置、系统及电子设备,该方法应用于服务端,服务端与版本管理服务器连接;接收用户的分支合并请求;将请求中的目标版本号和目标分支号发送至版本管理服务器,以使版本管理服务器确定第一分支下的第一待合并版本文件和第二分支下的第二待合并版本文件;其中,合并方向为从第一分支到第二分支;接收版本管理服务器返回的第二待合并版本文件的标识,基于该标识创建目标仓库;在目标仓库中进行第一待合并版本文件和第二待合并版本文件的合并操作,得到目标合并版本文件;将目标合并版本文件发送至版本管理服务器。本申请提供的合并方法,学习成本低、操作简单、不会漏提交、发生冲突时不会阻塞其它合并操作。
Description
技术领域
本申请涉及软件技术领域,尤其是涉及一种分支版本合并方法、装置、系统及电子设备。
背景技术
当前的项目研发流程中,为保留里程碑版本或开发大型独立功能,往往会采用分支策略。在分支策略中,分支合并操作可以实现不同分支间代码的同步,是必不可少的一环。在一些大型的项目中,每天都会产生成百上千次的分支合并,如何提升合并效率,妥善处理合并产生的版本冲突,是一个非常有价值的研究课题。
现有技术中,分支合并方案有以下3种(以通过SVN实现从分支A合并到分支B为例进行说明,SVN是subversion的缩写,是一个开放源代码的版本控制系统,即版本管理服务器):
1.使用SVN图形化merge工具:在分支B需要merge的目录下,使用SVN merge功能,并查询分支A需要被merge内容提交的版本号,merge成功后,在目录下勾选被merge的文件提交至分支B的远程仓库。
2.直接在文件系统层面操作,删除分支B需要merge的目录下的所有文件,并拷贝分支A中的文件到目录下,完成后再提交至分支B的远程仓库。
3.在某一工具服务器上拉取完整的分支B的仓库,根据版本号使用SVN命令行工具根据版本号从分支A进行merge,在分支B上完成merge操作后进行提交。
对于方案1:操作步骤复杂,容易出现误操作,非技术岗同学学习成本高。查询版本号时回溯仓库内所有提交,耗时很长,且merge成功后无法自动定位修改文件,commit阶段容易出现漏提交。
对于方案2:本质上是一种”双端提交”的策略,使用后分支的版本将无法对齐,版本号自带merge功能将无法使用,造成问题时难以回溯。进一步地,由于存在”删除”操作,流程上若出现不规范容易导致文件被错误覆盖,且对于资源量较大的仓库,整个流程执行时间比较长,效率低。
对于方案3:完整仓库定位版本号时耗时较长,且一旦发生版本冲突,会导致其他的merge的操作也无法正常进行,造成流程阻塞。
综上,现有的分支合并方式,存在学习成本高、操作繁琐、耗时长、容易漏提交、发生冲突时会阻塞其它合并操作的技术问题。
发明内容
本申请的目的在于提供一种分支版本合并方法、装置、系统及电子设备,以解决上述技术问题。
第一方面,本申请实施例提供一种分支版本合并方法,该方法应用于服务端,服务端与版本管理服务器连接;版本管理服务器包括多个分支;每个分支包括至少一个版本文件;方法包括:接收用户的分支合并请求;分支合并请求中携带有目标版本号和目标分支号;将目标版本号和目标分支号发送至版本管理服务器,以使版本管理服务器根据目标版本号和目标分支号,确定第一分支下的第一待合并版本文件和第二分支下的第二待合并版本文件;其中,合并方向为从第一分支到第二分支;接收版本管理服务器返回的所述第二待合并版本文件的标识,基于第二待合并版本文件的标识创建目标仓库;在目标仓库中进行第一待合并版本文件和第二待合并版本文件的合并操作,得到目标合并版本文件;将目标合并版本文件发送至版本管理服务器。
进一步的,上述将目标版本号和目标分支号发送至版本管理服务器,以使版本管理服务器根据目标版本号和目标分支号,确定第一分支下的第一待合并版本文件和第二分支下的第二待合并版本文件的步骤,包括:将所述目标版本号和所述目标分支号发送至所述版本管理服务器,以使所述版本管理服务器根据目标版本号,查找对应的版本提交信息;版本提交信息包括:指定分支号、第一版本文件和第二版本文件;第二版本文件为在第一版本文件基础上进行修改得到的新版本文件;将指定分支号对应的第二版本文件确定为第一分支下的第一待合并版本文件;将目标分支号对应的分支确定为第二分支;在第二分支对应的版本文件中查找与第一版本文件相同的文件,将查找到的文件作为第二分支下的第二待合并版本文件。
进一步的,上述基于第二待合并版本文件的标识创建目标仓库的步骤,包括:根据所述第二待合并版本文件的标识,从版本管理服务器拉取第二待合并版本文件;生成包含第二待合并版本文件的目标仓库。
进一步的,上述在目标仓库中进行第一待合并版本文件和第二待合并版本文件的合并操作,得到目标合并版本文件的步骤,包括:接收版本管理服务器根据版本提交信息,返回的第一待合并版本文件对应的修改信息;基于修改信息在目标仓库中对第二待合并版本文件进行合并操作,得到目标合并版本文件。
进一步的,上述在将目标合并版本文件发送至版本管理服务器的步骤之后,方法还包括:删除目标仓库。
进一步的,上述服务端还与终端设备连接;终端设备安装有智能聊天工具;接收用户的分支合并请求的步骤,包括:接收终端设备发送的分支合并请求;分支合并请求为用户在终端设备的界面上输入的基于目标版本号的分支合并指令。
进一步的,上述在目标仓库中进行第一待合并版本文件和第二待合并版本文件的合并操作,得到目标合并版本文件的步骤之后,方法还包括:向终端设备发送分支合并成功的第一提示信息,以使终端设备向用户显示第一提示信息。
进一步的,上述方法还包括:如果未接收到版本管理服务器返回的待合并版本文件的标识,或者,在目标仓库中进行第一待合并版本文件和第二待合并版本文件的合并操作出现冲突时,向终端设备发送分支合并失败的第二提示信息,以使终端设备向用户显示第二提示信息。
进一步的,上述第二提示信息还至少包括以下之一:分支合并失败原因、需手动处理提示信息、处理人信息和冲突文件。
第二方面,本申请实施例还提供一种分支版本合并方法,方法应用于版本管理服务器,版本管理服务器与服务端连接;版本管理服务器包括多个分支;每个分支包括至少一个版本文件;方法包括:接收服务端发送的目标版本号和目标分支号;根据目标版本号和目标分支号,确定第一分支下的第一待合并版本文件和第二分支下的第二待合并版本文件;其中,合并方向为从第一分支到第二分支;向服务端发送第二待合并版本文件的标识,以使服务端基于第二待合并版本文件的标识创建目标仓库;在目标仓库中进行第一待合并版本文件和第二待合并版本文件的合并操作,得到目标合并版本文件;接收服务端发送的目标合并版本文件。
进一步的,上述根据目标版本号和目标分支号,确定待合并版本文件的步骤,包括:根据目标版本号,查找对应的版本提交信息;版本提交信息包括:指定分支号、第一版本文件和第二版本文件;第二版本文件为在第一版本文件基础上进行修改得到的新版本文件;将指定分支号对应的第二版本文件确定为第一分支下的第一待合并版本文件;将目标分支号对应的分支确定为第二分支;在第二分支对应的版本文件中查找与第一版本文件相同的文件,将查找到的文件作为第二分支下的第二待合并版本文件。
进一步的,上述每个分支对应有目录结构;在第二分支对应的版本文件中查找与第一版本文件相同的文件的步骤,包括:确定第一版本文件在第一分支下的第一目录结构中的第一存储路径;在第二分支下的第二目录结构中查找与第一存储路径相同的第二存储路径;将第二存储路径对应的版本文件确定为与第一版本文件相同的文件。
第三方面,本申请实施例还提供一种分支版本合并装置,装置应用于服务端,服务端与版本管理服务器连接;版本管理服务器包括多个分支;每个分支包括至少一个版本文件;装置包括:请求接收模块,用于接收用户的分支合并请求;分支合并请求中携带有目标版本号和目标分支号;请求发送模块,用于将目标版本号和目标分支号发送至版本管理服务器,以使版本管理服务器确定第一分支下的第一待合并版本文件和第二分支下的第二待合并版本文件;其中,合并方向为从第一分支到第二分支;仓库创建模块,用于接收版本管理服务器返回的第二待合并版本文件的标识,基于第二待合并版本文件的标识创建目标仓库;分支合并模块,用于在目标仓库中进行第一待合并版本文件和第二待合并版本文件的合并操作,得到目标合并版本文件;版本文件发送模块,用于将目标合并版本文件发送至版本管理服务器。
第四方面,本申请实施例还提供一种分支版本合并装置,装置应用于版本管理服务器,版本管理服务器与服务端连接;版本管理服务器包括多个分支;每个分支包括至少一个版本文件;装置包括:信息接收模块,用于接收服务端发送的目标版本号和目标分支号;文件确定模块,用于根据目标版本号和目标分支号,确定第一分支下的第一待合并版本文件和第二分支下的第二待合并版本文件;其中,合并方向为从第一分支到第二分支;信息发送模块,用于向服务端发送第二待合并版本文件的标识,以使服务端基于第二待合并版本文件的标识创建目标仓库;在目标仓库中进行第一待合并版本文件和第二待合并版本文件的合并操作,得到目标合并版本文件;文件接收模块,用于接收服务端发送的目标合并版本文件。
第五方面,本申请实施例还提供一种分支版本合并系统,系统包括:版本管理服务器、终端设备和服务端;终端设备安装有智能聊天工具;服务端分别与终端设备和版本管理服务器连接;服务端用于执行如第一方面所述的方法;版本管理服务器用于执行如第二方面所述的方法。
第六方面,本申请实施例还提供一种电子设备,包括处理器和存储器,存储器存储有能够被处理器执行的计算机可执行指令,处理器执行计算机可执行指令以实现上述第一方面或第二方面所述的方法。
第七方面,本申请实施例还提供一种计算机可读存储介质,计算机可读存储介质存储有计算机可执行指令,计算机可执行指令在被处理器调用和执行时,计算机可执行指令促使处理器实现上述第一方面或第二方面所述的方法。
本申请实施例提供的分支版本合并方法、装置、系统及电子设备中,该方法应用于服务端,服务端与版本管理服务器连接;版本管理服务器包括多个分支;每个分支包括至少一个版本文件;方法包括:接收用户的分支合并请求;分支合并请求中携带有目标版本号和目标分支号;将目标版本号和目标分支号发送至版本管理服务器,以使版本管理服务器根据目标版本号和目标分支号,确定第一分支下的第一待合并版本文件和第二分支下的第二待合并版本文件;其中,合并方向为从第一分支到第二分支;接收版本管理服务器返回的第二待合并版本文件的标识,基于第二待合并版本文件的标识创建目标仓库;在目标仓库中进行第一待合并版本文件和第二待合并版本文件的合并操作,得到目标合并版本文件;将目标合并版本文件发送至版本管理服务器。本申请实施例中,用户只需要发起一个请求,服务端就会通过版本管理服务器自动根据请求中的信息定位到要合并的两个版本文件,然后对第二待合并版本文件创建一个目标仓库,由于该目标仓库中只包含第二待合并版本文件,文件数量相对少,可以称为稀疏仓库,通过该目标仓库可以隔离其他请求,也就是此次合并成功与否不会影响到其他的请求的合并操作,因此,上述合并方法对于用户来说,学习成本低、操作简单,而且可以将稀疏仓库中的文件全数提交至版本管理服务器,不会出现漏提交。
附图说明
为了更清楚地说明本申请具体实施方式或现有技术中的技术方案,下面将对具体实施方式或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图是本申请的一些实施方式,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1为本申请实施例提供的一种分支版本合并方法的流程图;
图2为本申请实施例提供的另一种分支版本合并方法的流程图;
图3为本申请实施例提供的一种请求发起示意图;
图4为本申请实施例提供的一种“稀疏仓库”示意图;
图5为本申请实施例提供的另一种分支版本合并流程示意图;
图6为本申请实施例提供的一种第一提示信息示意图;
图7为本申请实施例提供的一种第二提示信息示意图;
图8为本申请实施例提供的另一种分支版本合并方法的流程图;
图9为本申请实施例提供的一种分支版本合并装置的结构框图;
图10为本申请实施例提供的另一种分支版本合并装置的结构框图;
图11为本申请实施例提供的一种分支版本合并系统的结构框图;
图12为本申请实施例提供的一种电子设备的结构示意图。
具体实施方式
下面将结合实施例对本申请的技术方案进行清楚、完整地描述,显然,所描述的实施例是本申请一部分实施例,而不是全部的实施例。基于本申请中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本申请保护的范围。
在项目开发场景中,开发人员通常会从版本管理服务器的某个分支中拉取某个版本文件作为初始文件,然后在该初始文件的基础上进行修改提交,在提交成功后会收到版本管理服务器下发的版本号Revision,对于同一个仓库内的不同分支,共用一套版本号体系,即版本号可以在所有分支中定位到某次特定提交。因此,可以通过上述下发的版本号,获取到这次提交对应的版本提交信息,包括提交到哪个分支,初始文件是哪个,修改后的文件是哪个。
在上述提交版本文件后,为了使其他相关人员也能查阅或应用该版本文件,往往需要将该版本文件同步到其他分支中,也就是需要进行分支合并操作,现有技术中,通常有以下三种合并方式,以通过SVN实现从分支A合并到分支B为例进行说明:
1.使用SVN图形化merge工具:在分支B需要merge的目录下,使用SVN merge功能,并查询分支A需要被merge内容提交的版本号,merge成功后,在目录下勾选被merge的文件提交至分支B的远程仓库。这种方式操作步骤复杂,容易出现误操作,非技术岗同学学习成本高。查询版本号时回溯仓库内所有提交,耗时很长,且merge成功后无法自动定位修改文件,commit阶段容易出现漏提交。
2.直接在文件系统层面操作,删除分支B需要merge的目录下的所有文件,并拷贝分支A中的文件到目录下,完成后再提交至分支B的远程仓库。这种方案本质上是一种”双端提交”的策略,使用后分支的版本将无法对齐,版本号自带merge功能将无法使用,造成问题时难以回溯。进一步地,由于存在”删除”操作,流程上若出现不规范容易导致文件被错误覆盖,且对于资源量较大的仓库,整个流程执行时间比较长,效率低。
3.在某一版本管理服务器上拉取完整的分支B的仓库,根据版本号使用SVN命令行工具根据版本号从分支A进行merge,在分支B上完成merge操作后进行提交。这种方式中,通过完整仓库定位版本号耗时较长,且一旦发生版本冲突,会导致其他的merge的操作也无法正常进行,造成流程阻塞。
综上,现有的分支合并方式,存在学习成本高、操作繁琐、耗时长、容易漏提交、发生冲突时会阻塞其它合并操作的技术问题。
基于此,本申请实施例提供一种分支版本合并方法、装置、系统及电子设备,以解决上述技术问题。
为便于对本实施例进行理解,首先对本申请实施例所公开的一种分支版本合并方法进行详细介绍。本申请实施例中,针对上述现有分支合并方式中存在的学习成本高、操作繁琐、耗时长、容易漏提交、发生冲突时会阻塞其它合并操作等技术问题,提供了一种学习成本低、操作简单,分支版本合并效率高的分支版本合并方法,能够避免发生版本冲突问题,并且不会造成漏提交。该方法应用于服务端,服务端与版本管理服务器连接;版本管理服务器也就是版本管理工具,在软件开发过程中,管理多人协作的文件版本管理软件工具,包括但不限于SVN,Git。版本管理服务器包括多个分支;每个分支包括至少一个版本文件。图1示出了本申请实施例提供的一种分支版本合并方法的流程图,该方法具体包括以下步骤:
步骤S102,接收用户的分支合并请求;分支合并请求中携带有目标版本号和目标分支号。
上述分支合并请求可以通过多种方式发起,比如,在IM机器人界面中输入分支合并指令,如包含有目标版本号和目标分支号和合并指令,或者可以通过安装有特定智能聊天工具的终端设备上,输入包含有目标版本号和目标分支号和合并指令,也可以向服务端发起分支合并请求。
在一个版本管理服务器中,共用一套版本号,即在同一个仓库中,不同分支中的版本文件对应的版本号均是唯一确定的,因此,版本管理服务器可以根据上述目标版本号精准定位到一次版本提交信息。通过上述目标分支号可以确定出这次版本提交想要合并的分支是哪个分支。
步骤S104,将目标版本号和目标分支号发送至版本管理服务器,以使版本管理服务器确定第一分支下的第一待合并版本文件和第二分支下的第二待合并版本文件;其中,合并方向为从第一分支到第二分支。
具体实施过程中,服务端在接收到请求后,会将目标版本号和目标分支号发送给版本管理服务器,版本管理服务器可以先根据目标版本号确定出对应的版本提交信息;如前所述,该信息中可以包括提交到的指定分支号,第一版本文件和第二版本文件;其中,第一版本文件也就是前述的初始文件,第二版本文件也就是前述的在初始文件基础上修改后的文件。进一步,可以确定指定分支号下的第二版本文件就是第一分支下的第一待合并版本文件。然后根据上述版本提交信息和目标分支号,还可以确定出第二分支下的第二待合并版本文件,第二分支也就是目标分支号对应的分支,也就是用户想要合并的目标分支,确定出的第二待合并版本文件与第一待合并版本文件是完全对应的,比如,第一待合并版本文件中有三个文件,确定出的第二待合并版本文件中也包含三个文件。也就是说,一次提交中可能会包括多个文件,多个文件在本申请实施例中统称第一待合并版本文件。
步骤S106,接收版本管理服务器返回的第二待合并版本文件的标识,基于第二待合并版本文件的标识创建目标仓库。
通常来说,单次合并操作对应的文件数量是较少的,如1-10个之内,因此,基于第二待合并版本文件的标识拉取第二待合并版本文件,并创建的目标仓库中文件数量也就较少,在本申请实施例中,可以将目标仓库称为“稀疏仓库”,表示该仓库中的文件数量较少。创建目标仓库可以通过服务端中对应的命令进行文件拉取而实现,在此不再赘述。
步骤S108,在目标仓库中进行第一待合并版本文件和第二待合并版本文件的合并操作,得到目标合并版本文件。
在上述创建的“稀疏仓库”中进行第一待合并版本文件和第二待合并版本文件的合并操作,可以得到目标合并版本文件,该目标合并版本文件也就是将第一待合并版本文件同步到第二分支中的结果。
步骤S110,将目标合并版本文件发送至版本管理服务器。也就是将目标合并版本文件提交到远端仓库中,完成该次版本文件合并过程。
本申请实施例提供的分支版本合并方法中,用户只需要发起一个请求,服务端就会通过版本管理服务器自动根据请求中的信息定位到要合并的两个版本文件,然后对第二待合并版本文件创建一个目标仓库,由于该目标仓库中只包含第二待合并版本文件,文件数量相对少,可以称为“稀疏仓库”,通过该仓库可以隔离其他请求,也就是此次合并成功与否不会影响到其他的请求的合并操作,因此,上述合并方法对于用户来说,学习成本低、操作简单,而且可以将稀疏仓库中的文件全数提交至版本管理服务器,不会出现漏提交。
本申请实施例还提供另一种分支版本合并方法,该方法在上述实施例的基础上实现;本实施例重点描述请求发起过程、待合并的版本文件确定过程以及“稀疏仓库”的生成过程。
参见图2所示的一种分支版本合并方法的流程图,本方法中的终端设备以IM机器人为例进行说明,该方法包括以下步骤:
步骤S202,接收终端设备发送的分支合并请求;分支合并请求为用户在终端设备的界面上输入的基于目标版本号的分支合并指令。
上述终端设备与服务端连接;终端设备上安装有智能聊天工具,通过该工具可以向服务端发送请求。实际应用中,该工具中安装有一个监控消息发送的socket进程,换种方式描述,也就是在聊天群里有一个机器人账号,这个账号可以监控聊天信息,如果锁定到特定关键字,机器人可以向服务端发送指令执行操作。
在本申请实施例中,需要被融合的目标分支通常默认是最新版本分支,因此,用户只需要在终端设备的界面中输入包含目标版本号的分支合并指令即可,如图3所示,分支合并指令为“branch merge 126496”,其中,126496即为目标版本号,这样发起的请求中会自动携带用户输入的目标版本号和默认的分支号。如果用户并不想要和默认的分支进行合并,那也可以输入指令时明确分支号,如:完整的指令形成是:branch merge to20210810at 126496,其中20210810指代需要被融合的分支。
本申请实施例中通过上述机器人发起分支合并请求操作简单,可以大大降低用户的学习成本。
步骤S204,将目标版本号和目标分支号发送至版本管理服务器,以使所述版本管理服务器根据目标版本号,查找对应的版本提交信息;版本提交信息包括:指定分支号、第一版本文件和第二版本文件;第二版本文件为在第一版本文件基础上进行修改得到的新版本文件;将指定分支号对应的第二版本文件确定为第一分支下的第一待合并版本文件;将目标分支号对应的分支确定为第二分支;在第二分支对应的版本文件中查找与第一版本文件相同的文件,将查找到的文件作为第二分支下的第二待合并版本文件。
通过上述目标版本号可以定位到对应的版本提交信息,也就是通过该目标版本号可以获取到这次提交对应的分支,初始文件和修改后的文件,即上述指定分支号、第一版本文件和第二版本文件。
实际应用中,上述每个分支对应有目录结构;在第二分支对应的版本文件中查找与第一版本文件相同的文件的过程可以通过以下方式实现:首先确定第一版本文件在第一分支下的第一目录结构中的第一存储路径;然后在第二分支下的第二目录结构中查找与第一存储路径相同的第二存储路径;最后将第二存储路径对应的版本文件确定为与第一版本文件相同的文件。
步骤S206,根据所述第二待合并版本文件的标识,从版本管理服务器拉取第二待合并版本文件,生成包含第二待合并版本文件的目标仓库。该步骤中,可以实时根据查找到的第二待合并版本文件创建成仓库,具体方法是从版本管理服务器中查询到对应第二待合并版本文件后,直接使用svn co的方式从版本管理服务器拉取文件,从而形成包含第二待合并版本文件的“稀疏仓库”。
对于每次分支合并请求,均可以生成一个独立的“稀疏仓库”。即在服务端上会存在多个“稀疏仓库”,每个仓库内仅存在本次需要的第二待合并版本文件,可以参考图4所示,每个temp_target_(时间戳)文件夹便是一个生成的“稀疏仓库”,由于“稀疏仓库”间相互独立可以在仓库中进行冲突测试,即合并操作而不会影响到其他的合并流程。
步骤S208,接收版本管理服务器根据版本提交信息,返回的第一待合并版本文件对应的修改信息。前述版本提交信息中包括这次提交对应的分支,初始文件和修改后的文件,即指定分支号、第一版本文件和第二版本文件。因此,版本管理服务器可以确定出第二版本文件相对于第一版本文件的修改信息,也即第一待合并版本文件对应的修改信息。
步骤S210,基于修改信息在第一仓库中对第二待合并版本文件进行合并操作,得到目标合并版本文件。
合并的过程实际是服务端自带的功能,通过merge指令就可以通过上述修改信息在上述“稀疏仓库”中对第二待合并版本文件完成合并操作,得到目标合并版本文件。
本申请实施例提供的一种分支版本合并方法,是一套以“稀疏仓库”为核心的merge方案,使用“稀疏仓库”进行merge操作,和原有的大仓库不同,“稀疏仓库”具有以下特征:无需提前部署,根据用户提交的revision自动定位需要merge的版本文件并形成仓库;单个仓库内文件数量少(一般低于10个),可以支持实时创建;一次merge生成一个“稀疏仓库”,不同的“稀疏仓库”间环境隔离,不会影响其他的合并流程。
本申请实施例还提供另一种分支版本合并方法,该方法在上述实施例的基础上实现;本实施例重点描述合并结果的展示过程。
下面以基于“稀疏仓库”和SVN的由分支A向分支B的合并为例进行详细说明:
参见图5所示的合并流程示意图:工具服务器即为前述服务端;远端仓库即为前述版本管理服务器;信息采集机器人即为前述安装有智能聊天工具的终端设备。
①Merge请求发起:为降低使用者学习成本,本申请实施例中用户在机器人界面中输入版本号自动发起merge请求,使用者只需要输入待merge的revision即可开启merge流程。具体过程可参见前述步骤S202。
②merge文件定位,根据上一步中的revision,通过命令行工具svn log可以精确定位到这次提交中分支A需要merge的版本文件,同时通过相对路径转换,可以获得分支B中待merge的版本文件。具体过程可参考前述步骤S204-S208,在此不再赘述。
③创建“稀疏仓库”,可参见前述步骤S210的内容。
④冲突测试,也就是在“稀疏仓库”中进行合并操作的过程,如果不发生冲突,则在仓库成功完成merge后全量提交稀疏仓库(由于“稀疏仓库”中只有与本次merge关联的版本文件,全量提交即可,不会产生错提或漏提),并在完成后将“稀疏仓库”删除。
也就是上述在目标仓库中进行第一待合并版本文件和第二待合并版本文件的合并操作,得到目标合并版本文件的步骤之后,服务端还会将目标合并版本文件发送至版本管理服务器,并删除目标仓库,即“稀疏仓库”。这样可以在分支合并成功后,将目标仓库中的所有文件全量提交到版本管理服务器中,不会造成文件遗漏或错交。
若发生冲突,则在“稀疏仓库”内保留冲突现场用于回溯,并阻断提交。同时,无论冲突与否,都会将merge信息通过机器人返回给用户,以使用户第一时间处理问题,即Merge情况会通过信息采集机器人向使用者同步。具体的实现步骤如下:
为了使用户及时了解分支合并情况,本申请实施例操作的方法,在还目标仓库中进行第一待合并版本文件和第二待合并版本文件的合并操作,得到目标合并版本文件的步骤之后,还可以包括以下步骤:向终端设备发送分支合并成功的第一提示信息,以使终端设备向用户显示第一提示信息。如图6所示,在用户发送分支合并请求后,如果想到合并的目标分支此时正在执行合并操作过程,则会收到反馈机器人回复的该指令会加队列进行排队的信息,如果该用户的分支合并成功后,会收到反馈机器人回复的合并成功信息。
另一方面,如果根据目标版本号和目标分支号,未确定出第二分支下的第二待合并版本文件,或者,在目标仓库中进行第一待合并版本文件和第二待合并版本文件的合并操作出现冲突时,向终端设备发送分支合并失败的第二提示信息,以使终端设备向用户显示第二提示信息。在一种优选方式中,上述第二提示信息还至少包括以下之一:分支合并失败原因、需手动处理提示信息、处理人信息和冲突文件。
如图7所示,如在“稀疏仓库”内进行合并操作时发生冲突,保留冲突现场用于回溯,并阻断提交,同时,将分支合并情况信息,如:出现冲突,请手动处理的提示信息,以及冲突文件、处理人信息等,通过机器人反馈给用户,以使用户第一时间处理问题。
本申请实施例提供的分支版本合并方案,与原有的大仓库方案相比,“稀疏仓库”可以带来以下优点:
1)“稀疏仓库”实时生成,使用者不需要预先拉取仓库,工具部署成本和部署时间大幅缩短;
2)所有merge请求隔离处理,单次merge冲突不会阻碍其他merge流程;
3)“稀疏仓库”可用于merge测试,一旦发生冲突可以保留现场并定位到对应的操作人进行处理。成功则直接提交并删除本地“稀疏仓库”,不消耗额外硬盘空间;
4)在svn版本控制框架内进行merge,可以回溯所有提交和merge记录,且兼容图形化工具操作方案,在冲突发生时可以直接转人工处理;
5)由于”稀疏仓库”内仅保留当次merge对应的文件,merge完成后可以全量提交相应的”稀疏仓库”,杜绝漏提交或错提交的发生。
本申请实施例还提供另一种分支版本合并方法,该方法在版本管理服务器一端实现,参见图8所示,具体包括以下步骤:
步骤S802,接收服务端发送的目标版本号和目标分支号;
步骤S804,根据目标版本号和目标分支号,确定第一分支下的第一待合并版本文件和第二分支下的第二待合并版本文件;其中,合并方向为从第一分支到第二分支。
具体实施时,可通过以下步骤实现:
(1)根据目标版本号,查找对应的版本提交信息;版本提交信息包括:指定分支号、第一版本文件和第二版本文件;第二版本文件为在第一版本文件基础上进行修改得到的新版本文件;
(2)将指定分支号对应的第二版本文件确定为第一分支下的第一待合并版本文件;
(3)将目标分支号对应的分支确定为第二分支;
(4)在第二分支对应的版本文件中查找与第一版本文件相同的文件,将查找到的文件作为第二分支下的第二待合并版本文件。
进一步的,上述每个分支对应有目录结构;在第二分支对应的版本文件中查找与第一版本文件相同的文件的步骤,包括:确定第一版本文件在第一分支下的第一目录结构中的第一存储路径;在第二分支下的第二目录结构中查找与第一存储路径相同的第二存储路径;将第二存储路径对应的版本文件确定为与第一版本文件相同的文件。
步骤S806,向服务端发送第二待合并版本文件的标识,以使服务端基于第二待合并版本文件的标识创建目标仓库;在目标仓库中进行第一待合并版本文件和第二待合并版本文件的合并操作,得到目标合并版本文件;
步骤S808,接收服务端发送的目标合并版本文件。
本申请实施例提供的方法与前述服务端方法类似,未提及内容可参见前述实施例部分,在此不再赘述。
基于上述方法实施例,本申请实施例还提供一种分支版本合并装置,装置应用于服务端,服务端与版本管理服务器连接;版本管理服务器包括多个分支;每个分支包括至少一个版本文件;参见图9所示,该装置包括:
请求接收模块902,用于接收用户的分支合并请求;分支合并请求中携带有目标版本号和目标分支号;请求发送模块904,用于将目标版本号和目标分支号发送至版本管理服务器,以使版本管理服务器确定第一分支下的第一待合并版本文件和第二分支下的第二待合并版本文件;其中,合并方向为从第一分支到第二分支;仓库创建模块906,用于接收版本管理服务器返回的第二待合并版本文件的标识,基于第二待合并版本文件的标识创建目标仓库;分支合并模块908,用于在目标仓库中进行第一待合并版本文件和第二待合并版本文件的合并操作,得到目标合并版本文件;版本文件发送模块910,用于将目标合并版本文件发送至版本管理服务器。
上述请求发送模块904,还用于将目标版本号和目标分支号发送至版本管理服务器,以使版本管理服务器根据目标版本号,查找对应的版本提交信息;版本提交信息包括:指定分支号、第一版本文件和第二版本文件;第二版本文件为在第一版本文件基础上进行修改得到的新版本文件;将指定分支号对应的第二版本文件确定为第一分支下的第一待合并版本文件;将目标分支号对应的分支确定为第二分支;在第二分支对应的版本文件中查找与第一版本文件相同的文件,将查找到的文件作为第二分支下的第二待合并版本文件。
上述仓库创建模块906,还用于根据第二待合并版本文件的标识从版本管理服务器拉取第二待合并版本文件,生成包含第二待合并版本文件的目标仓库。
上述分支合并模块908,用于还接收版本管理服务器根据版本提交信息,返回的第一待合并版本文件对应的修改信息;基于修改信息在目标仓库中对第二待合并版本文件进行合并操作,得到目标合并版本文件。
上述装置还包括:仓库删除模块,用于在将目标合并版本文件发送至版本管理服务器的步骤之后,删除目标仓库。
上述服务端还与终端设备连接;终端设备安装有智能聊天工具;上述请求接收模块902,用于接收终端设备发送的分支合并请求;分支合并请求为用户在终端设备的界面上输入的基于目标版本号的分支合并指令。
上述装置还包括:信息发送模块,用于在目标仓库中进行第一待合并版本文件和第二待合并版本文件的合并操作,得到目标合并版本文件的步骤之后,向终端设备发送分支合并成功的第一提示信息,以使终端设备向用户显示第一提示信息。
上述信息发送模块,还用于如果根据目标版本号和目标分支号,未接收到版本管理服务器返回的待合并版本文件的标识,或者,在目标仓库中进行第一待合并版本文件和第二待合并版本文件的合并操作出现冲突时,向终端设备发送分支合并失败的第二提示信息,以使终端设备向用户显示第二提示信息。
上述第二提示信息还至少包括以下之一:分支合并失败原因、需手动处理提示信息、处理人信息和冲突文件。
本申请实施例提供的分支版本合并装置,其实现原理及产生的技术效果和前述方法实施例相同,为简要描述,装置的实施例部分未提及之处,可参考前述分支版本合并方法实施例中相应内容。
基于上述方法实施例,本申请实施例还提供一种分支版本合并装置,装置应用于版本管理服务器,版本管理服务器与服务端连接;版本管理服务器包括多个分支;每个分支包括至少一个版本文件;参见图10所示,装置包括:
信息接收模块102,用于接收服务端发送的目标版本号和目标分支号;文件确定模块104,用于根据目标版本号和目标分支号,确定第一分支下的第一待合并版本文件和第二分支下的第二待合并版本文件;其中,合并方向为从第一分支到第二分支;信息发送模块106,用于向服务端发送第二待合并版本文件的标识,以使服务端基于第二待合并版本文件的标识创建目标仓库;在目标仓库中进行第一待合并版本文件和第二待合并版本文件的合并操作,得到目标合并版本文件;文件接收模块108,用于接收服务端发送的目标合并版本文件。
上述文件确定模块104,用于根据目标版本号,查找对应的版本提交信息;版本提交信息包括:指定分支号、第一版本文件和第二版本文件;第二版本文件为在第一版本文件基础上进行修改得到的新版本文件;将指定分支号对应的第二版本文件确定为第一分支下的第一待合并版本文件;将目标分支号对应的分支确定为第二分支;在第二分支对应的版本文件中查找与第一版本文件相同的文件,将查找到的文件作为第二分支下的第二待合并版本文件。
进一步的,上述每个分支对应有目录结构;文件确定模块104,用于确定第一版本文件在第一分支下的第一目录结构中的第一存储路径;在第二分支下的第二目录结构中查找与第一存储路径相同的第二存储路径;将第二存储路径对应的版本文件确定为与第一版本文件相同的文件。
本申请实施例提供的分支版本合并装置,其实现原理及产生的技术效果和前述方法实施例相同,为简要描述,装置的实施例部分未提及之处,可参考前述分支版本合并方法实施例中相应内容。
基于上述方法实施例,本申请实施例还提供一种分支版本合并系统,参见图11所示,该系统包括:版本管理服务器112、终端设备114和服务端116;终端设备114安装有智能聊天工具;服务端116分别与终端设备114和版本管理服务器112连接;服务端116用于执行前述服务端侧方法实施例所述的方法;版本管理服务器112用于执行前述版本管理服务器侧方法实施例所述的方法。
本申请实施例提供的分支版本合并系统,其实现原理及产生的技术效果和前述方法实施例相同,为简要描述,系统的实施例部分未提及之处,可参考前述分支版本合并方法实施例中相应内容。
本申请实施例还提供了一种电子设备,如图12所示,为该电子设备的结构示意图,其中,该电子设备包括处理器121和存储器120,该存储器120存储有能够被该处理器121执行的计算机可执行指令,该处理器121执行该计算机可执行指令以实现上述方法。
在图12示出的实施方式中,该电子设备还包括总线122和通信接口123,其中,处理器121、通信接口123和存储器120通过总线122连接。
其中,存储器120可能包含高速随机存取存储器(RAM,Random Access Memory),也可能还包括非不稳定的存储器(non-volatile memory),例如至少一个磁盘存储器。通过至少一个通信接口123(可以是有线或者无线)实现该系统网元与至少一个其他网元之间的通信连接,可以使用互联网,广域网,本地网,城域网等。总线122可以是ISA(IndustryStandard Architecture,工业标准体系结构)总线、PCI(Peripheral ComponentInterconnect,外设部件互连标准)总线或EISA(Extended Industry StandardArchitecture,扩展工业标准结构)总线等。所述总线122可以分为地址总线、数据总线、控制总线等。为便于表示,图12中仅用一个双向箭头表示,但并不表示仅有一根总线或一种类型的总线。
处理器121可能是一种集成电路芯片,具有信号的处理能力。在实现过程中,上述方法的各步骤可以通过处理器121中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器121可以是通用处理器,包括中央处理器(Central Processing Unit,简称CPU)、网络处理器(Network Processor,简称NP)等;还可以是数字信号处理器(DigitalSignal Processor,简称DSP)、专用集成电路(Application Specific IntegratedCircuit,简称ASIC)、现场可编程门阵列(Field-Programmable Gate Array,简称FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成,或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器,闪存、只读存储器,可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器,处理器121读取存储器中的信息,结合其硬件完成前述实施例的方法的步骤。
本申请实施例还提供了一种计算机可读存储介质,该计算机可读存储介质存储有计算机可执行指令,该计算机可执行指令在被处理器调用和执行时,该计算机可执行指令促使处理器实现上述方法,具体实现可参见前述方法实施例,在此不再赘述。
本申请实施例所提供的方法、装置和电子设备的计算机程序产品,包括存储了程序代码的计算机可读存储介质,所述程序代码包括的指令可用于执行前面方法实施例中所述的方法,具体实现可参见方法实施例,在此不再赘述。
除非另外具体说明,否则在这些实施例中阐述的部件和步骤的相对步骤、数字表达式和数值并不限制本申请的范围。
所述功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个处理器可执行的非易失的计算机可读取存储介质中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
在本申请的描述中,需要说明的是,术语“中心”、“上”、“下”、“左”、“右”、“竖直”、“水平”、“内”、“外”等指示的方位或位置关系为基于附图所示的方位或位置关系,仅是为了便于描述本申请和简化描述,而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作,因此不能理解为对本申请的限制。此外,术语“第一”、“第二”、“第三”仅用于描述目的,而不能理解为指示或暗示相对重要性。
最后应说明的是:以上所述实施例,仅为本申请的具体实施方式,用以说明本申请的技术方案,而非对其限制,本申请的保护范围并不局限于此,尽管参照前述实施例对本申请进行了详细的说明,本领域的普通技术人员应当理解:任何熟悉本技术领域的技术人员在本申请揭露的技术范围内,其依然可以对前述实施例所记载的技术方案进行修改或可轻易想到变化,或者对其中部分技术特征进行等同替换;而这些修改、变化或者替换,并不使相应技术方案的本质脱离本申请实施例技术方案的精神和范围,都应涵盖在本申请的保护范围之内。因此,本申请的保护范围应所述以权利要求的保护范围为准。
Claims (17)
1.一种分支版本合并方法,其特征在于,所述方法应用于服务端,所述服务端与版本管理服务器连接;所述版本管理服务器包括多个分支;每个分支包括至少一个版本文件;所述方法包括:
接收用户的分支合并请求;所述分支合并请求中携带有目标版本号和目标分支号;
将所述目标版本号和所述目标分支号发送至所述版本管理服务器,以使所述版本管理服务器根据所述目标版本号和所述目标分支号,确定第一分支下的第一待合并版本文件和第二分支下的第二待合并版本文件;其中,合并方向为从第一分支到所述第二分支;
接收所述版本管理服务器返回的所述第二待合并版本文件的标识,基于所述第二待合并版本文件的标识创建目标仓库;
在所述目标仓库中进行所述第一待合并版本文件和所述第二待合并版本文件的合并操作,得到目标合并版本文件;
将所述目标合并版本文件发送至所述版本管理服务器。
2.根据权利要求1所述的方法,其特征在于,将所述目标版本号和所述目标分支号发送至所述版本管理服务器,以使所述版本管理服务器根据所述目标版本号和所述目标分支号,确定第一分支下的第一待合并版本文件和第二分支下的第二待合并版本文件的步骤,包括:
将所述目标版本号和所述目标分支号发送至所述版本管理服务器,以使所述版本管理服务器根据所述目标版本号,查找对应的版本提交信息;所述版本提交信息包括:指定分支号、第一版本文件和第二版本文件;所述第二版本文件为在所述第一版本文件基础上进行修改得到的新版本文件;将所述指定分支号对应的第二版本文件确定为第一分支下的第一待合并版本文件;将所述目标分支号对应的分支确定为第二分支;在所述第二分支对应的版本文件中查找与所述第一版本文件相同的文件,将查找到的文件作为所述第二分支下的第二待合并版本文件。
3.根据权利要求1所述的方法,其特征在于,基于所述第二待合并版本文件的标识创建目标仓库的步骤,包括:
根据所述第二待合并版本文件的标识,从所述版本管理服务器拉取所述第二待合并版本文件;
生成包含所述第二待合并版本文件的目标仓库。
4.根据权利要求2所述的方法,其特征在于,在所述目标仓库中进行所述第一待合并版本文件和所述第二待合并版本文件的合并操作,得到目标合并版本文件的步骤,包括:
接收所述版本管理服务器根据所述版本提交信息,返回的所述第一待合并版本文件对应的修改信息;
基于所述修改信息在所述目标仓库中对所述第二待合并版本文件进行合并操作,得到目标合并版本文件。
5.根据权利要求1所述的方法,其特征在于,在将所述目标合并版本文件发送至所述版本管理服务器的步骤之后,所述方法还包括:
删除所述目标仓库。
6.根据权利要求1所述的方法,其特征在于,所述服务端还与终端设备连接;所述终端设备安装有智能聊天工具;接收用户的分支合并请求的步骤,包括:
接收所述终端设备发送的分支合并请求;所述分支合并请求为所述用户在所述终端设备的界面上输入的基于所述目标版本号的分支合并指令。
7.根据权利要求6所述的方法,其特征在于,在所述目标仓库中进行所述第一待合并版本文件和所述第二待合并版本文件的合并操作,得到目标合并版本文件的步骤之后,所述方法还包括:
向所述终端设备发送分支合并成功的第一提示信息,以使所述终端设备向所述用户显示所述第一提示信息。
8.根据权利要求6所述的方法,其特征在于,所述方法还包括:
如果未接收到所述版本管理服务器返回的所述第二待合并版本文件的标识,或者,在所述目标仓库中进行所述第一待合并版本文件和所述第二待合并版本文件的合并操作出现冲突时,向所述终端设备发送分支合并失败的第二提示信息,以使所述终端设备向所述用户显示所述第二提示信息。
9.根据权利要求8所述的方法,其特征在于,所述第二提示信息还至少包括以下之一:分支合并失败原因、需手动处理提示信息、处理人信息和冲突文件。
10.一种分支版本合并方法,其特征在于,所述方法应用于版本管理服务器,所述版本管理服务器与服务端连接;所述版本管理服务器包括多个分支;每个分支包括至少一个版本文件;所述方法包括:
接收所述服务端发送的目标版本号和目标分支号;
根据所述目标版本号和所述目标分支号,确定第一分支下的第一待合并版本文件和第二分支下的第二待合并版本文件;其中,合并方向为从第一分支到所述第二分支;
向所述服务端发送所述第二待合并版本文件的标识,以使所述服务端基于所述第二待合并版本文件的标识创建目标仓库;在所述目标仓库中进行所述第一待合并版本文件和所述第二待合并版本文件的合并操作,得到目标合并版本文件;
接收所述服务端发送的所述目标合并版本文件。
11.根据权利要求10所述的方法,其特征在于,根据所述目标版本号和所述目标分支号,确定第一分支下的第一待合并版本文件和第二分支下的第二待合并版本文件的步骤,包括:
根据所述目标版本号,查找对应的版本提交信息;所述版本提交信息包括:指定分支号、第一版本文件和第二版本文件;所述第二版本文件为在所述第一版本文件基础上进行修改得到的新版本文件;
将所述指定分支号对应的第二版本文件确定为第一分支下的第一待合并版本文件;
将所述目标分支号对应的分支确定为第二分支;
在所述第二分支对应的版本文件中查找与所述第一版本文件相同的文件,将查找到的文件作为所述第二分支下的第二待合并版本文件。
12.根据权利要求11所述的方法,其特征在于,每个分支对应有目录结构;在所述第二分支对应的版本文件中查找与所述第一版本文件相同的文件的步骤,包括:
确定所述第一版本文件在所述第一分支下的第一目录结构中的第一存储路径;
在所述第二分支下的第二目录结构中查找与所述第一存储路径相同的第二存储路径;
将所述第二存储路径对应的版本文件确定为与所述第一版本文件相同的文件。
13.一种分支版本合并装置,其特征在于,所述装置应用于服务端,所述服务端与版本管理服务器连接;所述版本管理服务器包括多个分支;每个分支包括至少一个版本文件;所述装置包括:
请求接收模块,用于接收用户的分支合并请求;所述分支合并请求中携带有目标版本号和目标分支号;
请求发送模块,用于将所述目标版本号和所述目标分支号发送至所述版本管理服务器,以使所述版本管理服务器根据所述目标版本号和所述目标分支号确定第一分支下的第一待合并版本文件和第二分支下的第二待合并版本文件;其中,合并方向为从第一分支到所述第二分支;
仓库创建模块,用于接收所述版本管理服务器返回的所述第二待合并版本文件的标识,基于所述第二待合并版本文件的标识创建目标仓库;
分支合并模块,用于在所述目标仓库中进行所述第一待合并版本文件和所述第二待合并版本文件的合并操作,得到目标合并版本文件;
版本文件发送模块,用于将所述目标合并版本文件发送至所述版本管理服务器。
14.一种分支版本合并装置,其特征在于,所述装置应用于版本管理服务器,所述版本管理服务器与服务端连接;所述版本管理服务器包括多个分支;每个分支包括至少一个版本文件;所述装置包括:
信息接收模块,用于接收所述服务端发送的目标版本号和目标分支号;
文件确定模块,用于根据所述目标版本号和所述目标分支号,确定第一分支下的第一待合并版本文件和第二分支下的第二待合并版本文件;其中,合并方向为从第一分支到所述第二分支;
信息发送模块,用于向所述服务端发送所述第二待合并版本文件的标识,以使所述服务端基于所述第二待合并版本文件的标识创建目标仓库;在所述目标仓库中进行所述第一待合并版本文件和所述第二待合并版本文件的合并操作,得到目标合并版本文件;
文件接收模块,用于接收所述服务端发送的所述目标合并版本文件。
15.一种分支版本合并系统,其特征在于,所述系统包括:版本管理服务器、终端设备和服务端;所述终端设备安装有智能聊天工具;
所述服务端分别与所述终端设备和所述版本管理服务器连接;
所述服务端用于执行如权利要求1-9任一项所述的方法;
所述版本管理服务器用于执行如权利要求10-12任一项所述的方法。
16.一种电子设备,其特征在于,包括处理器和存储器,所述存储器存储有能够被所述处理器执行的计算机可执行指令,所述处理器执行所述计算机可执行指令以实现权利要求1至9或10-12任一项所述的方法。
17.一种计算机可读存储介质,其特征在于,所述计算机可读存储介质存储有计算机可执行指令,所述计算机可执行指令在被处理器调用和执行时,计算机可执行指令促使处理器实现权利要求1至9或10-12任一项所述的方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202111480768.XA CN114237688A (zh) | 2021-12-06 | 2021-12-06 | 分支版本合并方法、装置、系统及电子设备 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202111480768.XA CN114237688A (zh) | 2021-12-06 | 2021-12-06 | 分支版本合并方法、装置、系统及电子设备 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN114237688A true CN114237688A (zh) | 2022-03-25 |
Family
ID=80753568
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202111480768.XA Pending CN114237688A (zh) | 2021-12-06 | 2021-12-06 | 分支版本合并方法、装置、系统及电子设备 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN114237688A (zh) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN117270943A (zh) * | 2023-09-15 | 2023-12-22 | 上海子虔科技有限公司 | 一种基于元数据的云端应用文件版本管理系统及方法 |
CN117742777A (zh) * | 2024-02-21 | 2024-03-22 | 沐曦集成电路(上海)有限公司 | 芯片文件版本管理系统 |
-
2021
- 2021-12-06 CN CN202111480768.XA patent/CN114237688A/zh active Pending
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN117270943A (zh) * | 2023-09-15 | 2023-12-22 | 上海子虔科技有限公司 | 一种基于元数据的云端应用文件版本管理系统及方法 |
CN117742777A (zh) * | 2024-02-21 | 2024-03-22 | 沐曦集成电路(上海)有限公司 | 芯片文件版本管理系统 |
CN117742777B (zh) * | 2024-02-21 | 2024-05-03 | 沐曦集成电路(上海)有限公司 | 芯片文件版本管理系统 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN108196878B (zh) | 应用程序安装包的生成方法、装置、电子设备及存储介质 | |
US11960879B2 (en) | Code conflict resolution system and method, apparatus, device, and medium | |
CN114237688A (zh) | 分支版本合并方法、装置、系统及电子设备 | |
CN112148509A (zh) | 数据处理方法、装置、服务器及计算机可读存储介质 | |
CN106991046B (zh) | 应用测试方法及装置 | |
KR20190095099A (ko) | 거래 시스템 에러 검출 방법, 장치, 저장 매체 및 컴퓨터 장치 | |
CN113961332A (zh) | 一种工作流引擎实现的方法、装置、电子设备及存储介质 | |
CN111078274A (zh) | 一种代码开发方法、装置、电子设备和计算机存储介质 | |
CN111949607A (zh) | 一种udt文件的监控方法、系统和装置 | |
US20130013624A1 (en) | Reducing Errors in Sending File Attachments | |
JP2007128450A (ja) | ソフトウェア再利用部品管理システム | |
CN113821249A (zh) | 项目开发配置的方法、装置、电子设备和可读存储介质 | |
US20080172659A1 (en) | Harmonizing a test file and test configuration in a revision control system | |
CN111506339A (zh) | 软件开发工具包sdk的变更信息处理方法及装置 | |
CN114707971B (zh) | 工作流流程驳回方法、装置、设备及计算机可读存储介质 | |
US11366642B1 (en) | Change migration: processes for ensuring successful deployment of design changes | |
CN114371870A (zh) | 代码扫描、提交方法及代码扫描服务器、客户端和服务端 | |
JP2018120256A (ja) | 設定操作入力支援装置、設定操作入力支援システム | |
CN115469844A (zh) | 代码处理方法、系统、计算机集群、介质及程序产品 | |
CN113806327A (zh) | 一种数据库设计方法、装置及相关设备 | |
CN113626409B (zh) | 一种测试资料处理方法、装置、设备及存储介质 | |
JP2008225696A (ja) | ウェブログ管理プログラム、ウェブログ管理装置およびウェブログ管理方法 | |
CN110855526A (zh) | 检测数据源连接的方法、装置、存储介质及电子设备 | |
CN109871231B (zh) | 一种代码共享方法及系统 | |
US11468026B2 (en) | Information processing apparatus, information processing method, and recording medium recording information processing program |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination |