CN109725926A - 管理基线的方法和装置以及数据处理方法 - Google Patents

Abstract

本发明公开了一种管理基线的方法和装置以及数据处理方法。其中，该方法包括：通过版本控制软件创建开发分支；在第一基线列表中查找开发分支到目标分支的合并基线，其中，第一基线列表用于存储与目标分支有关的基线；在未查找到合并基线时，从第二基线列表中查询合并基线，其中，第二基线列表中包括与开发分支有关的基线；在查找到合并基线时，依据合并基线将开发分支合并至目标分支中。本发明解决了在合并分支的过程中易产生合并冲突的技术问题。

Description

管理基线的方法和装置以及数据处理方法

技术领域

本发明涉及计算机软件领域，具体而言，涉及一种管理基线的方法和装置以及数据处理方法。

背景技术

基线管理(SVN，即Subversion，开放源代码的版本控制系统)，可基于分支管理系统，使多个人共同开发同一个项目，共用资源。

分支主要分为主干分支、开发分支和发布分支。其中，每一个代码库应该有一个，且仅有一个主干分支，主干分支主要用于为用户提供正式的软件发布版本，开发分支主要用于在主干分支稳定之后基于正式的软件发布版本来开发软件，发布分支是用来为开发分支所开发出新的发布版本做准备。具体的，当开发分支上的代码处在一个稳定且准备发布的状态时，如果开发分支发生了任何改变，则改变后的开发分支将合并到主干分支上。而当发布分支呈现出可被发布的状态时，将发布分支合并到主干分支上。另外，在发布分支上所做的改变需要被合并到开发分支上。

图1示出了一种现有的合并分支的原理示意图，在图1中，来源节点为需要合并的分支(即开发分支)上的节点，目标节点为合并的目标分支(即主干分支)上的节点，祖先节点为向上追溯距离目标节点和来源节点最近的公共节点(该祖先节点的版本为基线版本)，例如，开发分支上节点的排列顺序为：G1→A1→B1→C→D1→E1→F1，其中，来源节点为F1；主干分支上节点的排列顺序为：G1→B2→C→D2→E2→F2，其中，目标节点为F2，节点C为距离节点F1和节点F2的距离最近，虽然通过节点G1也可得到来源节点和目标节点，但G1距离F1和F2的距离不是最近距离，因此，节点G1不是祖先节点，而节点C为祖先节点。

如图1所示，从开发分支合并到主干分支，其中，来源节点位于开发分支上，而目标节点位于主干分支上，祖先节点为距离来源节点和目标节点最近的节点，即基线版本。基于基线版本，对来源节点和目标节点进行合并，得到图1中的合并结果。

现有技术中，对分支进行合并主要通过如下步骤：

(1)首先确定来源节点和目标节点，然后向上追溯的距离目标节点和来源节点最近的公共节点作为祖先节点，进而确定祖先节点的版本，即基线版本；

(2)比较来源节点、目标节点和祖先节点的内容；

(3)如表1所示，如果三类节点的内容均没有发生变化，则合并结果为三者保持一致，如表1中的第1行，三个节点的内容均为A，合并后的结果也为A。

表1

序号	祖先节点	来源节点	目标节点	合并结果
					1	A	A	A	A
2	B	删除	B	删除
					3	D	D	Z(修改)	Z(修改)
4	E	R(修改)	Q(修改)	？(冲突)

如果来源节点、目标节点和祖先节点的内容任何一方发生了变化，并且只有一方发生变化时，合并结果为变化的节点的内容，例如，表1中的第2行，祖先节点的内容为B，来源节点的内容被删除，目标节点的内容也为B，此时的合并结果删除。又例如，祖先节点的内容为D，来源节点的内容也为D，而目标节点的内容修改为Z，则合并结果为Z。

如果三类节点中的任意两类节点的内容发生了改变，两类节点的内容都有变化，此时，便产生了合并冲突，需要通过用户来选择合并结果，例如，表1中的第4行，祖先节点的内容为E，来源节点的内容修改为R，而目标节点的内容修改为Q，此时合并结果不确定。

针对上述在合并分支的过程中易产生合并冲突的问题，目前尚未提出有效的解决方案。

发明内容

本发明实施例提供了一种管理基线的方法和装置以及数据处理方法，以至少解决在合并分支的过程中易产生合并冲突的技术问题。

根据本发明实施例的一个方面，提供了一种管理基线的方法，包括：通过版本控制软件创建开发分支；在第一基线列表中查找开发分支到目标分支的合并基线，其中，第一基线列表用于存储与目标分支有关的基线；在未查找到合并基线时，从第二基线列表中查询合并基线，其中，第二基线列表中包括与开发分支有关的基线；在查找到合并基线时，依据合并基线将开发分支合并至目标分支中。

根据本发明实施例的另一方面，还提供了一种管理基线的装置，包括：创建模块，用于通过版本控制软件创建开发分支；第一查询模块，用于在第一基线列表中查找开发分支到目标分支的合并基线，其中，第一基线列表用于存储与目标分支有关的基线；第二查询模块，用于在未查找到合并基线时，从第二基线列表中查询合并基线，其中，第二基线列表中包括与开发分支有关的基线；合并模块，用于在查找到合并基线时，依据合并基线将开发分支合并至目标分支中。

根据本发明实施例的另一方面，还提供了一种管理基线的方法，包括：在主干分支上创建多个开发分支；对于每个开发分支，获取开发分支演进后的演进分支；将演进分支合并到发布分支时，在第一基线列表中查找演进分支到目标分支的合并基线，其中，第一基线列表用于存储与目标分支有关的基线；在未查找到合并基线时，从第二基线列表中查询合并基线，其中，第二基线列表中包括与开发分支有关的基线；在查找到合并基线时，依据合并基线将演进分支合并至目标分支中。

根据本发明实施例的另一方面，还提供了一种存储介质，该存储介质包括存储的程序，其中，在程序运行时控制存储介质所在设备执行管理基线的方法。

根据本发明实施例的另一方面，还提供了一种处理器，该处理器用于运行程序，其中，程序运行时执行管理基线的方法。

根据本发明实施例的另一方面，还提供了一种数据处理方法，包括：按照预设规则从第一基线列表和第二基线列表中确定合并基线的查找列表；其中，合并基线为将开发分支合并到目标分支所依据的基线，第一基线列表用于存储与目标分支有关的基线，第二基线列表用于存储与开发分支有关的基线，基线为软件文件或代码的基准版本；在查找列表中查找到合并基线时，依据查找到的基线将开发分支合并至目标分支中。

根据本发明实施例的另一方面，还提供了一种数据处理方法，包括：获取第一数据和第二数据，其中，第一数据、第二数据用于合并操作；获取第二数据的版本信息；依据第二数据的版本信息，将第一数据合并至第二数据。

根据本发明实施例的另一方面，还提供了一种数据处理方法，包括：获取第一数据和第二数据，其中，第一数据、第二数据用于合并操作；获取第一列表，其中，第一列表包括第二数据的版本信息；确定第一列表中不存在将第一数据合并至第二数据所依据的版本信息；获取第二列表，其中,第二列表包括第一数据的版本信息；依据第二列表的版本信息，将第一数据合并至第二数据。

根据本发明实施例的另一方面，还提供了一种数据处理方法，包括：客户端接收外部上传的待合并数据；客户端将待合并数据发送至服务器；服务器从第一列表中查询版本信息，其中，版本信息为将待合并数据合并至目标数据所依据的版本；在未从第一列表中查询到版本信息时，从第二列表中查询版本信息；在从第一列表或第二列表中查询到版本信息时，依据查找到的版本信息将待合并数据合并至目标数据。

在本发明实施例中，通过基于版本控制软件创建开发分支，在第一基线列表中查找开发分支到目标分支的合并基线，如果未查找到合并基线，则从第二基线列表中查询合并基线，在查询到合并基线之后，依据合并基线将开发分支合并至目标分支中，其中，第一基线列表用于存储与目标分支有关的基线，第二基线列表中包含与开发分支有关的基线，达到了在分支合并的过程中有效避免合并冲突的目的，从而实现了对基线进行有效管理的技术效果，进而解决了在合并分支的过程中易产生合并冲突的技术问题。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据现有技术的一种现有的合并分支的原理示意图；

图2是根据本发明实施例的一种管理基线的方法流程图；

图3是根据本发明实施例的一种可选的创建开发分支的流程示意图；

图4是根据本发明实施例的一种可选的选择基线的流程示意图；

图5是根据本发明实施例的一种可选的基线计算的方法流程图；

图6是根据本发明实施例的一种可选的管道之间的连接示意图；

图7是根据本发明实施例的一种可选的确定目标分支的方法流程图；

图8是根据本发明实施例的一种可选的分支合并的示意图；

图9是根据本发明实施例的一种管理基线的装置结构示意图；

图10是根据本发明实施例的一种计算机终端的结构框图；

图11是根据本发明实施例的一种管理基线的方法流程图；

图12是根据本发明实施例的一种数据处理方法的流程图；

图13是根据本发明实施例的一种数据处理方法的流程图；

图14是根据本发明实施例的一种数据处理方法的流程图；以及

图15是根据本发明实施例的一种数据处理方法的流程图。

具体实施方式

为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

首先，在对本申请实施例进行描述的过程中出现的部分名词或术语适用于如下解释：

(1)管道模型，即pipeline模型，在开发模式中指开发发布过程中特定的一个生命周期分支，某一个代码或应用可能会根据环境变量(例如，env变量)和数据库对象的集合(例如，schema)等的不同而具备多条管道，基于管道模型可以将开发分支合并到发布分支上，还可以将开发分支合并到主干分支上。

(2)合并，即merge，在本申请中指将开发分支或发布分支合并到主干分支的过程。

(3)反向合并，即rebase，在本申请中指从主干分支反向合并到开发分支或发布分支的过程。

(4)基线，即Baseline，指一个正式标准，随后的版本基于此标准，并且只有经过授权后才能变更该标准。其中，基线的主要功能如下：在开发过程中，以该基线作为标准，将集成工作区中的文件合并入开发工作区中。

(5)基线提升，指在发布分支之后，将发布分支合并到主干上，并创建基线的过程。此外，基线提升的过程还可以保存提升后的基线。

(6)主干分支，即trunk，为测试人员进行测试的专用分支，其中，只有在修复测试人员提出错误的情况下，开发人员才有权限对主干分支进行修改，在其他情况下，开发人员无权对主干分支进行修改。此外，主干分支没有源分支，对主干分支进行测试的版本为Beta版本。

(7)分支开发模式，即BDM(Branch Developing Mode)，是一种基于分支开发和分支发布的研发模型，其中，主干分支为分支开发模型中的稳定版本。

(8)开发分支，即Development，该分支为开发人员进行开发的专用分支，其他人员无需使用该分支。其中，该分支的源分支为主干分支，所对应的版本为当前正在开发的版本，即Dev版本。

(9)发布分支，即Release，该分支为发布人员的专用分支，除紧急修复外，开发人员不能对该分支进行任何修改，其中，该分支的源分支为主干分支，所对应的版本为当前已经发布的版本，即Live版本。

(10)基线分支，即Tag，其中，任何人都无权对该分支进行修改。此外，该分支可对历次发布后的基线进行维护，其分支的源分支为发布分支，所对应的版本为最近的该基线分支上一次成功发布的版本基线。

实施例1

根据本发明实施例，提供了一种管理基线的方法实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

具体的，本申请提供了如图2所示的管理基线的方法。图2是根据本发明所提供的管理基线的方法实施例的方法流程图，如图2所示，该方法具体包括如下步骤：

步骤S202，创建开发分支。

需要说明的是，本申请的执行主体可以为版本控制软件，其中，版本控制软件可以为安装在服务器端的基线管理软件，也可以为安装在客户端的基线管理软件。上述版本控制软件为可以实现基线管理功能的SVN工具，例如，TortoiseSVN工具和Versions工具。另外，通过该软件可以创建开发分支以及基线列表，其中，基线列表至少包括用于存储与目标分支有关的基线的第一基线列表和包括与开发分支有关的基线的第二基线列表。

在一种可选的实施例中，如图3所示的一种可选的创建开发分支的流程示意图，具体的，每一个代码库具有一个，且仅有一个主干分支，该主干分支是自动建立的，版本控制软件根据主干分支的T-1版本创建出develop-A分支，此时，develop-A的版本为A-0，开发者将版本A-0对应的代码提交到开发分支的A-0版本上，在此之后，如果开发者再次提交代码，develop-A分支所对应的版本将演进到版本A-1(图3上显示为：提交代码)，此时，develop-A分支合并到主干分支的基线为主干分支的T-1版本(如图3中T-1对应的虚线框所示)。在创建完develop-A分支之后，开发者可能又发布了新的版本，此时，版本控制软件从主干分支的T-2版本上创建出develop-B分支(如图3中T-2对应的虚线框所示)，此时，develop-B分支所对应的版本为B-0，此后如果开发者再次提交两次代码，则develop-B分支将演进到B-2版本，develop-B分支对于主干分支的合并基线为主干分支的T-2版本。对于开发分支develop-N(如图3中T-N对应的虚线框所示)的创建方法，与上述方法类似，在此不再赘述。

需要说明的是，图3中的虚线表示反向合并的操作(即从主干到分支的合并)，即在develop-A分支的版本演进到A-1版本之后，如果develop-A分支需要同步主干分支所上传的最新的内容，即当前的T-2版本，开发人员通过版本控制软件选择从主干分支的T-2版本进行一次反向合并操作，将线上的代码同步到相应的开发分支上，从而在反向合并后，该开发分支所对应的版本演进到A-2。

在另一种可选的实施例中，如图4所示的一种可选的选择基线的流程示意图。具体的，在创建开发分支之后，如果develop-A分支需要同步主干分支所上传的最新的发布内容，即当前的T-2版本，在版本控制软件从主干分支反向合到develop-A分支的操作后，会记录下develop-A分支当前对于主干分支的合并基线的版本为主干分支的T-2版本。因此，在相应的系统中便存在了两条与develop-A分支相对应的基线，一条为初始从主干分支的T-1版本所创建的基线，另一条为从主干分支的T-2版本进行反向合并后的基线。如果后续进行了多次反向合并的动作，则开发系统会记录下基线的创建以及使用过程。而对于开发分支而言，从始至终存在一条最新的基线信息，该最新的基线信息记录在branch_baseline的表(图4中并未示出)中，用于后续的基线计算。

需要说明的是，在branch_baseline的表中存储的是最新的基线信息，例如，由于图4中最上面的Baseline record中存储的是最新的基线信息，因此，图4中最上面的Baseline record中的基线信息将存储在branch_baseline的表中。

由图4可知，在创建开发分支develop-A的过程中，基线列表(即Baseline record)存储基线的信息，其中，每个基线列表(即Baseline record)中至少存储了如下基线的信息：源分支(即图4中的src)、源版本(即图4中的src revision)、分支操作类型(即图4中的type)以及时间信息(即图4中的Time)，其中，源分支至少包括如下之一：主干(即图4中的trunk)、开发、发布和基线，操作分类型至少包括：反向合并(即rebase)、创建(即create)、，源版本至少包括：当前正在测试的版本(即Beta)、当前正在开发的版本(即Dev)以及当前已经发布的版本(即Live)。

步骤S204，在第一基线列表中查找开发分支到目标分支的合并基线，其中，第一基线列表用于存储与目标分支有关的基线。

需要说明的是，上述与目标分支有关的基线为开发分支与目标分支进行合并时所需要的合并基线，上述目标分支至少包括如下之一:发布分支和主干分支。此外，上述与目标分支有关的基线可以为发布分支合并其他分支时所使用的基线，或发布分支被合并至其他分支时所用到的基线。

具体的，首先获取到开发分支所对应的版本、分支类型等信息，同时，确定目标分支所对应的版本、分支类型等信息，然后基于开发分支所对应的版本、分支类型等信息以及目标分支所对应的版本、分支类型等信息从第一基线列表所存储的多个合并基线确定当前的开发分支合并时所使用的合并基线。在查找到开发分支到目标分支的合并基线后，基于合并基线对开发分支和目标分支进行合并处理，在分支合并成功后，开发系统将开发分支和发布分支进行合并的基线信息记录在branch_baseline的列表中，其中，branch_baseline的列表可用来存储发布分支合并的基线信息。

需要说明的是，第一基线列表存储与目标分支的有关的基线，将分支合并后的基线信息存储在branch_baseline的列表可以有效的避免在同一个集成区内进行多次分支合并所造成的冲突问题。

步骤S206，在未查找到合并基线时，从第二基线列表中查询合并基线，其中，第二基线列表中包括与开发分支有关的基线。

需要说明的是，上述第二基线列表中还可以为与发布分支有关的基线。此外，上述第二基线列表可以为上述的branch_baseline的列表。

具体的，在根据开发分支和分布分支未在第一基线列表中，查找到相对应的最新基线时，版本控制软件根据开发分支查找到第一基线列表中所对应的开发分支的最新基线。如果在第二基线列表中查找到了相应的基线，则该基线进行合并，如果人没有找到，说明开发系统出现了问题，此时开发系统抛出异常。

步骤S208，在查找到合并基线时，依据合并基线将开发分支合并至目标分支中。

具体的，在查找到合并基线之后，将根据查找到的合并基线将开发分支合并至目标分支中。如图5所示的一种可选的基线计算的方法流程图。如果在release_baseline的列表(即第一基线列表)中查询到了最新的基线信息(即查询到合并基线)，则将返回到基线列表中，从基线列表中获取基线信息；如果未在release_baseline的列表中查找到最新的基线信息(即查询到合并基线)，在继续判断在branch_baseline的列表中是否存在所要查找到最新的基线信息(即查询到合并基线)，如果存在，则返回到基线列表，否则，抛出异常。

基于上述步骤S202至步骤S208所限定的方案，可以获知，通过基于版本控制软件创建开发分支，在第一基线列表中查找开发分支到目标分支的合并基线，如果未查找到合并基线，则从第二基线列表中查询合并基线，在查询到合并基线之后，依据合并基线将开发分支合并至目标分支中，其中，第一基线列表用于存储与目标分支有关的基线，第二基线列表中包含与开发分支有关的基线。

容易注意到的是，由于是在第一基线列表中存储的是与目标分支有关的基线，而第二基线列表中存储的是与开发分布有关的基线，即在不同的基线列表中存储有不同的基线信息，从而可以有效的避免在同一个集成区内进行多次分支合并所造成的冲突问题。

本申请的上述方案可以达到在分支合并的过程中有效避免合并冲突的目的，从而实现了对基线进行有效管理的技术效果，进而解决了在合并分支的过程中易产生合并冲突的技术问题。

在一种可选的实施例中，基线管理方法还包括：将从目标分支所在管道模型进入下一管道模型时，将目标分支的内容更新至下一管道模型的分支中。

需要说明的是，可以根据实际的开发情况对上述管道模型的管道数量进行设置，在管道数量为多条的情况下，每条管道都可以作为一个单向的管道,每个管道由若干个节点构成，而整个研发流程是基于管道的形式进行传递的。当一个节点完毕后进入到下一个节点。当管道上的最后一个节点执行完毕后当前管道可以继续进入下一条管道继续若干代码相关活动。具体如图6所示的管道之间的连接示意图，在图6中，当前管道为管道a，管道a的节点主要包括集成节点、构建节点以及单侧节点等。当管道a的最后一个节点(即单测节点)完成后，将进入管道b的集成节点，进而通过管道b的流程的相应节点完成相关的操作，最后完成基线的提升。

具体的，当目标分支从管道a的最后一个节点进入到管道b之后，管道a的发布代码的内容将被带入到管道b中的发布代码中，同时管道b的版本演进将集成到管道b的发布代码中，基于上述方法便完成了将目标分支的内容更新至下一管道模型的分支中。

此外，还需要说明的是，由于上述目标分支的内容从一个管道模型进入到下一个管道模型只会执行一次，因此，在目标分支的内容从一个管道模型进入到下一个管道模型只会执行一次，将清空第一管道模型中的内容，即清空上一个管道模型内的内容。

在另一种可选的实施例中，依据合并基线将开发分支合并至目标分支中之前，还需要确定目标分支，其中，确定目标分支的方法为：从与版本控制软件的主干关联的分支中选择一个分支作为目标分支。

具体的，如图7所示的一种可选的确定目标分支的方法流程图。在图7中，在完成对开发分支的创建之后，开发系统将多个开发分支进行集成。首先，开发系统从多个开发分支中选择一个已经创建好的多个开发分支中选择一个开发分支作为分支合并的目标分支，从而根据该目标分支得到发布分支release-A，此时，发布分支release-A的分支基线也会被记录下来。在确定目标分支之后，对将开发分支合并到发布分支中。例如，开发分支develop-A合并到release-A，合并成功后release-A对应于develop-A的基线版本为A-2，而开发分支develop-B合并到release-B，合并成功后release-B对应于develop-B的基线版本为B-2，在开发分支为develop-N的情况下，开发分支develop-N合并到release-N，合并成功后release-N对应于develop-N的基线版本为N-X，其中，X为从主干分支所演进的版本号。

还存在一种可选的实施例，在第一基线列表中查找到开发分支到目标分支的合并基线时，管理基线的方法还包括：从第一基线列表中选择最新的一条基线。

需要说明的是，在每次对目标分支进行合并之前，开发系统将主干分支进行一次反向合并到开发分支上，从而可以保证合并基线的信息均为线上最新的发布内容。

此外，需要说明的是，当目标分支与开发分支合并产生冲突时，只有在冲突解决之后，才认为合成功并开始下一个分支的合并。分支首次合并到发布分支时,会到第一基线表中查询开发分支是否有到当前发布分支的合并基线。如果有当前发布分支的合并基线，则取出最新的一条发布内容；如果没有查询到基线，则选择从第二基线列表中获取开发分支的基线信息，从而将其进行合并。因此，可以有效地避免了分支合并造成树冲突，为分支的多次合并提供了可能，尤其在开发分支进行过反向合并时,反向合并的基线可以通过branch_baseline正确的计算出来，从而不会对主干分支到开发分支的反向合并造成冲突。

在另一种可选的实施例中，如图8所示的一种可选的分支合并的示意图，在图8中，虚线表示拉取分支，实线表示分支版本的演进，双箭头表示合并或反向合并，其中，发布分支和开发分支包含了4个节点，而主干分支包含了5个节点。具体的，从主干分支上创建出本次发布的发布分支,名称为release-A，然后从主干分支或发布分支上创建出开发分支，其中，创建的开发分支可能是多个(图8仅示出了在主干分支上创建开发分支的过程)。在创建开发分支之后，将创建好的开发分支合并到发布的发布分支上；最后，选择在发布上直接修改或者在开发分支修改后再次合并，即完成了开发分支与发布分支的合并过程。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质(如ROM/RAM、磁碟、光盘)中，包括若干指令用以使得一台终端设备(可以是手机，计算机，服务器，或者网络设备等)执行本发明各个实施例所述的方法。

实施例2

根据本发明实施例，还提供了一种用于实施上述管理基线的方法的管理基线的装置，如图9所示，该装置包括：创建模块901、第一查询模块903、第二查询模块905以及合并模块907。

其中，创建模块901，用于通过版本控制软件创建开发分支；第一查询模块903，用于在第一基线列表中查找开发分支到目标分支的合并基线，其中，第一基线列表用于存储与目标分支有关的基线；第二查询模块905，用于在未查找到合并基线时，从第二基线列表中查询合并基线，其中，第二基线列表中包括与开发分支有关的基线；合并模块907，用于在查找到合并基线时，依据合并基线将开发分支合并至目标分支中。

在一种可选的实施例中，管理基线的装置还包括：更新模块。其中，更新模块，用于将从目标分支所在管道模型进入下一管道模型时，将目标分支的内容更新至下一管道模型的分支中。

在一种可选的实施例中，管理基线的装置包括：清理模块。其中，清理模块，用于清空第一管道模型中的内容。

在一种可选的实施例中，管理基线的装置还包括：选择模块。其中，选择模块，用于从与版本控制软件的主干关联的分支中选择一个分支作为目标分支。

需要说明的是，目标分支包括：发布分支和主干分支。

此外，还需要说明的是，第二基线列表中还包括：与发布分支有关的基线。

在一种可选的实施例中，第一查询模块还包括：选择子模块。其中，选择子模块，用于从第一基线列表中选择最新的一条基线。

实施例3

本发明的实施例可以提供一种计算机终端，该计算机终端可以是计算机终端群中的任意一个计算机终端设备。可选地，在本实施例中，上述计算机终端也可以替换为移动终端等终端设备。

可选地，在本实施例中，上述计算机终端可以位于计算机网络的多个网络设备中的至少一个网络设备。

在本实施例中，上述计算机终端可以执行应用程序的漏洞检测方法中以下步骤的程序代码：通过版本控制软件创建开发分支；在第一基线列表中查找开发分支到目标分支的合并基线，其中，第一基线列表用于存储与目标分支有关的基线；在未查找到合并基线时，从第二基线列表中查询合并基线，其中，第二基线列表中包括与开发分支有关的基线；在查找到合并基线时，依据合并基线将开发分支合并至目标分支中。

可选地，图10是根据本发明实施例的一种计算机终端的结构框图。如图10所示，该计算机终端10可以包括：一个或多个(图中仅示出一个)处理器102、存储器104、以及装置106。

其中，存储器可用于存储软件程序以及模块，如本发明实施例中的安全漏洞检测方法和装置对应的程序指令/模块，处理器通过运行存储在存储器内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的系统漏洞攻击的检测方法。存储器可包括高速随机存储器，还可以包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器可进一步包括相对于处理器远程设置的存储器，这些远程存储器可以通过网络连接至终端10。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

处理器可以通过传输装置调用存储器存储的信息及应用程序，以执行下述步骤：通过版本控制软件创建开发分支；在第一基线列表中查找开发分支到目标分支的合并基线，其中，第一基线列表用于存储与目标分支有关的基线；在未查找到合并基线时，从第二基线列表中查询合并基线，其中，第二基线列表中包括与开发分支有关的基线；在查找到合并基线时，依据合并基线将开发分支合并至目标分支中。

可选的，上述处理器还可以执行如下步骤的程序代码：将从目标分支所在管道模型进入下一管道模型时，将目标分支的内容更新至下一管道模型的分支中。

可选的，上述处理器还可以执行如下步骤的程序代码：清空第一管道模型中的内容。

可选的，上述处理器还可以执行如下步骤的程序代码：从与版本控制软件的主干关联的分支中选择一个分支作为目标分支。

可选的，上述处理器还可以执行如下步骤的程序代码：从第一基线列表中选择最新的一条基线。

采用本发明实施例，提供了一种管理基线的方法。通过基于版本控制软件创建开发分支，在第一基线列表中查找开发分支到目标分支的合并基线，如果未查找到合并基线，则从第二基线列表中查询合并基线，在查询到合并基线之后，依据合并基线将开发分支合并至目标分支中，其中，第一基线列表用于存储与目标分支有关的基线，第二基线列表中包含与开发分支有关的基线，从而达到了在分支合并的过程中有效避免合并冲突的目的，进而解决了在合并分支的过程中易产生合并冲突的技术问题。

本领域普通技术人员可以理解，图10所示的结构仅为示意，计算机终端也可以是智能手机(如Android手机、iOS手机等)、平板电脑、掌声电脑以及移动互联网设备(MobileInternet Devices，MID)、PAD等终端设备。图10其并不对上述电子装置的结构造成限定。例如，计算机终端10还可包括比图10中所示更多或者更少的组件(如网络接口、显示装置等)，或者具有与图10所示不同的配置。

本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令终端设备相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：闪存盘、只读存储器(Read-Only Memory，ROM)、随机存取器(RandomAccess Memory，RAM)、磁盘或光盘等。

实施例4

本发明的实施例还提供了一种存储介质。可选地，在本实施例中，上述存储介质可以用于保存上述实施例一所提供的管理基线的方法所执行的程序代码。

可选地，在本实施例中，上述存储介质可以位于计算机网络中计算机终端群中的任意一个计算机终端中，或者位于移动终端群中的任意一个移动终端中。

可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的程序代码：通过版本控制软件创建开发分支；在第一基线列表中查找开发分支到目标分支的合并基线，其中，第一基线列表用于存储与目标分支有关的基线；在未查找到合并基线时，从第二基线列表中查询合并基线，其中，第二基线列表中包括与开发分支有关的基线；在查找到合并基线时，依据合并基线将开发分支合并至目标分支中。。

可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的程序代码：将从目标分支所在管道模型进入下一管道模型时，将目标分支的内容更新至下一管道模型的分支中。

可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的程序代码：清空第一管道模型中的内容。

可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的程序代码：从与版本控制软件的主干关联的分支中选择一个分支作为目标分支。

可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的程序代码：从第一基线列表中选择最新的一条基线。

实施例5

根据本发明实施例，还提供了如图11所示的一种管理基线的方法。其中，图11是根据本申请所提供的管理基线的方法实施例的管理基线的方法流程图，如图11所示，该方法具体包括如下步骤：

步骤S1102，在主干分支上创建多个开发分支；

步骤S1104，对于每个开发分支，获取开发分支演进后的演进分支；

步骤S1106，将演进分支合并到发布分支时，在第一基线列表中查找演进分支到目标分支的合并基线，其中，第一基线列表用于存储与目标分支有关的基线；

步骤S1108，在未查找到合并基线时，从第二基线列表中查询合并基线，其中，第二基线列表中包括与开发分支有关的基线；

步骤S1110，在查找到合并基线时，依据合并基线将演进分支合并至目标分支中。

需要说明的是，上述演进分支为对开发分支进行版本演进后所得到的开发分支，例如，如图3所示，版本控制软件根据主干分支的T-1版本创建出多个开发分支，例如develop-A分支、develop-B分支以及develop-N分支等，现以开发分支develop-A分支为例进行说明。此时，develop-A分支对应的版本为A-0。在开发者提交代码之后，develop-A分支所对应的版本演进到版本A-1，此时，A-1版本所对应的develop-A分支即为开发分支演进后的演进分支。

在一种可选的实施例中，版本控制软件在主干分支上创建多个开发分支，并获取到每个开发分支演进后的演进分支，然后在第一基线列表中获取到与目标分支有关的最新的基线信息，如果在第一基线列表中未查找到上述基线信息，则从第二基线列表(branch_baseline列表)中继续查找合并基线，如果在第二基线列表中查找到了合并基线，则基于合并基线对演进分支进行合并；如果在第二基线列表中也未查找到合并基线，则抛出异常。

基于上述步骤S1102至步骤S1110所限定的方案可以获知，通过在主干分支上创建多个开发甚至，对于每个开发分支获取开发分支演进后的演进分支，并将演进分支合并到发布分支，并在将演进分支合并到发布分支的过程中，在第一基线列表中查找演进分支到目标分支的合并基线，如果未查找到合并基线，则从第二基线列表中查询合并基线；如果查找到合并基线，则依据合并基线将演进分支合并至目标分支中，其中，第一基线列表用于存储与目标分支有关的基线，第二基线列表中包括与开发分支有关的基线。

容易注意到的是，由于是在第一基线列表中存储的是与目标分支有关的基线，而第二基线列表中存储的是与开发分布有关的基线，即在不同的基线列表中存储有不同的基线信息，从而可以有效的避免在同一个集成区内进行多次分支合并所造成的冲突问题。

本申请的上述方案可以达到在分支合并的过程中有效避免合并冲突的目的，从而实现了对基线进行有效管理的技术效果，进而解决了在合并分支的过程中易产生合并冲突的技术问题。

实施例6

根据本发明实施例，还提供了如图12所示的一种数据处理方法。其中，图12是根据本申请所提供的数据处理方法实施例的数据处理方法的流程图，如图12所示，该方法具体包括如下步骤：

步骤S1202，按照预设规则从第一基线列表和第二基线列表中确定合并基线的查找列表；其中，合并基线为将开发分支合并到目标分支所依据的基线，第一基线列表用于存储与目标分支有关的基线，第二基线列表用于存储与开发分支有关的基线，基线为软件文件或代码的基准版本；

步骤S1204，在查找列表中查找到合并基线时，依据查找到的基线将开发分支合并至目标分支中。

需要说明的是，上述预设规则可以为但不限于优先级规则，上述查找列表可以第一基线列表，也可以为第二基线列表。

在一种可选的实施例中，第一基线列表的优先级高于第二基线列表的优先级。版本控制软件先从第一基线列表中查找开发分支到目标分支的合并基线，此时的查找列表为第一基线列表。如果在第一基线列表中未查找到合并基线，则继续从第二基线列表中查询合并基线，此时，查找列表为第二基线列表。如果在第一基线列表中查找到了合并基线，则不再在第二基线列表中查找合并基线，只有在第一基线列表中不存在合并基线的情况下，才会在第二基线列表中查找合并基线。另外，在查找到合并基线之后，版本控制软件根据合并基线将开发分支合并到目标分支中。如果在两个基线列表中都没有查找到合并基线，则版本控制软件抛出异常。

基于上述步骤S1202至步骤S1204所限定的方案，可以获知，通过按照预设规则从第一基线列表和第二基线列表中确定合并基线的查找列表，在查找列表中查找合并基线时，依据查找到的基线将开发分支合并至目标分支中，其中，合并基线为将开发分支合并到目标分支所依据的基线，第一基线列表用于存储与目标分支有关的基线，第二基线列表用于存储与开发分支有关的基线，基线为软件文件或代码的基准标本。

容易注意到的是，由于是在第一基线列表中存储的是与目标分支有关的基线，而第二基线列表中存储的是与开发分布有关的基线，即在不同的基线列表中存储有不同的基线信息，从而可以有效的避免在同一个集成区内进行多次分支合并所造成的冲突问题。

本申请的上述方案可以达到在分支合并的过程中有效避免合并冲突的目的，从而实现了对基线进行有效管理的技术效果，进而解决了在合并分支的过程中易产生合并冲突的技术问题。

实施例7

根据本发明实施例，还提供了如图13所示的一种数据处理方法。其中，图13是根据本申请所提供的数据处理方法实施例的数据处理方法的流程图，如图13所示，该方法具体包括如下步骤：

步骤S1302，获取第一数据和第二数据，其中，第一数据、第二数据用于合并操作；

步骤S1304，获取第二数据的版本信息；

步骤S1306，依据第二数据的版本信息，将第一数据合并至第二数据。

需要说明的是，上述第一数据可以为但不限于开发分支，第二数据可以为但不限于目标分支，其中，目标分支至少包括如下之一：发布分支和主干分支，版本信息可以为将开发分支合并到目标分支的合并基线，

在一种可选的实施例中，安装在服务器端或客户端的版本管理工具可通过创建开发分支以得到开发分支(即第一数据)，然后在确定开发分支所对应的版本、分支类型等信息，以及目标分支(即第二数据)所对应的版本、分支类型等信息之后，版本管理工具根据上述信息从第一列表中所存储的多个合并基线确定是否存在开发分支合并时所使用的合并基线，如果第一列表中存在版本信息(即上述合并基线)，则版本管理工具通过基于上述版本信息将第一数据合并至第二数据。如果第一列表中不存在上述版本信息，则版本管理工具根据在第一列表中查找到与第一数据所对应的最新的版本信息在第二列表中继续查找，若在第二列表中查找到了版本信息，则将第一数据合并到第二数据中；若在第二列表中仍未查找到版本信息，则可确认版本管理工具的软件出现了异常。

基于上述步骤S1302至步骤S1306所限定的方案，可以获知，通过获取第一数据和第二数据，以及第二数据的版本信息，并依据第二数据的版本信息将第一数据合并至第二数据。其中，第一数据和第二数据用于合并操作。

容易注意到的是，由于是在第一列表中存储的是与目标分支有关的基线，而第二列表中存储的是与开发分布有关的基线，即在不同的基线列表中存储有不同的基线信息，从而可以有效的避免在同一个集成区内进行多次分支合并所造成的冲突问题。

本申请的上述方案可以达到在分支合并的过程中有效避免合并冲突的目的，从而实现了对基线进行有效管理的技术效果，进而解决了在合并分支的过程中易产生合并冲突的技术问题。

实施例8

根据本发明实施例，还提供了如图14所示的一种数据处理方法。其中，图14是根据本申请所提供的数据处理方法实施例的数据处理方法的流程图，如图14所示，该方法具体包括如下步骤：

步骤S1402，获取第一数据和第二数据，其中，第一数据、第二数据用于合并操作；

步骤S1404，获取第一列表，其中，第一列表包括第二数据的版本信息；

步骤S1406，确定第一列表中不存在将第一数据合并至第二数据所依据的版本信息；

步骤S1408，获取第二列表，其中,第二列表包括第一数据的版本信息；

步骤S1410，依据第二列表的版本信息，将第一数据合并至第二数据。

需要说明的是，上述第一数据包括：版本管理工具中的开发分支；第二数据包括以下至少之一：版本管理工具中的发布分支和主干分支，第一列表用于存储与目标分支有关的基线，第二列表用于存储与开发分支有关的基线，基线为软件文件或代码的基准版本。其中，版本管理工具可以为但不限于实现基线管理功能的SVN工具，例如，Versions工具。

此外，还需要说明的是，版本信息可以为将开发分支合并至目标分支的合并基线，版本信息包括：第一列表或第二列表中在预设时间段内发生变化后的版本信息。

在一种可选的实施例中，版本管理工具通过创建开发分支可以得到第一数据(例如，开发分支)，并通过创建发布分支或主干分支从而得到第二数据，其中，第二数据可以为发布分支和主干分支。然后根据第一数据在第一列表中查询是否存在将第一数据合并至第二数据所依据的版本信息，如果存在，则根据该版本信息将第一数据合并至第二数据；如果不存在，则继续在第二列表中查找版本信息；如果在第二列表中得到版本信息，则依据该版本信息将第一数据合并至第二数据。

此外，还需要说明的是，如果在第一列表和第二列表中均没有查询到版本信息，则版本管理工具可能发生了异常，此时，安装有版本管理工具的服务器或者用户终端向工作人员发出警告信息。

基于上述步骤S1402至步骤S1410所限定的方案，可以获知，通过获取第一数据和第二数据、以及第一列表，并确定第一列表中不存在将第一数据合并至第二数据所依据的版本信息；然后获取第二列表，并依据第二列表的版本信息将第一数据合并至第二数据，其中，第一数据、第二数据用于合并操作，第一列表包括第二数据的版本信息，第二列表包括第一数据的版本信息。

容易注意到的是，由于是在第一列表中存储的是与目标分支有关的基线，而第二列表中存储的是与开发分布有关的基线，即在不同的基线列表中存储有不同的基线信息，从而可以有效的避免在同一个集成区内进行多次分支合并所造成的冲突问题。

本申请的上述方案可以达到在分支合并的过程中有效避免合并冲突的目的，从而实现了对基线进行有效管理的技术效果，进而解决了在合并分支的过程中易产生合并冲突的技术问题。

实施例9

根据本发明实施例，还提供了如图15所示的一种数据处理方法。其中，图15是根据本申请所提供的数据处理方法实施例的数据处理方法的流程图，如图15所示，该方法具体包括如下步骤：

步骤S1502，客户端接收外部上传的待合并数据；

步骤S1504，客户端将待合并数据发送至服务器；

步骤S1506，服务器从第一列表中查询版本信息，其中，版本信息为将待合并数据合并至目标数据所依据的版本；在未从第一列表中查询到版本信息时，从第二列表中查询版本信息；在从第一列表或第二列表中查询到版本信息时，依据查找到的版本信息将待合并数据合并至目标数据。

需要说明的是，上述客户端为具有外部接口的客户端，可接收用户上传的待合并数据。在接收到待合并数据之后，客户端并不对待合并数据进行合并处理，而是将其发送至服务器，由服务器完成待合并数据的合并。此外，上述待合并数据属于版本管理工具中的开发分支，目标数据属于以下至少之一：版本管理工具中的发布分支和主干分支，版本信息包括：第一列表或第二列表中在预设时间段内发生变化后的版本信息。

在一种可选的实施例中，安装在服务器端版本管理工具(例如，TortoiseSVN工具和Versions工具)通过创建开发分支以得到开发分支，然后在确定开发分支所对应的版本、分支类型等信息，以及目标分支所对应的版本、分支类型等信息之后，版本管理工具根据上述信息从第一列表中所存储的多个合并基线确定是否存在开发分支合并时所使用的合并基线，如果第一列表中存在合并基线，则版本管理工具通过基于合并基线将开发分支合并至目标分支。如果第一列表中不存在合并基线，则版本管理工具根据在第一列表中查找到与开发分支所对应的最新的合并基线在第二列表中继续查找，若在第二列表中查找到了合并基线，则将开发分支合并到目标分支中；若在第二列表中仍未查找到合并基线，则可确认版本管理工具的软件出现了异常。

基于上述步骤S1502至步骤S1506所限定的方案，可以获知，通过客户端接收外部上传的待合并数据，并将待合并数据发送至服务器中，服务器从第一列表中查询版本信息，其中，版本信息为将待合并数据合并至目标数据所依据的版本。在未从第一列表中查询到版本信息时，从第二列表中查询版本信息；在从第一列表或第二列表中查询到版本信息时，依据查找到的版本信息将待合并数据合并至目标数据。

容易注意到的是，由于是在第一列表中存储的是与目标分支有关的基线，而第二列表中存储的是与开发分布有关的基线，即在不同的基线列表中存储有不同的基线信息，从而可以有效的避免在同一个集成区内进行多次分支合并所造成的冲突问题。

本申请的上述方案可以达到在分支合并的过程中有效避免合并冲突的目的，从而实现了对基线进行有效管理的技术效果，进而解决了在合并分支的过程中易产生合并冲突的技术问题。

在一种可选的实施例中，数据处理方法还包括：在从第一列表中查询到版本信息时，依据从第一列表中查询到的版本信息将待合并数据合并至目标数据；或者，步骤S1510，在从第二列表中未查询到版本信息时，则进行告警。

具体的，版本管理工具首先从第一列表中查询版本信息，如果版本管理工具从第一列表中查找到版本信息，则根据查找到的版本信息对待合并数据进行合并。如果版本管理工具从第一列表中未查找到版本信息，则版本管理工具继续从第二列表中查找版本信息。如果版本管理工具在第二列表中未查找到版本信息，则确认版本官本工具出现了异常，此时，服务器发出警报信息，其中，发出警报信息的途径可以为但不限于语音报警、在服务器的窗口上显示提示框。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可为个人计算机、服务器或者网络设备等)执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (19)

1.一种管理基线的方法，其特征在于，包括：

创建开发分支；

在第一基线列表中查找所述开发分支到目标分支的合并基线，其中，所述第一基线列表用于存储与所述目标分支有关的基线；

在未查找到所述合并基线时，从第二基线列表中查询所述合并基线，其中，所述第二基线列表中包括与所述开发分支有关的基线；

在查找到所述合并基线时，依据所述合并基线将所述开发分支合并至所述目标分支中。

2.根据权利要求1所述的方法，其特征在于，所述方法还包括：

将从所述目标分支所在管道模型进入下一管道模型时，将所述目标分支的内容更新至所述下一管道模型的分支中。

3.根据权利要求2所述的方法，其特征在于，将所述目标分支的内容更新至所述下一管道模型的分支中之后，所述方法还包括：

清空第一管道模型中的内容。

4.根据权利要求1所述的方法，其特征在于，依据所述合并基线将所述开发分支合并至所述目标分支中之前，所述方法还包括：

从与版本控制软件的主干关联的分支中选择一个分支作为所述目标分支。

5.根据权利要求1所述的方法，其特征在于，所述目标分支包括：发布分支和主干分支。

6.根据权利要求5所述的方法，其特征在于，所述第二基线列表中还包括：与所述发布分支有关的基线。

7.根据权利要求1所述的方法，其特征在于，在第一基线列表中查找到所述开发分支到目标分支的合并基线时，所述方法还包括：

从所述第一基线列表中选择最新的一条基线。

8.一种基线管理的装置，其特征在于，包括：

创建模块，用于创建开发分支；

第一查询模块，用于在第一基线列表中查找所述开发分支到目标分支的合并基线，其中，所述第一基线列表用于存储与所述目标分支有关的基线；

第二查询模块，用于在未查找到所述合并基线时，从第二基线列表中查询所述合并基线，其中，所述第二基线列表中包括与所述开发分支有关的基线；

合并模块，用于在查找到所述合并基线时，依据所述合并基线将所述开发分支合并至所述目标分支中。

9.一种存储介质，其特征在于，所述存储介质包括存储的程序，其中，在所述程序运行时控制所述存储介质所在设备执行权利要求1至7中任意一项所述的管理基线的方法。

10.一种处理器，其特征在于，所述处理器用于运行程序，其中，所述程序运行时执行权利要求1至7中任意一项所述的管理基线的方法。

11.一种管理基线的方法，其特征在于，包括：

在主干分支上创建多个开发分支；

对于每个开发分支，获取所述开发分支演进后的演进分支；

将所述演进分支合并到发布分支时，在第一基线列表中查找所述演进分支到目标分支的合并基线，其中，所述第一基线列表用于存储与所述目标分支有关的基线；

在未查找到所述合并基线时，从第二基线列表中查询所述合并基线，其中，所述第二基线列表中包括与所述开发分支有关的基线；

在查找到所述合并基线时，依据所述合并基线将所述演进分支合并至所述目标分支中。

12.一种数据处理方法，其特征在于，包括：

按照预设规则从第一基线列表和第二基线列表中确定合并基线的查找列表；其中，所述合并基线为将开发分支合并到目标分支所依据的基线，所述第一基线列表用于存储与所述目标分支有关的基线，所述第二基线列表用于存储与所述开发分支有关的基线，所述基线为软件文件或代码的基准版本；

在所述查找列表中查找到所述合并基线时，依据查找到的基线将所述开发分支合并至所述目标分支中。

13.一种数据处理方法，其特征在于，包括：

获取第一数据和第二数据，其中，所述第一数据、第二数据用于合并操作；

获取所述第二数据的版本信息；

依据所述第二数据的版本信息，将所述第一数据合并至第二数据。

14.一种数据处理方法，其特征在于，包括：

获取第一数据和第二数据，其中，所述第一数据、第二数据用于合并操作；

获取第一列表，其中，所述第一列表包括所述第二数据的版本信息；

确定第一列表中不存在将第一数据合并至第二数据所依据的版本信息；

获取第二列表，其中,所述第二列表包括所述第一数据的版本信息；

依据第二列表的版本信息，将所述第一数据合并至第二数据。

15.根据权利要求14所述的方法，其特征在于，所述第一数据包括：版本管理工具中的开发分支；所述第二数据包括以下至少之一：所述版本管理工具中的发布分支和主干分支。

16.根据权利要求15所述的方法，其特征在于，所述第一列表用于存储与目标分支有关的基线，所述第二列表用于存储与所述开发分支有关的基线，所述基线为软件文件或代码的基准版本。

17.一种数据处理方法，其特征在于，包括：

客户端接收外部上传的待合并数据；

所述客户端将所述待合并数据发送至服务器；

所述服务器从第一列表中查询版本信息，其中，所述版本信息为将所述待合并数据合并至目标数据所依据的版本；在未从所述第一列表中查询到所述版本信息时，从第二列表中查询所述版本信息；在从所述第一列表或第二列表中查询到所述版本信息时，依据查找到的版本信息将所述待合并数据合并至目标数据。

18.根据权利要求17所述的方法，其特征在于，所述方法还包括：

在从所述第一列表中查询到所述版本信息时，依据从所述第一列表中查询到的版本信息将所述待合并数据合并至所述目标数据；或者，

在从所述第二列表中未查询到所述版本信息时，则进行告警。

19.根据权利要求17所述的方法，其特征在于，所述版本信息包括：所述第一列表或第二列表中在预设时间段内发生变化后的版本信息。