一种软件开发的分支管理方法、装置、电子设备及介质与流程

1.本发明实施例涉及计算机技术领域，尤其涉及一种软件开发的分支管理方法、装置、电子设备及介质。


背景技术：

2.在软件开发技术领域中，不同软件开发团队以及不同开发场景下，有不同的分支模式。其中，主流的分支模式包括aoneflow、gitflow和trunkbased等。各个分支模式在不同的开发团队、不同文化以及不同项目背景下都有各自的优缺点。随着开发团队技术的提升、人员变动以及交付需求变化等情况的发生，现有的分支模式无法满足于现状，通常需要借助合理的工具对现有的分支模式进行适当的裁剪或扩充，以更加顺畅的进行软件开发的分支管理工作。
3.现有技术中的分支管理方案通常采用统一的、固定的分支管理策略，整个分支管理的过程中自动化程度较低，分支管理成本较高、耗时长，导致项目组无法根据自身情况自动化进行分支管理，从而降低了分支管理的效率。


技术实现要素：

4.本发明提供一种软件开发的分支管理方法、装置、电子设备及介质，以实现根据项目组自身情况自动化进行分支模式的确定，提高分支管理效率。
5.第一方面，本发明实施例提供了一种软件开发的分支管理方法，该方法包括：
6.响应于用户对软件开发的当前迭代创建指令，判断用户是否从候选分支模式中确定目标分支模式；
7.若否，则响应于用户的自定义分支模式创建指令，记录当前自定义分支模式的分支管理策略；
8.根据预设的策略判断周期，判断所述当前自定义分支模式的分支管理策略是否满足预设的自定义分支稳定规则；
9.若是，则确定所述当前自定义分支模式为软件开发的目标分支模式，以完成对分支模式的自定义管理。
10.第二方面，本发明实施例还提供了一种软件开发的分支管理装置，该装置包括：
11.目标分支模式确定模块，用于响应于用户对软件开发的当前迭代创建指令，判断用户是否从候选分支模式中确定目标分支模式；
12.分支管理策略记录模块，用于若用户不从候选分支模式中确定目标分支模式，则响应于用户的自定义分支模式创建指令，记录当前自定义分支模式的分支管理策略；
13.分支稳定策略判断模块，用于根据预设的策略判断周期，判断所述当前自定义分支模式的分支管理策略是否满足预设的自定义分支稳定规则；
14.自定义管理模块，用于若当前自定义分支模式的分支管理策略满足预设的自定义分支稳定规则，则确定所述当前自定义分支模式为软件开发的目标分支模式，以完成对分
支模式的自定义管理。
15.第三方面，本发明实施例还提供了一种软件开发的分支管理设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器执行所述程序时实现如第一方面实施例所提供的任一软件开发的分支管理方法。
16.第四方面，本发明实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，其中，该程序被处理器执行时实现如第一方面实施例所提供的任一软件开发的分支管理方法。
17.本发明方案响应于用户选择的自定义分支模式创建指令，并记录当前自定义分支模式的分支管理策略。当分支管理策略满足预设的自定义分支稳定规则时，确定当前自定义分支模式为软件开发的目标分支模式，并完成对分支模式的自定义管理。上述方案实现了项目组能够根据软件开发情况形成适用于自身的自动化分支管理方案，提高了分支管理效率，从而节约了分支管理成本。
附图说明
18.图1是本发明实施例一中的一种软件开发的分支管理方法的流程示意图；
19.图2是本发明实施例二中的一种软件开发的分支管理方法的流程示意图；
20.图3是本发明实施例三中的一种软件开发的分支管理装置的结构示意图；
21.图4是本发明实施例四中的一种软件开发的分支管理设备的结构示意图。
具体实施方式
22.下面结合附图和实施例对本发明作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本发明，而非对本发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本发明相关的部分而非全部结构。
23.实施例一
24.图1为本发明实施例一提供的一种软件开发的分支管理方法的流程图，本实施例可适用于根据项目组自身情况，自动化确定软件开发的分支模式，并对分支模式进行分支管理的情况，该方法可以由软件开发的分支管理装置来执行，该装置可采用软件和/或硬件的方式实现。如图1所示，该方法具体包括如下步骤：
25.s110、响应于用户对软件开发的当前迭代创建指令，判断用户是否从候选分支模式中确定目标分支模式。
26.其中，候选分支模式可以包括aoneflow分支模式、gitflow分支模式和trunkbased分支模式等中的至少一种。目标分支模式可以是在进行软件开发过程中，用户进行分支管理所采用的分支模式，例如可以是候选分支模式中的其中一个。当前迭代可以是项目组在迭代计划会结束后，用户根据当前的迭代计划会的内容创建相关工作项。其中，迭代计划会可以是在软件开发过程中，相关项目组定期举行的开发会议；在迭代计划会中，项目组可以根据本次迭代任务确定本次迭代的需求。其中，相关工作项可以包括迭代故事和迭代任务，进一步的，一个相关工作项可以包括至少一个迭代故事，一个迭代故事可以包括至少一个迭代任务。当前迭代创建指令可以是用户根据相关工作项所发起的相关工作项内容的更新指令。
27.示例性的，可以根据实际的软件开发情况，有针对性的选择分支模式。具体的，针对软件开发进行的迭代计划会，用户可以根据迭代计划会内容，线上或线下创建相关工作项，从而确定相关工作项的迭代故事和迭代任务，并根据当前迭代故事和迭代任务发起当前迭代创建指令。当前迭代创建指令中可以包括相关工作项中的迭代故事和迭代任务，还可以包括用户是否从候选分支模式中选择目标分支模式。根据由用户发起的当前迭代创建指令，判断用户是否从候选分支模式中确定目标分支模式。
28.若用户是从候选分支模式中确定的目标分支模式，则按照目标分支模式中固定的分支模式管理方案进行一系列规范的分支管理。
29.s120、若否，则响应于用户的自定义分支模式创建指令，记录当前自定义分支模式的分支管理策略。
30.其中，若用户不是从候选分支模式中确定的目标分支模式，则可以响应用户发起的自定义分支模式创建指令。其中，自定义分支模式可以是用户根据软件开发的实际需求，自行创建的一套适合于自身需求的分支管理策略。
31.自定义分支模式创建指令可以包括创建分支指令、合并分支指令、删除分支指令、代码检视指令和流水线配置指令等；相应的，分支管理策略可以包括分支创建策略、分支合并策略、分支删除策略、代码检视策略和流水线配置策略等。其中，创建分支指令、合并分支指令和删除分支指令可以包括创建主分支、创建开发分支、创建发布分支、创建特性分支或创建热修复分支等中的至少一种；合并主分支、合并开发分支、合并发布分支、合并特性分支或合并热修复分支等中的至少一种；删除发布分支、删除特性分支或删除热修复分支等中的至少一种。
32.代码检视可以是开发过程中对创建、删除或合并后的分支进行的代码检测，从而确定创建、删除或合并后的分支上的代码是否正确。代码检视可以由相关工作人员进行人工检视，也可以自动检视。其中，自动检视可以根据不同的待进行代码检视的分支，预先配置相应的流水线，并通过流水线进行自动化检视。流水线配置可以是相关技术人员根据相关任务需求预先设定的一套流程，并且可以被相关任务直接调用。流水线配置可以根据不同相关任务需求进行不同的信息配置。其中，相关任务可以是自动代码检视等。
33.若用户不是从候选分支模式中确定的目标分支模式，则可以响应用户发起的自定义分支模式创建指令；根据用户发起的自定义分支模式创建指令，确定自定义分支模式创建指令对应的各分支创建策略；根据各分支创建策略，实时或定时记录当前自定义分支模式的分支管理策略。其中，若采用定时记录当前自定义分支模式的分支管理策略，则可以由用户提前预设定时周期，并由后台在定时周期内记录当前自定义分支模式的分支管理策略。
34.在一个可选实施例中，响应于用户的自定义分支模式创建指令，记录当前自定义分支模式的分支管理策略，包括：根据自定义分支模式创建指令，确定分支创建策略、分支合并策略、分支删除策略、代码检视策略和流水线配置策略；根据分支创建策略、分支合并策略、分支删除策略、代码检视策略、流水线配置策略以及自定义分支模式创建指令的触发时间，确定当前自定义分支模式的分支管理策略。
35.其中，触发时间可以是当前自定义分支模式中，发出创建分支指令触发时间、发出合并分支指令触发时间、发出删除分支指令触发时间、发出代码检视指令触发时间和发出
流水线配置指令触发时间。示例性的，根据自定义分支模式创建指令，确定分支创建策略、分支合并策略、分支删除策略、代码检视策略和流水线配置策略；判断当前时间是否为自定义分支模式创建指令的触发时间。若是，则根据分支创建策略、分支合并策略、分支删除策略、代码检视策略、流水线配置策略以及自定义分支模式创建指令的触发时间，确定当前自定义分支模式的分支管理策略；若否，则等待确定当前自定义分支模式的分支管理策略，直到当前时间为自定义分支模式创建指令的触发时间时，继续确定当前自定义分支模式的分支管理策略。
36.本可选实施例根据通过自定义分支模式创建指令确定的分支创建策略、分支合并策略、分支删除策略、代码检视策略、流水线配置策略以及自定义分支模式创建指令的触发时间，确定当前自定义分支模式的分支管理策略。上述方案实现了自定义分支模式的分支管理策略的确定，使得用户能够根据软件开发的实际需求在自定义分支模式中进行分支创建、删除、合并，根据实际需求进行代码检视和流水线配置。
37.s130、根据预设的策略判断周期，判断当前自定义分支模式的分支管理策略是否满足预设的自定义分支稳定规则。
38.其中，策略判断周期可以由相关技术人员进行提前预设，策略判断周期可以是时间周期，例如可以设置为5天，每5天进行一次自定义分支模式的分支管理策略的自定义分支稳定规则的判断；策略判断周期还可以是次数周期，例如可以设置为1次，每响应1次自定义分支模式的创建，进行1次自定义分支模式的分支管理策略的自定义分支稳定规则的判断。
39.其中，自定义分支稳定规则可以由相关技术人员进行提前设定，例如可以是将各分支创建策略、分支合并策略、分支删除策略、代码检视策略和流水线配置策略转换成矩阵或记忆曲线的形式，当转换后的矩阵或记忆曲线符合预设条件时，则可以认为自定义分支模式趋于稳定，即满足自定义分支稳定规则；当转换后的矩阵或记忆曲线不符合预设条件时，则可以认为自定义分支模式不稳定，即不满足自定义分支稳定规则。其中，预设条件例如可以是当前策略判断周期下，转换后的记忆曲线与历史策略判断周期内的记忆曲线相比较是否更加趋于稳定。
40.在一个可选实施例中，根据预设的策略判断周期，判断所述当前自定义分支模式的分支管理策略是否满足预设的自定义分支稳定规则，包括：获取预设策略判断周期内历史分支模式的分支管理策略；其中，所述历史分支模式为历史自定义分支模式或任一候选分支模式；确定当前自定义分支模式的分支管理策略与历史分支模式的分支管理策略之间的策略差值；若所述策略差值小于预设的差值阈值，则确定所述当前自定义分支模式的分支管理策略满足预设的自定义分支稳定规则。
41.获取预设的策略判断周期内的至少一个历史分支模式的分支管理策略，其中，历史分支模式可以为历史自定义分支模式或任一候选分支模式。
42.将历史分支模式的分支管理策略转换成矩阵或记忆曲线的形式。策略差值可以是当前自定义分支模式的分支管理策略转换后的矩阵，与历史分支模式的分支管理策略转换后的矩阵之间的矩阵差值；也可以是当前自定义分支模式的分支管理策略转换后的记忆曲线，与历史分支模式的分支管理策略转换后的记忆曲线之间的曲线上某两个点之间的差值。其中，预设的差值阈值可以由相关技术人员进行提前设定，具体可以是根据经验值或实
验值对不同策略差值比较对象进行设定。其中，策略差值比较对象例如可以是矩阵差值或记忆曲线差值，相关技术人员可以根据矩阵差值或记忆曲线差值设置不同的差值阈值。例如，策略差值比较对象为记忆曲线差值的差值阈值可以设置为3，策略差值比较对象为矩阵差值的差值阈值可以设置为5。
43.示例性的，以策略差值比较对象为矩阵差值为例，进行举例说明，可以将当前自定义分支模式的分支管理策略转换后的矩阵中的元素，与历史分支模式的分支管理策略转换后的矩阵中的元素进行比较，确定当前自定义分支模式的分支管理策略与历史分支模式的分支管理策略之间的矩阵差值。
44.示例性的，以策略差值比较对象为记忆曲线差值为例，进行举例说明，可以对当前自定义分支模式的分支管理策略转换后记忆曲线(以下称当前记忆曲线)任取一坐标点，对历史分支模式的分支管理策略转换后的记忆曲线(以下称历史记忆曲线)取与当前记忆曲线相对应的坐标点；可以将当前记忆曲线的坐标点对应的坐标值与历史记忆曲线的坐标点对应的坐标值进行逐一比较，确定当前自定义分支模式的分支管理策略与历史分支模式的分支管理策略之间的记忆曲线差值。即，判断自定义分支模式的变化是否趋于稳定。
45.具体的，若策略差值小于预设的差值阈值，则确定当前自定义分支模式的分支管理策略满足预设的自定义分支稳定规则，可以执行s140；若策略差值大于预设的差值阈值，则当前自定义分支模式的分支管理策略不满足预设的自定义分支稳定规则，可以由用户确定是否继续使用当前自定义分支模式作为目标分支模式，以完成对目标分支模式的分支管理。
46.本可选实施例通过获取预设判断周期内历史分支模式的分支管理策略，并将其与历史分支模式的分支管理策略进行比较，确定策略差值；根据策略差值与预设差值的关系，确定当前自定义分支模式的分支管理策略是否满足预设的自定义分支稳定规则。上述技术方案通过确定当前自定义分支模式的分支管理策略是否满足预设的自定义分支稳定规则的方式，实现了用户能够通过稳定的分支管理策略进行软件开发，在以后的迭代开发中，能够根据已形成的稳定的分支管理策略进行分支管理，从而减少了项目组的分支管理成本，实现了一体化的、自动化的分支管理策略。
47.s140、若是，则确定当前自定义分支模式为软件开发的目标分支模式，以完成对分支模式的自定义管理。
48.若当前自定义分支模式的分支管理策略满足预设的自定义分支稳定规则，则可以确定当前自定义分支模式为软件开发的目标分支模式，并完成对分支模式的自定义管理。其中，分支模式的自定义管理可以包括项目组根据自身情况对主分支、开发分支、特性分支、发布分支和特性分支等中的至少一种进行自定义管理；还可以包括对代码检视、流水线配置的管理。例如，在不同分支管理策略下配置不同的流水线，在自定义管理过程中随时对各分支中的代码进行代码检视。
49.本实施例方案通过响应于的用户选择的自定义分支模式创建指令，并记录当前自定义分支模式的分支管理策略；当分支管理策略满足预设的自定义分支稳定规则时，确定当前自定义分支模式为软件开发的目标分支模式，并完成对分支模式的自定义管理。上述方案实现了项目组能够根据软件开发情况形成适用于自身的自动化分支管理方案，提高了分支管理效率，从而节约了分支管理成本。
50.实施例二
51.图2为本发明实施例二提供的一种软件开发的分支管理方法的流程图，本实施例在上述各技术方案的基础上，进行了优化改进。
52.进一步的，将操作“判断用户是否从候选分支模式中确定目标分支模式”，追加为“若确定用户从所述候选分支模式中选择目标分支模式，则根据所述当前迭代创建指令，确定当前迭代开始时间；判断当前时间是否为当前迭代开始时间；若是，则根据目标分支模式的预设管理策略，对当前迭代进行分支管理。”以完善目标分支模式的确定。
53.如图2所示，该方法包括以下具体步骤：
54.s210、响应于用户对软件开发的当前迭代创建指令，判断用户是否从候选分支模式中确定目标分支模式。
55.s220、若确定用户从候选分支模式中选择目标分支模式，则根据当前迭代创建指令，确定当前迭代开始时间。
56.若用户从候选分支模式中选择目标分支模式，则根据当前迭代创建指令，确定当前迭代开始时间；若用户未从候选分支模式中选择目标分支模式，则可以执行s250。其中，当前迭代开始时间可以由用户根据需求进行人为设定。
57.s230、判断当前时间是否为当前迭代开始时间。
58.若接收到迭代创建指令，则判断当前时间是否为当前迭代开始时间；若未接收到迭代创建指令时，则不作响应，直到定时或实时的接收到迭代创建指令。若当前时间为当前迭代开始时间，则可以执行s240；若当前时间不是当前迭代开始时间，则等待当前时间为当前迭代创建指令的迭代开始时间后，可以继续执行s240。
59.s240、若是，则根据目标分支模式的预设管理策略，对当前迭代进行分支管理。
60.其中，若当前时间为当前迭代创建指令的当前迭代开始时间，则可以根据目标分支模式的预设管理策略，对当前迭代进行分支管理。其中，目标分支模式可以包括aoneflow分支模式、gitflow分支模式或trunkbased分支模式等中的任一分支模式，目标分支模式的分支管理为预先设计好的一套固定的分支模式管理方案，可以直接被进行软件开发的所属用户使用，并在使用的过程中按照预先设置好的分支管理策略进行分支管理。
61.在一个可选实施例中，若目标分支模式为gitflow分支模式；则根据目标分支模式的预设管理策略，对当前迭代进行分支管理，包括：根据主干分支拉取当前迭代的第一开发分支；根据当前迭代的工作项，基于预设的特性分支创建场景，从第一开发分支拉取特性分支；响应于代码提交指令，判断特性分支的代码是否进行代码检视，若是，则将特性分支合并入第一开发分支，得到第二开发分支；根据第二开发分支拉取发布分支；将发布分支部署至测试环境，根据预先配置的提测级流水线，对发布分支进行测试；若发布分支测试无误，则将发布分支合并入所述第二开发分支，以及将发布分支合并入主干分支，以完成分支管理。
62.从主分支中拉取当前迭代的第一开发分支，根据当前迭代的工作项，基于预设的特性分支创建场景，从第一开发分支拉取特性分支。其中，第一开发分支主要用于后续特性分支的合并。特性分支创建场景可以由用户根据需求进行提前预设，具体可以是根据当前迭代的工作项的功能特性创建特性分支，还可以是根据当前迭代的工作项的项目开发小组团队创建特性分支。具体的，从第一开发分支拉取特性分支之前，可以根据软件开发实际需
求选择相应的特性分支创建场景，从而根据特性分支创建场景，确定从第一开发分支拉取的特性分支。
63.示例性的，若根据当前迭代的工作项的功能特性创建特性分支，则在特性分支的创建过程中，可以根据当前迭代的工作项的功能特性对特性分支进行创建；可以将工作项中相同功能对应的代码写入同一特性分支中，因此，不同特性分支的工作项的功能特性不同，便于后续能够根据工作项对应的不同功能，对相应的特性分支上的代码进行编辑、修改或删除。其中，工作项中可以包含至少一个故事，一个故事对应至少一个开发软件的功能。
64.用户可以按照预设的命名规则对工作项中的故事进行命名，其中，命名规则可以由相关工作人员进行提前设定；对工作项中各故事的命名进行语义分析，并根据语义分析结果确定相关性较大的至少一个故事，其中，语义分析可以由相关语义分析算法对应的神经网络模型进行分析，并生成语义分析结果；将确定的相关性较大的至少一个故事关联到同一个特性分支下进行开发。可选的，用户还可以在拉取特性分支之前，手动将相关性较大的故事关联至一起，并在拉取特性分支之后，将相关性较大的故事关联至同一个特性分支下进行开发。
65.示例性的，若根据当前迭代的工作项的项目开发小组团队创建特性分支，则在特性分支的创建过程中，可以根据当前迭代的工作项的所属开发团队，对特性分支进行创建。其中，一个开发团队对应至少一个开发小组，一个开发小组可以负责开发工作项中不同的工作单元，且工作单元之间相互独立，一个工作单元中可以包括至少一个故事。具体可以是根据开发小组数量创建同等数量的特性分支，若要对特性分支中的代码进行修改、删除或编辑等操作，则可以直接由待操作的特性分支对应的开发小组对待操作的特性分支进行操作。
66.用户在编写特性分支的代码时，可以不断发出代码提交指令。在接收到用户的代码提交指令之后，可以通过查询代码检视记录确定用户提交的各特性分支中的代码是否进行了代码检视，其中，代码检视记录可以通过后台获取，后台可以实时或定时的监测各特性分支是否被执行代码检视操作，并为执行代码检视操作的各特性分支生成代码检视记录；若当前判断的特性分支有代码检视记录，则可以认为该特性分支已进行代码检视，若当前判断的特性分支没有代码检视记录，则可以认为该特性分支未进行代码检视，并可以通过发送邮件的方式通知相关开发人员对未进行代码检视的特性分支进行代码检视。
67.可以由相关技术人员手动对各特性分支中的代码进行代码检视，具体可以是将特性分支的代码手动放入测试工具中进行测试，并将测试通过的结果进行提交，由后台实时或定时的监测代码检视提交记录。若对代码检视的测试未通过，则由相关技术人员重新进行特性分支的代码检视，直到测试通过。其中，若采用定时监测的方式，则可以由相关工作人员设置定时周期，例如可以是1小时。可选的，代码检视还可以通过插拔式触发提交级构建流水线自动测试，其中，可以根据不同的开发语言类型对流水线进行相应的配置，例如，可以根据c语言、java语言或js语言对流水线进行相应的配置。
68.若代码检视由流水线自动化测试，则后台根据自动化测试结果确定是否生成代码检视提交记录。若自动化测试结果通过，则生成对应的特性分支的代码检视记录；若自动化测试结果未通过，则不生成对应的特性分支的代码检视记录，并且可以向流水线发送提示信息，以提示自动化检视未通过，并由流水线重新进行代码检视。
69.判断特性分支的代码是否进行代码检视，若是，为便于验证合并后的当前迭代的各项功能，则将特性分支合并入第一开发分支，得到第二开发分支；若否，则后台可以通过发送邮件的方式通知相关工作人员进行代码检视。
70.若特性分支已进行代码检视，则将特性分支合并入第一开发分支，得到第二开发分支。具体的，将特性分支合并入第一开发分支，得到第二开发分支之前，可以对预合并的特性分支的代码进行质量检测。若质量测试通过，则将特性分支合并入第一开发分支，得到第二开发分支，并在合并的过程中，为第二开发分支创建标签，便于后续因开发需求变动从而需要对第二开发分支进行相应操作时，能够根据第二开发分支的标签，快速回滚至第二开发分支中合并前的位置，并进行相应的操作，从而不影响其他分支的合并，其中，相应操作例如可以是对删除、编辑或修改操作；若质量测试未通过，则通知相关开发人员对质量测试未通过的特性分支进行修改。
71.在一个可选实施例中，将特性分支合并入第一开发分支，得到第二开发分支，包括：根据第一开发分支拉取临时分支；将特性分支合并入临时分支，得到预合并分支；根据预先设置的项目管理要求，对预合并分支的代码进行质量检测；若检测成功，则将特性分支合并入第一开发分支，得到第二开发分支。
72.可以从第一开发分支中拉取临时分支，并将特性分支合并入临时分支，得到预合并分支。根据预先设置的项目管理要求，对预合并分支的代码进行质量检测。具体的，开发人员可以根据预先设置的项目管理要求，设置不同的指标和阈值。其中，指标可以包括单元测试覆盖率、新增代码覆盖率、债务率、快味道数量和程序漏洞(bug)数量等中的至少一种；阈值可以是与各项指标相对应的指标阈值。对预合并分支的代码质量检测可以通过触发门禁式构建流水线进行检测，具体可以是通过门禁式构建流水线对预合并分支进行检测，在门禁式构建流水线中使用门禁规则对临时分支中不合格的特性分支进行阻断，从而实现对预合并分支进行质量检测。
73.若预合并分支的质量检测成功，则将特性分支合并入第一开发分支，得到第二开发分支；若合并分支的质量检测失败，则通知相关开发人员对质量测试失败的特性分支进行修改。本可选实施例通过确定预合并分支，判断预合并分支代码的质量测试是否通过的方式，确定是否将特性分支合并入所述第一开发分支，实现了对合并入第一开发分支之前的合并的特性分支代码的预先测试，从而防止特性分支在合并过程中出现错误，提高了合并后特性分支代码的准确度与稳定性。
74.在一个可选实施例中，在将特性分支合并入第一开发分支，得到第二开发分支之后，还包括：将特性分支添加至待删除清单中，判断特性分支是否满足预设的第一删除条件；若是，则将特性分支从待删除清单中删除。
75.分支模式中的各分支包括短分支和长分支，其中，短分支周期较短，通常可以在各分支的代码开发完成后进行删除，例如，短分支可以是特性分支、发布分支和热修复分支。长分支通常在软件开发过程中长期保留，进而不会在分支上的功能开发完成后删除，例如，长分支可以是主分支或开发分支。
76.其中，第一删除条件可以是当前待删除的特性分支分支已合并至第一开发分支，并且后台中在预设期限中不存在当前待删除特性分支的提交记录，即当前待删除特性分支中的代码在预设期限中未进行更新。
77.将特性分支添加至待删除清单中，判断特性分支是否满足预设的第一删除条件；若是，则将特性分支从待删除清单中删除；若否，则将特性分支保留在待删除清单中，并提示开发人员该特性分支不满足第一删除条件。本可选实施例通过将满足预设第一删除条件的特性分支删除的方式，减小了对内存空间的占用。
78.根据第二开发分支拉取发布分支；将发布分支部署至测试环境，根据预先配置的提测级流水线，对发布分支进行测试。具体的，开发人员可以通过预先配置的提测级流水线，将发布分支部署至测试环境，对发布分支进行测试；若发布分支测试无误，则将发布分支合并入第二开发分支，以及将发布分支合并入主分支，以完成分支管理；若发布分支测试有误，则提示相关开发人员测试有误，并可以提示相关开发人员可以直接在测试环境中对测试有误的代码进行修改，并将修改后的发布分支合并至第二开发分支以及主分支中。
79.其中，当发布分支合并至主分支后，可以将发布分支放入待删除清单中。判断发布主分支是否满足第二删除条件，若满足，则可以将各发布分支从待删除清单中删除，若不满足，则可以保留在待删除清单中，并提示工作人员该发布分支不满足第二删除条件。其中，第二删除条件可以是当前待删除发布分支已合并至主分支，并且后台中在预设期限中不存在当前待删除发布分支的提交记录，即当前待删除发布分支中的代码在预设期限中未进行更新。
80.若在部署测试环境后，需要对生产环境中的代码进行紧急修复，具体可以是在主分支中拉取热修复分支，并在热修复分支中对待紧急修复的代码进行修复，并将修复成功的代码合并入主分支中，同时合并入发布分支。具体的，当热修复分支中的代码完成紧急修复，并且已合并至主分支后，可以将热修复分支添加至待删除清单中。判断热修复分支是否满足第三删除条件，若满足，则可以将各热修复分支从待删除清单中删除，若不满足，则可以保留在待删除清单中，并提示工作人员该热修复分支不满足第三删除条件。其中，第三删除条件可以是当前待删除的热修复分支已合并至主分支，并且后台中在预设期限中不存在当前待删除热修复分支的提交记录，即当前待删除热修复分支中的代码在预设期限中未进行更新。
81.本可选实施例通过当前迭代的工作项，基于预设的特性分支创建场景，从第一开发分支中拉取特性分支，实现了在gitflow分支模式中进行特性分支创建的过程中，能够根据预设的特性分支创建场景与实际需求，选择性的对特性分支进行创建，为使用gitflow分支模式进行分支管理的所属开发人员提供更多的创建选择，并在开发过程中提供便利。通过将发布分支部署至测试环境，根据预先配置的提测级流水线，对发布分支进行测试的方式完成分支管理，实现了对各发布分支的自动化测试，从而提高了各发布分支代码的准确度。
82.在一个可选实施例中，若目标分支模式为trunkbased分支模式，则可以按照trunkbased分支模式的设定规则进行分支管理。在trunkbased分支模式下，工作项中的各故事所包含的任务均与主分支相关联，开发人员可以基于主分支完成对软件的开发。
83.开发人员可以根据主分支拉取软件开发的当前迭代的副主分支，用于承载工作项中各故事所包含的任务代码；后台可以定时或实时监测是否有代码检视记录，其中，若采用定时监测方式，则后台可以监测在定时周期内是否有代码检视记录，其中，定时周期可以由相关技术人员进行提前设定，例如可以设定为10分钟。若是，则可以将副主分支合并至主分
支，若否，则可以通过发送邮件的方式通知相应工作人员安排代码检视，或通过向流水线发送提示信息的方式，以提示流水线对相应的副主分支代码进行自动化测试。若代码检视通过，后台会生成副主分支代码检视通过的代码检视记录。其中，自动化测试可以通过插拔式触发提交级构建的流水线完成，并且可以根据不同的开发语言类型对流水线进行相应的配置。
84.将代码检视通过的各副主分支合并至主分支，并从合并后的主分支中拉取至少一个发布分支进行代码质量测试，具体可以是触发门禁式构建流水线，并根据不同的开发语言类型对流水线进行相应的配置，通过配置后的流水线完成对发布分支的代码质量的测试。若代码质量测试通过，则可以将发布分支中的代码放入提前部署的测试环境中进行测试；若代码质量测试未通过，则可以在发布分支中对代码进行修改。
85.若发布分支中的代码质量测试通过，则可以配置提测级流水线，并在部署的提测级流水线的测试环境中，对发布分支中的代码进行测试验证。若测试通过，则可以将发布分支合并至主分支中，并部署到正式环境，同时可以为各发布分支创建标签，便于后续能够通过标签确定需要修改、编辑或删除的待操作发布分支，并完成对待操作发布分支的相应操作；若测试未通过，则后台发出测试未通过提示信息，以提示相应的工作人员对测试未通过的代码进行修复。相关工作人员可以将各发布分支修复后的代码重新合并至主分支，并部署到正式环境中，并为发布分支创建标签。
86.示例性的，若在部署测试环境后，需要对生产环境中的代码进行紧急修复，具体可以是在主分支中拉取热修复分支，并在热修复分支中对待紧急修复的代码进行修复，并将修复成功的代码合并入主分支中，同时合并入发布分支。具体的，当热修复分支中的代码完成紧急修复，并且已合并至主分支之后，可以将热修复分支添加至待删除清单中。判断热修复分支是否满足第三删除条件，若满足，则可以将各热修复分支从待删除清单中删除，若不满足，则可以保留在待删除清单中，并提示工作人员该热修复主分支不满足第三删除条件。
87.在一个可选实施例中，若目标分支模式为aoneflow分支模式，则可以按照aoneflow分支模式的设定规则进行分支管理。在aoneflow分支模式下，开发人员可以基于主分支，根据工作项中的各故事所包含的不同任务自动创建特性分支。
88.示例性的，开发人员可以根据主分支拉取软件开发的当前迭代的特性分支，用于承载工作项中各故事所包含的任务代码；后台可以定时或实时监测是否有代码检视记录，其中，代码检测可以通过可插拔式触发提交级构建的流水线进行自动检测。若是，则可以将特性分支合并至由主分支拉取的发布分支，若否，则可以通过发送邮件的方式通知相应工作人员安排代码检视，或通过向流水线发送提示信息的方式，以提示流水线对相应的特性分支代码进行代码检视。若代码检视通过，后台会生成特性分支代码检视通过的代码检视记录。
89.基于主分支拉取发布分支，将代码检视通过的各特性分支合并至发布分支，并对合并后的发布分支进行代码质量测试，其中，代码质量测试可以通过提测级流水线进行自动化测试。若发布分支的代码质量通过，则将发布分支部署到正式环境中，同时，将发布分支合并至主分支，并为主分支中的发布分支添加标签。
90.示例性的，在各特性分支合并的过程中，可以将各合并完成后的特性分支添加至待删除清单中，判断各分支是否满足预设的第一删除条件；若是，则可以将各特性分支从待
删除清单中删除。若否，则将特性分支保留在待删除清单中，并提示开发人员该特性分支不满足第一删除条件。
91.若在部署测试环境后，需要对生产环境中的代码进行紧急修复，具体可以是在主分支中拉取热修复分支，并在热修复分支中对待紧急修复的代码进行修复，并将修复成功的代码合并入主分支中，同时合并入发布分支。具体的，当热修复分支中的代码完成紧急修复之后，可以将热修复分支添加至待删除清单中。
92.s250、若用户未从候选分支模式中确定目标分支模式，则响应于用户的自定义分支模式创建指令，记录当前自定义分支模式的分支管理策略。
93.s260、根据预设的策略判断周期，判断当前自定义分支模式的分支管理策略是否满足预设的自定义分支稳定规则。
94.s270、若是，则确定当前自定义分支模式为软件开发的目标分支模式，以完成对分支模式的自定义管理。
95.本实施例方案通过确定用户从候选分支模式中选择的目标分支模式，并根据目标分支模式的预设管理策略，对当前迭代进行分支管理的方式，实现了用户在候选分支模式下自动化、规范化的进行分支管理，从而提高软件开发效率。
96.实施例三
97.图3为本发明实施例三提供的一种软件开发的分支管理装置的结构示意图。本发明实施例所提供的一种软件开发的分支管理装置可执行本发明任意实施例所提供的一种软件开发的分支管理方法，具备执行方法相应的功能模块和有益效果。该装置可采用软件和/或硬件的方式实现。如图4所示，该装置具体包括：
98.目标分支模式确定模块301，用于响应于用户对软件开发的当前迭代创建指令，判断用户是否从候选分支模式中确定目标分支模式；
99.分支管理策略记录模块302，用于若用户不从候选分支模式中确定目标分支模式，则响应于用户的自定义分支模式创建指令，记录当前自定义分支模式的分支管理策略；
100.分支稳定策略判断模块303，用于根据预设的策略判断周期，判断所述当前自定义分支模式的分支管理策略是否满足预设的自定义分支稳定规则；
101.自定义管理模块304，用于若当前自定义分支模式的分支管理策略满足预设的自定义分支稳定规则，则确定所述当前自定义分支模式为软件开发的目标分支模式，以完成对分支模式的自定义管理。
102.本实施例方案通过响应于的用户选择的自定义分支模式创建指令，并记录当前自定义分支模式的分支管理策略；当分支管理策略满足预设的自定义分支稳定规则时，确定当前自定义分支模式为软件开发的目标分支模式，并完成对分支模式的自定义管理。上述方案实现了项目组能够根据软件开发情况形成适用于自身的自动化分支管理方案，提高了分支管理效率，从而节约了分支管理成本。
103.可选的，所述自定义分支模式创建指令包括创建分支指令、合并分支指令、删除分支指令、代码检视指令和流水线配置指令；
104.相应的，分支管理策略记录模块302，包括：
105.策略确定单元，用于根据所述自定义分支模式创建指令，确定分支创建策略、分支合并策略、分支删除策略、代码检视策略和流水线配置策略；
106.分支管理策略确定单元，用于根据所述分支创建策略、分支合并策略、分支删除策略、代码检视策略、流水线配置策略以及自定义分支模式创建指令的触发时间，确定当前自定义分支模式的分支管理策略。
107.可选的，分支稳定策略判断模块303，包括：
108.历史策略获取单元，用于获取预设策略判断周期内历史分支模式的分支管理策略；其中，所述历史分支模式为历史自定义分支模式或任一候选分支模式；
109.策略差值确定单元，用于确定当前自定义分支模式的分支管理策略与历史分支模式的分支管理策略之间的策略差值；
110.稳定规则确定单元，用于若所述策略差值小于预设的差值阈值，则确定所述当前自定义分支模式的分支管理策略满足预设的自定义分支稳定规则。
111.可选的，该装置还包括：
112.时间确定模块，用于在判断用户是否从候选分支模式中确定目标分支模式之后，若确定用户从所述候选分支模式中选择目标分支模式，则根据所述当前迭代创建指令，确定当前迭代开始时间；
113.时间判断模块，用于判断当前时间是否为当前迭代开始时间；
114.分支管理模块，用于若当前时间为当前迭代开始时间，则根据目标分支模式的预设管理策略，对当前迭代进行分支管理。
115.可选的，所述目标分支模式为gitflow分支模式；
116.相应的，分支管理模块，包括：
117.第一开发分支拉取单元，用于根据主干分支拉取当前迭代的第一开发分支；
118.特性分支拉取单元，用于根据当前迭代的工作项，基于预设的特性分支创建场景，从所述第一开发分支拉取特性分支；
119.第二开发分支确定单元，用于响应于代码提交指令，判断所述特性分支的代码是否进行代码检视，若是，则将所述特性分支合并入所述第一开发分支，得到第二开发分支；
120.发布分支拉取单元，用于根据所述第二开发分支拉取发布分支；
121.测试子单元，用于将所述发布分支部署至测试环境，根据预先配置的提测级流水线，对所述发布分支进行测试；
122.分支管理单元，用于若所述发布分支测试无误，则将所述发布分支合并入所述第二开发分支，以及将所述发布分支合并入所述主干分支，以完成分支管理。
123.可选的，该装置还包括：
124.第一删除条件判断装置，用于在将所述特性分支合并入所述第一开发分支，得到第二开发分支之后，将所述特性分支添加至待删除清单中，判断所述特性分支是否满足预设的第一删除条件；
125.特性分支删除装置，用于若所述特性分支满足预设的第一删除条件，则将所述特性分支从所述待删除清单中删除。
126.可选的，第二开发分支确定单元，具体用于：
127.根据所述第一开发分支拉取临时分支；
128.将所述特性分支合并入所述临时分支，得到预合并分支；
129.根据预先设置的项目管理要求，对所述预合并分支的代码进行质量检测；
130.若检测成功，则将所述特性分支合并入所述第一开发分支，得到所述第二开发分支。
131.上述软件开发的分支管理装置可执行本技术任意实施例所提供的软件开发的分支管理方法，具备执行各软件开发的分支管理方法相应的功能模块和有益效果。
132.实施例四
133.图4是本发明实施例四提供的一种软件开发的分支管理的结构示意图。软件开发的分支管理设备是一种电子设备，图4示出了适于用来实现本发明实施方式的示例性电子设备400的框图。图4显示的电子设备400仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。
134.如图4所示，电子设备400以通用计算设备的形式表现。电子设备400的组件可以包括但不限于：一个或者多个处理器或者处理单元401，系统存储器402，连接不同系统组件(包括系统存储器402和处理单元401)的总线403。
135.总线403表示几类总线结构中的一种或多种，包括存储器总线或者存储器控制器，外围总线，图形加速端口，处理器或者使用多种总线结构中的任意总线结构的局域总线。举例来说，这些体系结构包括但不限于工业标准体系结构(isa)总线，微通道体系结构(mac)总线，增强型isa总线、视频电子标准协会(vesa)局域总线以及外围组件互连(pci)总线。
136.电子设备400典型地包括多种计算机系统可读介质。这些介质可以是任何能够被电子设备400访问的可用介质，包括易失性和非易失性介质，可移动的和不可移动的介质。
137.系统存储器402可以包括易失性存储器形式的计算机系统可读介质，例如随机存取存储器(ram)404和/或高速缓存存储器405。电子设备400可以进一步包括其它可移动/不可移动的、易失性/非易失性计算机系统存储介质。仅作为举例，存储系统406可以用于读写不可移动的、非易失性磁介质(图4未显示，通常称为“硬盘驱动器”)。尽管图4中未示出，可以提供用于对可移动非易失性磁盘(例如“软盘”)读写的磁盘驱动器，以及对可移动非易失性光盘(例如cd
‑
rom,dvd
‑
rom或者其它光介质)读写的光盘驱动器。在这些情况下，每个驱动器可以通过一个或者多个数据介质接口与总线403相连。存储器402可以包括至少一个程序产品，该程序产品具有一组(例如至少一个)程序模块，这些程序模块被配置以执行本发明各实施例的功能。
138.具有一组(至少一个)程序模块407的程序/实用工具408，可以存储在例如存储器402中，这样的程序模块407包括但不限于操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。程序模块407通常执行本发明所描述的实施例中的功能和/或方法。
139.电子设备400也可以与一个或多个外部设备409(例如键盘、指向设备、显示器410等)通信，还可与一个或者多个使得用户能与该电子设备400交互的设备通信，和/或与使得该电子设备400能与一个或多个其它计算设备进行通信的任何设备(例如网卡，调制解调器等等)通信。这种通信可以通过输入/输出(i/o)接口411进行。并且，电子设备400还可以通过网络适配器412与一个或者多个网络(例如局域网(lan)，广域网(wan)和/或公共网络，例如因特网)通信。如图4所示，网络适配器412通过总线403与电子设备400的其它模块通信。应当明白，尽管图4中未示出，可以结合电子设备400使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、raid系统、磁带驱动器以
及数据备份存储系统等。
140.处理单元401通过运行存储在系统存储器402中的程序，从而执行各种功能应用以及数据处理，例如实现本发明实施例所提供的一种软件开发的分支管理方法。
141.实施例六
142.本发明实施例六还提供一种包含计算机可执行指令的存储介质，其上存储有计算机程序，该程序被处理器执行时实现如本发明实施例所提供的一种软件开发的分支管理方法，包括：
143.响应于用户对软件开发的当前迭代创建指令，判断用户是否从候选分支模式中确定目标分支模式；
144.若否，则响应于用户的自定义分支模式创建指令，记录当前自定义分支模式的分支管理策略；
145.根据预设的策略判断周期，判断所述当前自定义分支模式的分支管理策略是否满足预设的自定义分支稳定规则；
146.若是，则确定所述当前自定义分支模式为软件开发的目标分支模式，以完成对分支模式的自定义管理。
147.本发明实施例的计算机存储介质，可以采用一个或多个计算机可读的介质的任意组合。计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质。计算机可读存储介质例如可以是但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑磁盘只读存储器(cd
‑
rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本文件中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。
148.计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。
149.计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于无线、电线、光缆、rf等等，或者上述的任意合适的组合。
150.可以以一种或多种程序设计语言或其组合来编写用于执行本发明操作的计算机程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如java、smalltalk、c ，还包括常规的过程式程序设计语言—诸如“c”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络，包括局域网(lan)或广域网(wan)，连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。
151.注意，上述仅为本发明的较佳实施例及所运用技术原理。本领域技术人员会理解，本发明不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本发明的保护范围。因此，虽然通过以上实施例对本发明进行了较为详细的说明，但是本发明不仅仅限于以上实施例，在不脱离本发明构思的情况下，还可以包括更多其他等效实施例，而本发明的范围由所附的权利要求范围决定。