CN115129362A - 一种代码修改方法、服务装置以及设备 - Google Patents
一种代码修改方法、服务装置以及设备 Download PDFInfo
- Publication number
- CN115129362A CN115129362A CN202110329141.8A CN202110329141A CN115129362A CN 115129362 A CN115129362 A CN 115129362A CN 202110329141 A CN202110329141 A CN 202110329141A CN 115129362 A CN115129362 A CN 115129362A
- Authority
- CN
- China
- Prior art keywords
- code
- library
- code library
- version
- modified
- 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
- 238000002715 modification method Methods 0.000 title claims abstract description 16
- 238000000034 method Methods 0.000 claims abstract description 64
- 230000004048 modification Effects 0.000 claims abstract description 45
- 238000012986 modification Methods 0.000 claims abstract description 40
- 230000008569 process Effects 0.000 claims abstract description 21
- 238000011161 development Methods 0.000 claims description 23
- 238000004590 computer program Methods 0.000 claims description 6
- 230000004044 response Effects 0.000 description 20
- 238000004891 communication Methods 0.000 description 15
- 238000010586 diagram Methods 0.000 description 13
- 238000012423 maintenance Methods 0.000 description 11
- 238000007726 management method Methods 0.000 description 6
- 230000006870 function Effects 0.000 description 5
- 230000009471 action Effects 0.000 description 4
- 230000001960 triggered effect Effects 0.000 description 3
- 230000003287 optical effect Effects 0.000 description 2
- 238000005457 optimization Methods 0.000 description 2
- 238000004458 analytical method Methods 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 230000037361 pathway Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 238000013403 standard screening design Methods 0.000 description 1
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/72—Code refactoring
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
-
- 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)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Stored Programmes (AREA)
Abstract
一种代码修改方法、服务装置以及设备,用以实现代码合并。该方法中,服务端在接收客户端端请求后,向客户端提供第一代码库;之后,客户端可以对该第一代码库进行修改。向服务端发送修改后的第一代码库。服务端利用修改后的第一代码库更新服务端存储的第一代码库,将第二代码库中的代码与修改后的第一代码库中的代码进行合并,生成第一合并代码版本,保存第一合并代码版本。服务端在客户端每次对第一代码库进行修改的情况下,生成对应的合并代码版本,保证能够记录每次对第一代码库修改后所对应的代码版本,以便后续能够对不同修改阶段的代码版本进行查看。
Description
技术领域
本申请涉及软件开发领域,尤其涉及一种代码修改方法、服务装置以及设备。
背景技术
在代码开发过程中,较为常见是利用一个独立的代码库,如git库,来对待开发的代码进行管理。但当待开发的代码较为庞大时,也可以创建多个代码库,可以并行地对该多个代码库进行修改,实现代码的开发。
在这种方式中,由于涉及到多个代码库,经常需要同时对该多个代码库中的代码进行修改。目前,通过多个代码库进行协同开发的过程中,利用客户端已部署的专用工具,如git-repo,能够将多个代码库下载到客户端,并在修改之后向服务端推送仓库的修改。但这种方式中,在对代码库中的代码修改之后,服务端会利用修改后的代码库覆盖已保存的代码库,当进行多次代码修改后,中间修改的代码版本可能会丢失。或者若用户需要某一次修改的代码版本通常需要是由用户自行处理。
发明内容
本申请提供一种代码修改方法、服务装置以及设备,用以实现代码合并。
第一方面,本申请实施例提供了一种代码修改方法,所述方法应用于代码管理系统,所述代码管理系统包括客户端和服务端,服务端存储有存在关联的第一代码库和第二代码库,在该方法中,客户端可以向服务端请求第一代码库,服务端在接收客户端的请求后,可以向客户端提供第一代码库;客户端在获取该第一代码库后,客户端可以对该第一代码库进行修改。之后,客户端向服务端发送修改后的第一代码库。服务端从客户端获取修改后的第一代码库后,可以利用修改后的第一代码库更新服务端存储的第一代码库;还可以将第二代码库中的代码与修改后的第一代码库中的代码进行合并,生成第一合并代码版本,保存第一合并代码版本。服务端可以创建合并代码库,专用于存储各个合并代码版本,也即服务端在生成了第一合并代码版本后,可以将第一合并代码版本保存在合并代码库中。
通过上述方法,服务端在客户端每次对第一代码库进行修改的情况下,可以利用修改后的第一代码库更新服务端存储的第一代码库,还可以生成对应的合并代码版本,保证能够记录每次对第一代码库修改后所对应的代码版本,以便后续能够对各修改阶段的代码版本进行查看。
一种可能的实施方式中,之后若客户端对第一代码库中的代码再次进行修改,或对第二代码库进行修改,服务端可以在获取修改后的第一代码库或第二代码库后,可以再次更新服务端存储的第一代码库,或更新第二代码库,并对更新后的第一代码库和第二代码库进行合并,生成第二合并代码版本,保存第二合并代码版本,该第二合并代码版本可以存储在合并代码库中。
通过上述方法,服务端可以每对存储有多个代码库中的任一代码库更新一次后,可以对更新后的、存在关联的多个代码库进行合并,生成一个合并代码版本,并进行保存,这样可以查看任一合并代码版本,还可以达到代码版本回退的效果。
一种可能的实施方式中,第一代码库和第二代码库之间存在关联,第一代码库和第二代码库之间关联关系可以为如下三种的任一种:
第一种、第一代码库中的代码和第二代码库中的代码中存在相同的代码元素,修改后的第一代码库中被修改的代码中包括相同的代码元素。
第二种、第一代码库中的代码第二代码库中的代码为应用中实现不同功能组件的代码。例如,第一代码库中的代码为应用中实现第一功能组件的代码,第二代码库中的代码是应用中用于实现第二功能组件的代码,第一合并代码版本表示应用的版本快照。
第三种、第一代码库中的代码和第二代码库中的代码包括下列的部分或全部:代码开发过程中的原始代码的主干代码、由主干代码延伸的至少一个分支代码。
通过上述方法,第一代码库和第二代码库之间可以存在多种不同的关联方式,适用于不同的应用场景,扩展了应用范围。
一种可能的实施方式中,服务端在生成了第一合并代码版本后,可以向客户端提供第一合并代码版本的标识。本申请实施例并不限定第一合并代码版本的标识的类型,凡是能够唯一标识该第一合并代码版本的信息均可以作为第一合并代码版本的标识。
通过上述方法,服务端能够向客户端提供第一合并代码版本的标识,能够便于客户端可以利用该标识请求第一合并代码版本。
一种可能的实施方式中,客户端可以向服务端发送查询请求,该查询请求可以携带第一合并代码版本的标识,服务端在从客户端接收到查询请求后,可以向客户端提供第一合并代码版本。
通过上述方法,客户端可以利用第一合并代码版本的标识查询第一合并代码版本,查询方式简单快捷。
一种可能的实施方式中,服务端在对第二代码库中的代码与修改后的第一代码库中的代码进行合并时,可以是自行对第二代码库中的代码与修改后的第一代码库中的代码进行合并,也可以在客户端的指示下,对第二代码库中的代码与修改后的第一代码库中的代码进行合并。
通过上述方法,服务端可以灵活的对第二代码库中的代码与修改后的第一代码库中的代码进行合并,可以适用于不同的场景。
第二方面,本申请实施例还提供了一种服务装置,服务装置存储有第一代码库和第二代码库,服务装置包括发送模块、接收模块、更新模块以及合并模块。
发送模块,用于向客户端提供第一代码库。
接收模块,用于从客户端获取修改后的第一代码库。
更新模块,用于利用修改后的第一代码库更新服务装置存储的第一代码库。
合并模块,用于将第二代码库中的代码与修改后的第一代码库中的代码进行合并,生成第一合并代码版本,保存第一合并代码版本。
一种可能的实施方式中,服务装置还保存第二合并代码版本,第二合并代码版本是在更新后的第一代码库被再次修改,和/或,第二代码库被修改,且更新模块再次更新了第一代码库和/或第二代码库后,合并模块对第一代码库中的代码和第二代码库中的代码合并生成的。
一种可能的实施方式中,第一代码库和第二代码库之间存在关联,第一代码库和第二代码库之间关联关系可以为如下三种的任一种:
第一种、第一代码库中的代码和第二代码库中的代码中存在相同的代码元素,修改后的第一代码库中被修改的代码中包括相同的代码元素。
第二种、第一代码库中的代码第二代码库中的代码为应用中实现不同功能组件的代码。例如,第一代码库中的代码为应用中实现第一功能组件的代码,第二代码库中的代码是应用中用于实现第二功能组件的代码,第一合并代码版本表示应用的版本快照。
第三种、第一代码库中的代码和第二代码库中的代码包括下列的部分或全部:代码开发过程中的原始代码的主干代码、由主干代码延伸的至少一个分支代码。
一种可能的实施方式中,发送模块还可以向客户端提供第一合并代码版本的标识。
一种可能的实施方式中,接收模块还可以从客户端接收到携带有第一合并代码版本的标识的查询请求;之后,发送模块可以向客户端提供第一合并代码版本。
一种可能的实施方式中,合并模块在对第二代码库中的代码与修改后的第一代码库中的代码进行合并时,可以自行对第二代码库中的代码与修改后的第一代码库中的代码进行合并,也可以在客户端的指示下,对第二代码库中的代码与修改后的第一代码库中的代码进行合并。
第三方面,本申请还提供了一种计算设备,所述计算设备包括处理器和存储器,还可以包括通信接口,所述处理器执行所述存储器中的程序指令执行上述第一方面或第一方面任一可能的实现方式提供的方法中服务端执行的方法。所述存储器与所述处理器耦合,其保存代码修改的过程中必要的程序指令和数据。所述通信接口,用于与其他设备进行通信,如发送第一代码库、第一合并代码版本的标识以及第一合并代码版本,以及接收查询请求。
第四方面,本申请提供了一种计算设备系统,该计算设备系统包括至少一个计算设备。每个计算设备包括存储器和处理器。至少一个计算设备的处理器用于访问所述存储器中的代码以执行第一方面或第一方面的任意一种可能的实现方式提供的方法中服务端执行的方法。
第五方面,本申请提供了一种非瞬态的计算机可读存储介质,所述非瞬态的计算机可读存储介质被计算设备执行时,所述计算设备执行前述第一方面或第一方面的任意可能的实现方式中提供的方法。该存储介质中存储了程序。该存储介质包括但不限于易失性存储器,例如随机访问存储器,非易失性存储器,例如快闪存储器、硬盘(hard disk drive,HDD)、固态硬盘(solid state drive,SSD)。
第六方面,本申请提供了一种计算设备程序产品,所述计算设备程序产品包括计算机指令,在被计算设备执行时,所述计算设备执行前述第一方面或第一方面的任意可能的实现方式中提供的方法。该计算机程序产品可以为一个软件安装包,在需要使用前述第一方面或第一方面的任意可能的实现方式中提供的方法的情况下,可以下载该计算机程序产品并在计算设备上执行该计算机程序产品。
附图说明
图1为一种代码修改方法示意图;
图2A~图2C为本申请提供的一种系统的架构示意图;
图3为本申请提供的一种代码修改方法的流程图;
图4为本申请提供的一种选择代码库的界面示意图;
图5为本申请提供的一种展示第一代码库的界面示意图;
图6A~图6B为本申请提供的一种修改代码的界面示意图;
图7A~图7C为本申请提供的一种提交或合并代码的界面示意图;
图8为本申请提供的一种代码修改方法的流程图;
图9为本申请提供的一种代码修改方法的流程图;
图10A为本申请提供的另一种展示第一代码库的界面示意图;
图10B为本申请提供的一种选择合并代码版本的界面示意图;
图11为本申请提供的一种服务装置的结构示意图;
图12为本申请提供的一种客户装置的结构示意图;
图13~图14为本申请实施例提供的一种计算设备的结构示意图。
具体实施方式
为方便理解,对本申请实施例提供的一种代码修改方法介绍之前,先对本申请实施例涉及的概念进行说明。
(1)、代码库
在本申请实施例中,服务端存储代码是以代码库为粒度进行存储的。代码库是用于存储代码的容器。在需要获取代码时,可以通过代码库的标识定位代码所在的代码库。代码库的标识可以是在创建代码库时配置的,本申请实施例并不限定代码库的标识类型或构成,凡是能够唯一标识该代码库的信息均适用于本申请实施例。
代码库作为存储代码的容器,可以是文件,也可以是git库,凡是能够存储代码的容器均可以作为代码库。
(2)、关联的多个代码库
在本申请实施例中,当存在关联的多个代码库(如第一代码库、第二代码库以及第三代码库)中的部分或全部被更新时,服务端能够对更新后的该多个代码库中的代码进行合并。多个代码库之间的关联方式有很多种,列举其中三种。
这里以该多个代码库中的第一代码库和第二代码库为例,对多个代码库可能存在的三种关联方式进行说明。
第一种、第一代码库中的代码和第二代码库中的代码中存在相同的代码元素。代码元素为代码中的最小单元,代码元素包括类、包、函数/方法、域/变量等。
当第一代码库的代码被修改时,若涉及修改的部分涉及到该相同的代码元素,为了保持一致,第二代码库中相同的代码元素也可以被更新。
第二种、第一代码库和第二代码库中的代码是同一应用的代码,该第一代码库和第二代码库中的代码可以用于实现该应用的不同功能组件,如第一代码库中的代码为应用中实现第一功能组件的代码,第二代码库中的代码是该应用中用于实现第二功能组件的代码。
第一代码库(或修改后的第一代码库)和第二代码库(或修改后的第二代码库)每次合并,所生成的合并代码版本为该应用的版本快照,用于记录该应用在经过一次修改后的代码,服务端也可以记录合并代码版本的相关信息,如合并时间、合并版本号等。
第一代码库和第二代码库中的代码是同一应用的不同代码,当第一代码库和第二代码库中的任一代码库被修改时,需要及时的生成相应的应用的版本快照,也即合并代码版本。
第三种、第一代码库中的代码和第二代码库中的代码包括下列的部分或全部:
代码开发过程中的原始代码的主干代码、由主干代码延伸的至少一个分支代码。
对于一个较为庞大的原始代码,原始代码可以被划分为主干代码以及由主干代码延伸的至少一个分支代码。在代码开发过程中,主干代码和该至少一个分支代码可以对一个或多个运维团队设置不同的修改开发权限。如主干代码可以对各个运维团队开放修改开放权限,也即各个运维团队均能够对主干代码进行修改、优化等代码开发操作。每个分支代码可以只对特定的一个或多个运维团队开放修改开放权限,不同的分支代码可以开发给不同的运维团队,也即只有该特定的一个或多个运维团队才能对该分支代码进行修改、优化等代码开发操作。
无论是主干代码,还是任一分支代码被修改的情况下,原始代码将会发生变化,变成另一个版本的代码。在本申请实施例中,当第一代码库和/或任第二代码库被修改时,将会在服务端生成相应的合并代码版本,该合并代码版本即为原始代码的一个版本。
(3)、代码合并、合并代码版本(如第一合并代码版本、第二合并代码版本)
代码合并过程实际上是对多个代码库的整合过程,对于存在关联的多个代码库,每经过一次修改,该多个代码库构成的代码整体在功能或实现上可能会发生改变,为此,可以在没经过一次修改后,对修改之后的多个代码库进行合并,生成合并代码版本。
也就是说,合并代码版本是多个代码库中的代码合并后所形成的代码,该合并代码版本可以显示出合并是该多个代码库中的代码,本申请实施例并不限定该合并代码版本的表现形式,例如该合并代码版本可以以.cpp的文件形式呈现,也可以以代码快照的方式呈现。
(4)、合并代码库
在本申请实施例中,合并代码库是用于存储合并代码版本的容器,这里并不限定该容器的类型,例如,可以为git库,也可以为文件夹。
如图1所示,为常见的一种多个代码修改方式,用户可以通过专用工具(如gitrepo)从服务端将多个代码库的下载到客户端(步骤101),在客户端完成修改(步骤102)后,再利用该专用工具将修改后的代码库推送(步骤103)到服务端。
运维人员可以在对该多个代码库修改之后,通过客户端从服务端获取修改后的代码库,查看修改后的代码库,并决定是否该多个代码库进行合并。
这种方式存在一种弊端,在多个代码库进行多次修改后,每次修改都会将之前的代码库覆盖,运维人员当前所能查看的代码库是经过了多次修改后的代码库。而在代码开发过程中,往往需要实现代码版本回退,也即可能存在需要查看未经过修改的合并代码版本或者在经过某一次或几次修改之后的合并代码版本。对于多个运维团队参与代码开发的过程中,每个运维团队对相应代码库中的代码开发的时机、修改的内容均可能不同。每修改一次,实际上是会存在对应的一种版本的代码,这些版本的代码有利于后续运维人员对代码进行进一步分析,以实现代码优化。
可见代码版本回退的重要性,但鉴于目前合并代码版本的方式,合并代码版本只能是当前代码库合并后的代码,之后无法实现代码回退,查看历史代码修改过程。
为此,本申请实施例提供了一种代码修改方法,该方法应用于代码管理系统,在该方法中,代码管理系统中的服务端存储有多个存在关联的代码库,可以向代码管理系统中的客户端提供代码库,还能够从该客户端获取修改后的代码库,利用修改后的代码库更新服务端存储的代码库,还可以将修改后的代码库与其他关联的代码库进行合并,生成合并代码版本,保存合并代码版本。在本申请实施例中,服务端在代码库存在修改时,能够自行实现代码合并,并且保存合并代码版本,保证代码库的代码可以及时合并,并可以通过保存该合并代码版本可以记录此次修改中各个代码库中代码的状态,以便实现代码版本回退。
如图2A所示为本申请实施例提供的一种代码管理系统架构示意图,该代码管理系统中包括服务端100和客户端200。
客户端200部署在用户侧,用于在用户的触发下向服务端100发起请求。本申请实施例并不限定客户端200的具体形态,例如客户端200可为用户的本地计算设备(例如:个人电脑、手机、平板等)或运行在设备中的专用客户端软件。
本申请以客户端200为用户的本地计算设备为例进行说明,客户端200上可以部署有代码修改软件,用户可以通过设置代码修改软件触发客户端200与服务端100进行通信。例如,用户可以通过该代码修改软件使得该客户端200能够与服务端100连接,之后,通过代码修改软件触发客户端200从服务端100请求代码库。用户还可以在代码修改软件中对代码库中的代码进行修改,在本地修改了代码库中的代码后可以向服务端100提交修改后的代码库,或指示服务端100对代码库中的代码进行合并。
在本申请实施例中服务端100中存储有存在关联的多个代码库,服务端100可以在客户端200的请求下,向客户端200发送代码库,还可以在接收到客户端200发送的修改后的代码库后,更新本地服务端100的代码库,也可以对存在关联的多个代码库进行合并,生成合并代码版本,保存合并代码。
本申请实施例并不限定服务端100的部署位置,例如服务端100可以部署在边缘数据中心,也可以部署在云数据中心中,也可以部署在终端计算设备上。服务端100也可以分布式的部署在边缘数据中心、云数据中心以及终端计算设备中的部分或全部环境中。
服务端100既可以是一个硬件装置,例如:服务器、终端计算设备等,也可以是一个软件装置,具体为运行在硬件计算设备上的一套软件系统。本申请实施例中并不限定服务端100所部署的位置。示例性的,如图2B所示,服务端100可以部署在云计算设备系统(包括至少一个云计算设备,例如:服务器等),也可以部署在边缘计算设备系统(包括至少一个边缘计算设备,例如:服务器、台式电脑等),也可以部署在各种终端计算设备上,例如:笔记本电脑、个人台式电脑等。
服务端100在逻辑上也可以是由多个模块构成的装置,如服务端100可以包括接收模块、更新模块、合并模块、发送模块,服务端100中的各个组成部分可以分别部署在不同的系统或服务器中。示例性的,如图2C所示,装置的各部分可以分别运行在云计算设备系统、边缘计算设备系统或终端计算设备这三个环境中,也可以运行在这三个环境中的任意两个中。云计算设备系统、边缘计算设备系统和终端计算设备之间由通信通路连接,可以互相进行通信和数据传输。本申请实施例提供的代码修改方法中服务端100执行的方法可以由运行在三个环境(或三个环境中的任意两个)中的服务端100的各组合部分配合执行。
本申请实施例并不限定服务端100的部署方式,例如服务端100可以为部署在云端的应用程序,为能够为用户提供云服务,也即该服务端100可以部署在边缘计算设备系统或云计算系统中,用户可以通过部署在用户侧的客户端200从该服务端100获取该云服务。
下面结合附图对本申请实施例提供的一种代码修改方法进行说明,在本申请实施例中客户端200侧可以对一个代码库进行修改,也可以对多个代码库进行修改,下面先对客户端200对一个代码库进行修改并请求服务端100进行代码合并的方式进行说明:
第一种代码修改方式:客户端200对一个代码库进行修改并请求服务端100进行代码合并。
如图3所示,为本申请实施例提供的一种代码修改方法,该方法包括:
步骤301:客户端200向服务端100请求第一代码库。
客户端200可以向用户展示在服务端100中存储的多个代码库,如图4所示,为客户端200向用户展示代码库的界面示意图。客户端200可以向用户展示代码库列表,该代码库列表中包括服务端100中存储的多个代码库的标识,用户可以请求任意一个代码库,例如:第一代码库,示例性地,用户可以控制光标移动到第一代码库的标识上,通过点击标识或打开属性框的方式,选择展示该第一代码库中的代码。在图4所示的界面中,当用户选定第一代码库时,还可以展示第一代码库的一些属性信息,如第一代码库中的代码所属的原始代码,以及第一代码库中代码所在分支的编号等信息。
本申请实施例并不限定代码库的标识的具体类型,例如可以是预先为代码库配置的编号。又例如,当该代码库中的代码为原始代码中的某一个分支时,该代码库的标识也可以由原始代码的标识以及分支的标识构成,凡是能够唯一标识该代码库的信息均可以作为代码库的标识。
客户端200在检测到用户的操作后,确定需要展示第一代码库中的代码,可以向服务端100发起代码库获取请求,该代码库获取请求用于请求获取第一代码库中的代码,该代码库获取请求中可以携带第一代码库的标识。
上述用户通过客户端200显示的界面触发客户端200向服务端100请求第一代码库的方式仅是举例,在本申请实施例,并不限定客户端200执行步骤301的具体方式。
步骤302:服务端100向客户端200发送该第一代码库。
服务端100在接收到客户端200发送的代码库获取请求后,可以从代码库获取请求中获取第一代码库的标识,根据第一代码库的标识从服务端100存储的多个代码库中确定第一代码库。
服务端100在确定了第一代码库后,可以向客户端200发送代码库获取响应,该代码库获取响应中可以包括第一代码库,也即携带第一代码库中的代码,可选的,代码库获取响应中还可以包括第一代码库的标识。该代码库获取响应中还可以携带第一代码库的相关信息,例如可以携带与第一代码库存在关联的代码库的标识。又例如,若该第一代码库中的代码为某一个原始代码中的分支,该代码库获取响应中还可以携带该原始代码的标识。又例如,若该第一代码库之前被修改,该代码库获取响应中能够还可以携带历史修改信息,如修改时间、修改位置、修改前后的代码等。
步骤303:客户端200获取该第一代码库后,向用户展示该第一代码库。
客户端200在接收带代码库获取响应后,从代码库获取响应中获取第一代码库,并向用户展示该第一代码库。如图5所示,当用户控制光标在客户端200所展示的界面中点击了该第一代码库后,在界面的右侧窗口可以展示该第一代码库,在右侧窗口中,可以展示该第一代码库中的代码。
客户端200除了展示该第一代码库中的代码,还可以向用户展示该第一代码库的相关信息,如图5所示,在右侧窗口的上方可以显示关联代码库、原始代码、以及历史修改信息等选项,用户可以通过点击这些选项查看相应信息。
上述展示第一代码库的方式仅是举例,本申请实施例并不限定客户端200向用户展示第一代码库的方式。
步骤304:客户端200修改第一代码库中的代码。
当客户端200向用户展示了该第一代码库后,用户可以通过操作该客户端200,对该第一代码库中的代码进行修改。
如图6A所示,用户可以在展示该第一代码库的界面中,选择需要修改的代码,直接在该键入新的代码,客户端200在检测到用户的操作后,响应于该用户的操作对第一代码库中的代码进行修改。
在图6B中,在展示该第一代码库的界面中设置有修改选项,用户选择需要修改的代码,并点击修改选项,在展示该第一代码库的界面中出现修改窗口。用户可以在该修改窗口中键入新的代码。客户端200在检测到用户的操作(如键入新的代码)后,响应于该用户的操作对第一代码库中的代码进行修改。
当用户在未选择修改的代码,直接点击修改选项,则说明需要对该第一代码库中的所有代码进行修改,用户在该修改窗口中键入新的代码。这种情况下,第一代码库中的所有代码需要变为该新的代码。客户端200在检测到用户的操作(如键入新的代码)后,响应于该用户的操作将第一代码库中的代码替换为该新的代码。
本申请实施例并不限定对第一代码库中的代码的修改方式,例如可以变更第一代码库中的代码中的一些代码元素,也可以在第一代码库中的代码中增加新的代码,还可以删除第一代码库中的部分代码。
步骤305:客户端200向服务端100提交修改后的第一代码库。
用户在键入新的代码后,可以触发客户端200向服务端100提交修改后的第一代码库。在一种实施例中,如图7A所示,在展示第一代码库的界面上设置有提交选项。用户可以点击提交选项。客户端200在检测到用户的操作后,可以向服务端100提交修改后的第一代码库。客户端200可以向服务端100发送代码库更新请求,该代码库更新请求用于请求更新该第一代码库,该代码库更新请求中可以携带修改后的第一代码库,还可以携带第一代码库的标识。
步骤306:服务端100在从客户端200接收到修改后的第一代码库后,利用修改后的第一代码库更新本地存储的第一代码库,并对修改后的第一代码库中的代码与第二代码库中的代码进行合并。该第二代码库是与第一代码库关联的代码。
服务端100在接收到代码库更新请求后,从该代码库更新请求中获取修改后的第一代码库,将服务端100存储的第一代码库中替换为修改后的第一代码库,服务端100还记录该第一代码库的修改信息,如修改时间、修改位置、修改前后的代码等。
服务端100还可以将修改后的第一代码库中的代码与第二代码库中的代码进行合并,服务端100可以自行对修改后的第一代码库中的代码与第二代码库中的代码进行合并,也可以是在客户端200的指示下,对修改后的第一代码库中的代码与第二代码库中的代码进行合并。
方式一、服务端100可以自行对修改后的第一代码库中的代码与第二代码库中的代码进行合并。
在服务端100可以预先记录代码库的关联关系,该代码库的关联关系指示了各个代码库之间关联关系,服务端100通过解析代码库的关联关系,可以确定与第一代码库关联的第二代码库。
需要说明的是,代码库的关联关系可以是预先配置的,也可以是用户通过客户端200发送给服务端100的。
服务端100在更新了服务端100存储的第一代码库后,可以对修改后的第一代码库中的代码与第二代码库中的代码进行合并,生成第一合并代码版本。
当第一代码库中的代码和第二代码库中的代码中存在相同的代码元素时,若修改后的第一代码库中该代码元素变更了,在合并时,第二代码库中相同的代码元素也需要进行变更,之后将修改后的第一代码库中的代码与第二代码库中的代码整合在一起,生成第一合并代码版本。
当第一代码库和第二代码库中的代码是同一应用中用于实现不同功能组件的代码,服务端100可以在更新了服务端100存储的第一代码库,将修改后的第一代码库和第二代码库中的代码直接整合在一起,形成该应用的一个版本的代码快照,该代码快照即为第一合并代码版本。
当第一代码库中的代码和第二代码库中的代码为原始代码的主干代码或分支代码。
服务端100可以在更新了服务端100存储的第一代码库,将修改后的第一代码库和第二代码库中的代码整合在一起,形成该原始代码的一个版本,该版本即为第一合并代码版本。
方式二、服务端100在客户端200的指示下,对修改后的第一代码库中的代码与第二代码库中的代码进行合并。
客户端200除了向服务端100提交修改后的第一代码库之外,还可以指示服务端100将修改后的第一代码库的代码与其他代码库中的代码进行合并,本申请实施例并不限定该其他代码库的数量,可以是一个,也可以是多个。为方便说明,本申请实施例中以其他代码库为第二代码库为例进行说明。
在一种可能的实施例中,如图7B所示,在展示第一代码库的界面上除了设置有提交选项,还可以设置有合并选项。用户可以点击提交选项。客户端200在检测到用户的操作后,可以向服务端100提交修改后的第一代码库。如客户端200可以向服务端100发送代码库更新请求,该代码库更新请求用于请求更新该第一代码库,该代码库更新请求中可以携带修改后的第一代码库,还可以携带第一代码库的标识。
用户可以点击合并选项。客户端200在检测到用户的操作后,可以指示服务端100将修改后的第一代码库中的代码和第二代码库中的代码进行合并。如客户端200可以向服务端100发送代码合并请求,该代码合并请求用于请求服务端100对修改后的第一代码库中的代码与第二代码库中的代码进行合并。服务端100侧可以记录代码库的关联关系,在这种情况下,代码合并请求中可以不包括第二代码库的标识,服务端100可以通过解析代码库的关联关系,确定与第一代码库关联的第二代码库。
作为一种可能的实施方式,用户在可以点击合并选项时,可以触发客户端200向服务端100提交修改后的第一代码库,又可以指示服务端100对修改后的第一代码库中的代码与第二代码库中的代码进行合并。例如,客户端200可以向服务端100发送代码库更新及合并请求。代码库更新及合并请求携带有修改后的第一代码库,代码库更新及合并请求用于请求更新第一代码库、对修改后的第一代码库中的代码与第二代码库中的代码进行合并。
服务端100侧可以记录代码库的关联关系,在这种情况下,代码更新及合并请求中可以不包括第二代码库的标识,服务端100可以通过解析代码库的关联关系,确定与第一代码库关联的第二代码库。
在上述说明中均是以与第一代码库关联的第二代码库是服务端100自行确定为例,在一些场景中,用户也可以自行选择与第一代码库关联的第二代码库。
如图7C所示,在展示第一代码库的界面上设置有合并选项,用户在点击合并选项后,客户端200可以向用户展示与第一代码库关联的代码库标识列表,用户可以自行从该代码库标识列表中选择一个或多个代码库作为第二代码库。
用户在选择了第二代码库之后,可以点击“确定”,客户端200在检测到用户的操作后,可以发送代码库更新及合并请求,该代码库更新及合并请求可以请求更新第一代码库,以及指示服务端100对修改后的第一代码库中的代码和第二代码库中的代码进行合并,代码库更新及合并请求中可以包括修改后的第一代码库、第一代码库的标识以及第二代码库的标识,该第二代码库的标识用于指示需要与第一代码库关联的代码库。
服务端100对修改后的第一代码库中的代码与第二代码库中的代码进行合并,生成第一合并代码版本,可以参见前述说明,此处不再赘述。
当修改后的第一代码库需要与多个代码库中的代码合并时,修改后的第一代码库与多个代码库中的代码合并的方式与第一代码库与第二代码库中的代码合并的方式相同,区别在于需要合并的代码库的数量不同。
服务端100在生成第一合并代码版本后,还可以保存该第一合并代码版本,该第一合并代码版本可以存储的合并代码库中,该合并代码库中还可以记录第一合并代码版本的相关信息,如各个代码库的标识、合并时间等。
当服务端100接收到代码库更新请求时,服务端100在更新本地存储的第一代码库后,服务端100可以向客户端200反馈代码库更新响应,用于指示第一代码库更新成功。
当服务端100接收到代码库合并请求时,服务端100在生成第一合并代码版本后,服务端100可以向客户端200反馈代码库合并响应,用于指示对代码库合并完成,该代码库合并响应还可以携带有第一合并代码版本的标识,本申请实施例并不限定第一合并代码版本的标识的类型,例如,该第一合并代码版本的标识可以是原始代码的版本号或应用的版本号,凡是能够标识该第一合并代码版本的信息均适用于本申请实施例。
当服务端100接收到代码库更新及合并请求时,服务端100在更新本地存储的第一代码库以及生成第一合并代码版本后,服务端100可以向客户端200反馈代码库更新及合并响应,用于指示第一代码库更新成功以及对代码库合并完成,该代码库更新及合并响应还可以携带有第一合并代码版本的标识。
第二种代码修改方式:客户端200对多个代码库进行修改并请求服务端100进行代码合并。
如图8所示,以客户端200对两个代码库(分别为第一代码库和第二代码库)进行修改为例,为本申请实施例提供的一种代码修改方法,该方法包括:
步骤801:客户端200向服务端100请求第一代码库和第二代码库。客户端200向服务端100请求第一代码库和第二代码库方式与步骤301的方式类似,具体可以参见前述说明,此处不再赘述。
步骤802:服务端100向客户端200发送该第一代码库和第二代码库。步骤802与步骤302的方式类似,具体可以参见前述说明,此处不再赘述。
步骤803:客户端200获取该第一代码库和第二代码库后,向用户展示该第一代码库和第二代码库。步骤803与步骤303的方式类似,具体可以参见前述说明,此处不再赘述。
步骤804:客户端200修改第一代码库中的代码和第二代码库中的代码。客户端200修改第一代码库中的代码和第二代码库中的代码的方式与步骤304中客户端200修改第一代码库中的代码的方式类似,具体可以参见前述说明,此处不再赘述。
步骤805:客户端200向服务端100提交修改后的第一代码库和第二代码库。
客户端200提交修改第一代码库中的代码和第二代码库中的代码的方式与步骤305中客户端200提交修改第一代码库中的代码的方式类似,具体可以参见前述说明,此处不再赘述。
需要说明的是,当客户端200需要合并修改后的第一代码库和修改后的第二代码库中的代码时,客户端200可以采用与步骤305类似的方式,用户在提交了修改后的第一代码库和修改第二代码库后,在第一代码库的展示界面中选择合并选项,触发客户端200指示服务端100对修改后的第一代码库中的代码和第二代码库中的代码进行合并。在该场景下,服务端100预先配置代码库的关联关系,用户通过客户端200提交了修改后的第一代码库和修改第二代码库后,在第一代码库的展示界面中选择合并选项后,服务端100可以自行对修改后的第一代码库和修改后第二代码库进行合并,也即不需要客户端200明确指示与第一代码库合并的代码库的标识,仅需指示需要对第一代码库进行合并。
用户也可以在选择合并选项后,点击需要与第一代码库合并的第二代码库的标识,触发客户端200指示服务端100对修改后的第一代码库中的代码和第二代码库中的代码进行合并。当客户端200需要合并的代码库中除了修改后的第一代码库、修改后的第二代码库,还有第三代码库时,客户端200可以采用与步骤305类似的方式,用户在提交了修改后的第一代码库和修改第二代码库后,在第一代码库的展示界面中选择合并选项,选择需要与第一代码库合并的第二代码库的标识和第三代码库的标识,触发客户端200指示服务端100对修改后的第一代码库中的代码、修改后的第二代码库以及第三代码库中的代码进行合并。
步骤806:服务端100利用修改后的第一代码库更新服务端100存储的第一代码库,利用修改后的第二代码库更新服务端100存储的第二代码库,并对修改后的第一代码库中的代码与修改后的第二代码库中的代码进行合并。
服务端100更新服务端100存储的第一代码库和第二代码库的方式与步骤306中服务端100更新服务端100存储的第一代码库的方式类似,具体可以参见前述内容,此处不再赘述。
服务端100在对修改后的第一代码库中的代码与修改后的第二代码库中的代码进行合并生成第二合并代码版本,该第二合并代码版本可以存储在合并代码版本路中。服务端100生成第二合并代码版本的方式与步骤306中服务端100生成第一合并代码版本的方式类似,具体可以参见前述内容。
采用上述类似的方式,用户可以通过客户端200继续对第一代码库和第二代码库进行修改,如用户可以通过客户端200继续对第一代码库或第二代码库进行修改,并向服务端100提交修改后的第一代码库或第二代码库,服务端100可以更新服务端100存储的第一代码库或第二代码库,并对更新后的第一代码库或第二代码库、与其关联代码库进行合并,生成第三合并代码版本,保存第三合并代码版本。可见,每次修改,均会生成对应的合并代码版本,保存在合并代码库中。
如图9所示,为本申请实施例提供的一种代码修改方法的流程示意图,图9中以代码库为git库为例,在服务端100可以记录代码库的关联关系,记录的方式可以如下:
上述信息指示了代码库X、代码库Y以及代码库Z之间的存在关联,代码库X、代码库Y以及代码库Z的地址(https://git@hostname_of_server)以及代码库X、代码库Y以及代码库Z所属的原始代码(master)。
以用户对存在关联的代码库X、代码库Y以及代码库Z均进行修改。首先,用户通过客户端200向服务端100请求代码库X、代码库Y以及代码库Z。
键入的命令以及输出的信息如下:
$git mm init-u https://hostname_of_server/repos/manifest.git-mdefault.xml
INFO:manifest repository has been initialized
$git mm sync
INFO:Syncing working directory:x
INFO:Syncing working directory:y
INFO:Syncing working directory:z
通过访问代码库X、代码库Y以及代码库Z的地址(https://git@hostname_of_server),以请求获取代码库X、代码库Y以及代码库Z。
当客户端200从服务端100获取了代码库X、代码库Y以及代码库Z(对应步骤1)后,可以向用户展示该代码库X、代码库Y以及代码库Z。用户在客户端200对该代码库X、代码库Y以及代码库Z进行修改(对应步骤2)。之后,用户可以触发客户端200向服务端100提交修改后的代码库X、代码库Y以及代码库Z,并指示合并(对应步骤3)。
提交代码库时,键入的命令以及输出的信息如下:
$git mm upload
remote:merge request:https://hostname_of_server/repos/x/merge_requests/12
remote:merge request:https://hostname_of_server/repos/y/merge_requests/54
remote:merge request:https://hostname_of_server/repos/z/merge_requests/105
---------------------------------------------------------------------
INFO:root mergeequest:
remote:#############################################################################
remote:#https://hostname_of_server/repos/manifest/merge_requests/35 #
remote:#############################################################################
服务端100在接收到修改后的代码库X、代码库Y以及代码库Z后,可以对服务端保存的代码库X、代码库Y以及代码库Z进行更新(对应步骤4),对修改后的代码库X、代码库Y以及代码库Z进行合并,生成代码快照(对应步骤5)。
代码快照如下:
在该代码快照中记录了合并代码,在代码快照中通过每个代码库的标识以及每个代码库的版本号(revision后为版本号)指示合并代码。
由上可知,在每次对代码库合并时,服务端100侧均会生成一个合并代码版本。在对代码库进行多次修改以及多次合并的情况下,用户只要知道每次合并代码版本的标识,就可以从服务端100请求对应的合并代码版本。
在一种可能的实施方式中,服务端100在每次对代码库进行合并后,也可以不向客户端200反馈合并后的代码所在的合并代码版本(如第一合并代码版本、第二合并代码版本)的标识,用户可以通过客户端200向服务器请求合并代码版本的标识。
如图10A所示,在展示第一代码库的界面上设置有合并历史选项,用户在点击合并历史选项后,可以触发客户端200向服务端100发送合并历史请求,该合并历史请求用于向服务端100请求第一代码库中的代码与其他代码库中的代码合并后的代码所在的所有合并代码版本的标识。
服务端100在接收到该合并历史请求后,可以在本地存储的合并代码版本中查找,第一代码库的代码与其他代码库中的代码合并后的代码所在的所有合并代码版本,如确定的合并代码版本为第一合并代码版本、第二合并代码版本、第三合并代码版本。
服务端100将第一合并代码版本的标识、第二合并代码版本的标识、第三合并代码版本携带在合并历史响应中,向客户端200发送合并历史响应。
客户端200在接收到合并历史响应之后,获取第一合并代码版本的标识、第二合并代码版本的标识。如图10B所示,客户端200向用户展示合并代码版本标识列表,用户可以自行从该合并代码版本标识列表中选择一个或多个合并代码版本。
用户在通过点击合并代码版本的标识选择了其中一个或多个合并代码版本后,可以触发客户端200向服务端100发起请求该一个或多个合并代码版本的查询请求,该查询请求携带有用户选择的一个或多个合并代码版本的标识,服务端100在客户端200的请求下,可以向客户端200反馈该一个或多个合并代码版本。客户端200向服务端100请求该一个或多个合并代码版本的方式、以及服务端100反馈该一个或多个合并代码版本的方式与如图2所示的实施例中,客户端200向服务端100请求第一代码库的方式以及服务端100反馈第一代码库的方式类似,具体可以参见前述内容,此处不再赘述。
基于与方法实施例同一发明构思,本申请实施例还提供了一种服务装置,该服务装置用于执行上述方法实施例中服务端100执行的方法。如图11所示,所述服务装置存储有第一代码库和第二代码库,所述服务装置1100包括发送模块1101、接收模块1102、更新模块1103以及合并模块1104;具体地,在服务装置中,各模块之间通过通信通路建立连接。
发送模块1101,用于向客户端提供第一代码库。
接收模块1102,用于从客户端获取修改后的第一代码库。
更新模块1103,用于利用修改后的第一代码库更新服务装置存储的第一代码库。
合并模块1104,用于将第二代码库中的代码与修改后的第一代码库中的代码进行合并,生成第一合并代码版本,保存第一合并代码版本。
作为一种可能的实施方式,服务装置还保存第二合并代码版本,第二合并代码版本是在更新后的第一代码库被再次修改,和/或,第二代码库被修改,且更新模块1103再次更新了第一代码库和/或第二代码库后,合并模块1104对第一代码库中的代码和第二代码库中的代码合并生成的。
作为一种可能的实施方式,第一代码库和第二代码库之间存在关联,第一代码库和第二代码库之间关联关系可以为如下三种的任一种:
第一种、第一代码库中的代码和第二代码库中的代码中存在相同的代码元素,修改后的第一代码库中被修改的代码中包括相同的代码元素。
第二种、第一代码库中的代码第二代码库中的代码为应用中实现不同功能组件的代码。例如,第一代码库中的代码为应用中实现第一功能组件的代码,第二代码库中的代码是应用中用于实现第二功能组件的代码,第一合并代码版本表示应用的版本快照。
第三种、第一代码库中的代码和第二代码库中的代码包括下列的部分或全部:
代码开发过程中的原始代码的主干代码、由主干代码延伸的至少一个分支代码。
作为一种可能的实施方式,在生成第一合并代码版本之后,发送模块1101还可以向客户端提供第一合并代码版本的标识。
作为一种可能的实施方式,接收模块1102还可以从客户端接收到携带有第一合并代码版本的标识的查询请求;之后,发送模块1101可以向客户端提供第一合并代码版本。
作为一种可能的实施方式,合并模块1104在对第二代码库中的代码与修改后的第一代码库中的代码进行合并时,可以自行对第二代码库中的代码与修改后的第一代码库中的代码进行合并,也可以在客户端的指示下,对第二代码库中的代码与修改后的第一代码库中的代码进行合并。
基于与方法实施例同一发明构思,本申请实施例还提供了一种客户装置,该客户装置用于执行上述方法实施例中客户端200执行的方法。如图12所示,客户装置1200包括发送模块1201、修改模块1202以及接收模块1203。具体地,在服务端中,各模块之间通过通信通路建立连接。
发送模块1201,用于向服务端请求第一代码库。
接收模块1203,用于从服务端获取第一代码库。
修改模块1202,用于对第一代码库进行修改。
发送模块1201,还用于向服务端发送修改后的第一代码库。
作为一种可能的实施方式,发送模块1201还用于向服务端发送指示,该指示用于指定对第二代码库中的代码与修改后的第一代码库中的代码进行合并。
作为一种可能的实施方式,第一代码库和第二代码库之间存在关联,第一代码库和第二代码库之间关联关系可以为如下三种的任一种:
第一种、第一代码库中的代码和第二代码库中的代码中存在相同的代码元素,修改后的第一代码库中被修改的代码中包括相同的代码元素。
第二种、第一代码库中的代码第二代码库中的代码为应用中实现不同功能组件的代码。例如,第一代码库中的代码为应用中实现第一功能组件的代码,第二代码库中的代码是应用中用于实现第二功能组件的代码,第一合并代码版本表示应用的版本快照。
第三种、第一代码库中的代码和第二代码库中的代码包括下列的部分或全部:
代码开发过程中的原始代码的主干代码、由主干代码延伸的至少一个分支代码。
作为一种可能的实施方式,接收模块1203可以从服务端获取第一合并代码版本的标识。
作为一种可能的实施方式,发送模块1201可以向服务端发送查询请求,该查询请求携带第一合并代码版本的标识。接收模块1203可以从服务端接收第一合并代码版本。
本申请实施例中对模块的划分是示意性的,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,另外,在本申请各个实施例中的各功能模块可以集成在一个处理器中,也可以是单独物理存在,也可以两个或两个以上模块集成为一个模块中。上述集成的模块既可以采用硬件的形式实现,也可以采用软件功能模块的形式实现。
该集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台终端设备(可以是个人计算机,手机,或者网络设备等)或处理器(processor)执行本申请各个实施例的方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(read-onlymemory,ROM)、随机存取存储器(random access memory,RAM)、磁碟或者光盘等各种可以存储程序代码的介质。
本申请还提供如图13所示的计算设备1300。所述计算设备1300包括总线1301、处理器1302、通信接口1303和存储器1304。处理器1302、存储器1304和通信接口1303之间通过总线1301通信。
其中,处理器1302可以为中央处理器(central processing unit,CPU)。存储器1304可以包括易失性存储器(volatile memory),例如随机存取存储器(random accessmemory,RAM)。存储器1304还可以包括非易失性存储器(non-volatile memory),例如只读存储器(read-only memory,ROM),快闪存储器,HDD或SSD。存储器中存储有可执行代码,处理器1302可以执行该可执行代码以执行前述图3、8或9所示的实施例中服务端100执行的方法。存储器1304中还可以包括操作系统等其他运行进程所需的软件模块(如服务装置1100中的多个模块)。处理器1302也可以执行该可执行代码以执行前述图3、8或9所示的实施例中客户端100执行的方法。存储器1304中还可以包括操作系统等其他运行进程所需的软件模块(如客户装置1200中的多个模块),操作系统可以为LINUXTM,UNIXTM,WINDOWSTM等。图13中仅示例性的绘制出了服务装置1100中的多个模块。
本申请还提供一种计算设备系统,所述计算设备系统包括至少一个如图14所示的计算设备1400。所述计算设备1400包括总线1401、处理器1402、通信接口1403和存储器1404。处理器1402、存储器1404和通信接口1403之间通过总线1401通信。所述计算设备系统中的至少一个计算设备1400之间通过通信通路进行通信。
其中,处理器1402可以为CPU。存储器1404可以包括易失性存储器,例如随机存取存储器。存储器1404还可以包括非易失性存储器,例如只读存储器,快闪存储器,HDD或SSD。存储器1404中存储有可执行代码,处理器1402执行该可执行代码以执行前述图3、8或9所示的实施例中服务端100执行的方法中的任意部分或全部。存储器中还可以包括操作系统等其他运行进程所需的软件模块。处理器1402执行该可执行代码以执行前述图3、8或9所示的实施例中客户端100执行的方法中的任意部分或全部。存储器中还可以包括操作系统等其他运行进程所需的软件模块。操作系统可以为LINUXTM,UNIXTM,WINDOWSTM等。
所述计算设备系统中的至少一个计算设备1400之间通过通信网络互相建立通信,每个计算设备1400上可以运行服务装置1100中的任意一个或者任意多个模块。每个计算设备1400上也可以运行客户装置1200中的任意一个或者任意多个模块。图14中仅示例性的绘制出了服务装置1100中的多个模块。
上述各个附图对应的流程的描述各有侧重,某个流程中没有详述的部分,可以参见其他流程的相关描述。
在上述实施例中,可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时,可以全部或部分地以计算机程序产品的形式实现。计算机程序产品包括计算机程序指令,在计算机上加载和执行所述计算机程序指令时,全部或部分地产生按照本发明实施例图3、8或9所示的流程或功能。
所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中,或者从一个计算机可读存储介质向另一个计算机可读存储介质传输,例如,所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质,(例如,软盘、硬盘、磁带)、光介质(例如,DVD)、或者半导体介质(例如SSD)。
显然,本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请范围。这样,倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内,则本申请也意图包含这些改动和变型在内。
Claims (18)
1.一种代码修改方法,其特征在于,所述方法应用于代码管理系统,所述代码管理系统包括客户端和服务端,所述服务端存储有第一代码库和第二代码库,所述方法包括:
所述服务端向所述客户端提供所述第一代码库;
所述服务端从所述客户端获取修改后的所述第一代码库,利用修改后的所述第一代码库更新所述服务端存储的第一代码库;
所述服务端将所述第二代码库中的代码与所述修改后的第一代码库中的代码进行合并,生成第一合并代码版本,保存所述第一合并代码版本。
2.如权利要求1所述的方法,其特征在于,所述服务端还保存第二合并代码版本,所述第二合并代码版本是在更新后的所述第一代码库被再次修改,和/或,所述第二代码库被修改,且所述服务端再次更新了所述第一代码库和/或所述第二代码库后,所述服务端对所述第一代码库中的代码和所述第二代码库中的代码合并生成的。
3.如权利要求1或2所述的方法,其特征在于,所述第一代码库中的代码和所述第二代码库中的代码中存在相同的代码元素,所述修改后的所述第一代码库中被修改的代码中包括所述相同的代码元素。
4.如权利要求1或2所述的方法,其特征在于,所述第一代码库中的代码为应用中实现第一功能组件的代码,所述第二代码库中的代码是所述应用中用于实现第二功能组件的代码,所述第一合并代码版本表示所述应用的版本快照。
5.如权利要求1或2所述的方法,其特征在于,所述第一代码库中的代码和所述第二代码库中的代码包括下列的部分或全部:
代码开发过程中的原始代码的主干代码、由所述主干代码延伸的至少一个分支代码。
6.如权利要求1~5任一所述的方法,其特征在于,所述方法还包括:
所述服务端向所述客户端提供所述第一合并代码版本的标识。
7.如权利要求6所述的方法,其特征在于,所述方法还包括:
所述服务端在从所述客户端接收到携带有所述第一合并代码版本的标识的查询请求后,向所述客户端提供所述第一合并代码版本。
8.如权利要求1~7任一所述的方法,其特征在于,所述服务端对第二代码库中的代码与所述修改后的第一代码库中的代码进行合并,包括:
所述服务端在所述客户端的指示下,对所述第二代码库中的代码与修改后的所述第一代码库中的代码进行合并。
9.一种服务装置,其特征在于,所述服务装置存储有第一代码库和第二代码库,所述服务装置包括发送模块、接收模块、更新模块以及合并模块;
所述发送模块,用于向客户端提供所述第一代码库;
所述接收模块,用于从所述客户端获取修改后的所述第一代码库;
所述更新模块,用于利用修改后的所述第一代码库更新所述服务装置存储的第一代码库;
所述合并模块,用于将所述第二代码库中的代码与所述修改后的第一代码库中的代码进行合并,生成第一合并代码版本,保存所述第一合并代码版本。
10.如权利要求9所述的服务装置,其特征在于,所述服务装置还保存第二合并代码版本,所述第二合并代码版本是在更新后的所述第一代码库被再次修改,和/或,所述第二代码库被修改,且所述更新模块再次更新了所述第一代码库和/或所述第二代码库后,所述合并模块对所述第一代码库中的代码和所述第二代码库中的代码合并生成的。
11.如权利要求9或10所述的服务装置,其特征在于,所述第一代码库中的代码和所述第二代码库中的代码中存在相同的代码元素,所述修改后的所述第一代码库中被修改的代码中包括所述相同的代码元素。
12.如权利要求9或10所述的服务装置,其特征在于,所述第一代码库中的代码为应用中实现第一功能组件的代码,所述第二代码库中的代码是所述应用中用于实现第二功能组件的代码,所述第一合并代码版本表示所述应用的版本快照。
13.如权利要求9或10所述的服务装置,其特征在于,所述第一代码库中的代码和所述第二代码库中的代码包括下列的部分或全部:
代码开发过程中的原始代码的主干代码、由所述主干代码延伸的至少一个分支代码。
14.如权利要求9~13任一所述的服务装置,其特征在于,所述发送模块,还用于:
向所述客户端提供所述第一合并代码版本的标识。
15.如权利要求14所述的服务装置,其特征在于,
所述接收模块,还用于:从所述客户端接收到携带有所述第一合并代码版本的标识的查询请求;
所述发送模块,还用于向所述客户端提供所述第一合并代码版本。
16.如权利要求9~15任一所述的服务装置,其特征在于,所述合并模块在对第二代码库中的代码与所述修改后的第一代码库中的代码进行合并时,具体用于:
在所述客户端的指示下,对所述第二代码库中的代码与修改后的所述第一代码库中的代码进行合并。
17.一种计算设备,其特征在于,所述计算设备包括处理器和存储器;
所述存储器,用于存储计算机程序指令;
所述处理器调用所述存储器中的计算机程序指令执行上述权利要求1至8中任一项所述的方法。
18.一种非瞬态的计算机可读存储介质,其特征在于,所述非瞬态的计算机可读存储介质被计算设备执行时,所述计算设备执行上述权利要求1至8中任一项所述的方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110329141.8A CN115129362A (zh) | 2021-03-27 | 2021-03-27 | 一种代码修改方法、服务装置以及设备 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202110329141.8A CN115129362A (zh) | 2021-03-27 | 2021-03-27 | 一种代码修改方法、服务装置以及设备 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN115129362A true CN115129362A (zh) | 2022-09-30 |
Family
ID=83373964
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202110329141.8A Pending CN115129362A (zh) | 2021-03-27 | 2021-03-27 | 一种代码修改方法、服务装置以及设备 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN115129362A (zh) |
-
2021
- 2021-03-27 CN CN202110329141.8A patent/CN115129362A/zh active Pending
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11151083B2 (en) | Generating target application packages for groups of computing devices | |
US10303586B1 (en) | Systems and methods of integrated testing and deployment in a continuous integration continuous deployment (CICD) system | |
EP3428811B1 (en) | Database interface agent for a tenant-based upgrade system | |
US11886870B2 (en) | Maintaining and updating software versions via hierarchy | |
US8589350B1 (en) | Systems, methods, and media for synthesizing views of file system backups | |
US9552401B2 (en) | ETL tool interface for remote mainframes | |
JP4473153B2 (ja) | ネットワーク構成のチェックおよび修理のための方法、システムおよびプログラム | |
US8782604B2 (en) | Sandbox support for metadata in running applications | |
US20150006608A1 (en) | Networked solutions integration using a cloud business object broker | |
US20170091069A1 (en) | Testing of software upgrade | |
US20180113700A1 (en) | Caching and analyzing images for faster and simpler cloud application deployment | |
US9652220B2 (en) | Zero down-time deployment of new application versions | |
US11789745B2 (en) | Systems and methods for automated and distributed configuration of computing devices | |
US20190347245A1 (en) | Determining when a change set was delivered to a workspace or stream and by whom | |
US20230126168A1 (en) | Scalable visualization of a containerized application in a multiple-cluster and multiple deployment application environment | |
CN112068820B (zh) | 微服务的配置处理方法、装置、计算机设备和存储介质 | |
US20230239212A1 (en) | Stable References for Network Function Life Cycle Management Automation | |
EP4130982A1 (en) | Network-based solution module deployment platform | |
US9621424B2 (en) | Providing a common interface for accessing and presenting component configuration settings | |
CN115129362A (zh) | 一种代码修改方法、服务装置以及设备 | |
CN114760314A (zh) | 服务器管理方法、装置、计算机设备和存储介质 | |
CN116684282B (zh) | 新增云端服务器初始化方法、装置和计算机设备 | |
US12019922B2 (en) | Retention framework for data stores | |
US20230315836A1 (en) | Software discovery within software packaging and deployment systems | |
US10762090B2 (en) | Software discovery based on metadata analysis |
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 |