CN114327588A - 一种代码提交日志的处理方法及装置 - Google Patents

Abstract

本发明的实施例提供一种代码提交日志的处理方法及装置，所述方法包括：获取代码提交日志；调用配置在代码服务端的检查脚本，对所述代码提交日志进行规范检查；若检查的结果为不符合预设规范，则将所述代码提交日志作提交失败处理，否则，将所述代码提交日志提交到代码服务器。本发明的方案通过判断代码提交日志规范符合度，强制干预不符合规范的提交，并对不同情况灵活处理，提升代码提交规范度及执行效率。

Description

一种代码提交日志的处理方法及装置

技术领域

本发明涉及计算机技术领域，特别是指一种代码提交日志的处理方法及装置。

背景技术

在软件开发团队协作过程中，通常会使用GIT(是一个开源的分布式版本控制系统,用于敏捷高效地处理任何或小或大的项目)、SVN(是一个开放源代码的版本控制系统，通过采用分支管理系统的高效管理)等工具对整个软件开发过程做版本的控制管理。当开发人员编辑好代码需要提交的时候，往往需要编写提交日志，而提交日志的主要用途是：告诉这个项目的人，本次代码提交里做了些什么，便于后期阅读、修改、维护、撤销等操作。

然而没有工具和规范约束的个人操作，往往会让提交日志五花八门，为了避免这一现象，维护一份可读性好，方便跟踪项目历史，便于代码审查的代码，各公司也选择了适合自己的不同规范，但是规范如果仅仅靠个人自觉遵守往往收效甚微，使得对代码提交日志的规范化执行效率大大降低。

发明内容

本发明提供了一种代码提交日志的处理方法及装置。通过判断代码提交日志规范符合度，强制干预不符合规范的提交，并对不同情况灵活处理，提升代码提交规范度及执行效率。

为解决上述技术问题，本发明的实施例提供以下方案：

一种代码提交日志的处理方法，所述方法包括：

获取代码提交日志；

调用配置在代码服务端的检查脚本，对所述代码提交日志进行规范检查；

若检查的结果为不符合预设规范，则将所述代码提交日志作提交失败处理，否则，将所述代码提交日志提交到代码服务器。

可选的，所述检查脚本为预推钩pre-push事件的hook脚本。

可选的，所述pre-push事件的hook脚本通过以下过程配置在所述服务端：

修改用于仓库管理系统的开源项目gitlab配置文件；

执行sudo gitlab-ctl reconfigure命令使配置生效；

在自定义hook脚本目录下创建以下三个文件夹：第一文件夹、第二文件夹以及第三文件夹，分别对应三类全局hook，在每个文件夹下创建可执行脚本，在对应的hook时期，包括代码入库前，代码入库过程中以及代码入库后，gitlab主动调用所述hook脚本。

可选的，所述代码提交日志包括：本地分支相对于远程分支的所有新提交日志列表作为本次提交的代码提交日志。

可选的，调用配置在代码服务端的检查脚本，对所述代码提交日志进行规范检查，包括：

将获取到提交日志列表中的提交日志信息逐条与预置规则做比较，若提交日志列表的所有提交日志都符合规则，则正常提交入库，若有任何一条不符合规则，则提交失败。

可选的，所述预置规则为：<type>-<JIRAID>:<subject>，其中<type>表示提交类型；<JIRAID>表示具体缺陷的ID号；<subject>表示本条提交内容的简短描述。

可选的，提交日志列表中的所有提交日志都符合规则，则正常提交入库，若有任何一条不符合规则，则提交失败，包括：

逐条检查提交日志列表中的提交日志格式是否符合要求，则检查<type>是否为预设类型，若属于，则检查<JIRAID>是否真实有效，若有效，则检查该JIRAID是否为非关闭状态，若是则正常提交入库，否则任一条不符合则本次所有提交失败。

可选的，代码提交日志的处理方法，还包括以下至少一项：

对于两个分支的结合点的提交日志，通过检查脚本获取提交日志列表的时候，通过预设参数将所述将两个分支的结合点的提交日志删除；

对于新分支的提交日志列表，正常提交到代码服务器；

对于指定的排除仓库列表，提交代码触发hook检查时，检查当前仓库URL是否在所述指定的排除仓库列表中，如果当前仓库在排除仓库列表中，则直接通过规范检查，正常提交；如果不在，再检查是否为新分支，如果是新分支，则通过规范检查，正常提交；如果不是新分支，再检查除两个分支的结合点之外的所有新提交是否符合规范，所有都符合则正常提交，否则提交失败。

可选的，所述检查脚本对所有仓库生效，或者将仓库分类，在检查脚本中添加不同类别仓库做不同规范检查的逻辑，使不同类别的仓库配置不同检查规则。

本发明的实施例还提供一种代码提交日志的处理装置，包括：

获取模块，用于获取代码提交日志；

处理模块，用于调用配置在代码服务端的检查脚本，对所述代码提交日志进行规范检查；若检查的结果为不符合预设规范，则将所述代码提交日志作提交失败处理，否则，将所述代码提交日志提交到代码服务器。

本发明的实施例还提供一种通信设备，包括：处理器、存储有计算机程序的存储器，所述计算机程序被处理器运行时，执行如上所述的方法。

本发明的实施例还提供一种计算机可读存储介质，包括指令，当所述指令在计算机上运行时，使得计算机执行如上所述的方法。

本发明的上述方案至少包括以下有益效果：

本发明的上述方案，通过获取代码提交日志；调用配置在代码服务端的检查脚本，对所述代码提交日志进行规范检查；若检查的结果为不符合预设规范，则将所述代码提交日志作提交失败处理，否则，将所述代码提交日志提交到代码服务器。判断代码提交日志规范符合度，强制干预不符合规范的提交，并对不同情况灵活处理，提升代码提交规范度及执行效率。

附图说明

图1为本发明的实施例代码提交日志的处理方法的流程示意图；

图2为本发明的实施例代码提交日志的检查流程示意图；

图3为本发明的实施例特殊提交日志的检查流程示意图；

图4为本发明的实施例检查是否为新分支流程示意图；

图5为本发明的实施例特殊仓库的检查流程示意图；

图6为本发明的实施例不同项目配置不同检查规则的流程示意图；

图7为本发明的实施例代码提交日志的处理装置的模块示意图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本发明而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本发明，并且能够将本发明的范围完整的传达给本领域的技术人员。

如图1所示，本发明的实施例提供一种代码提交日志的处理方法，所述方法包括：

步骤11，获取代码提交日志；

步骤12，调用配置在代码服务端的检查脚本，对所述代码提交日志进行规范检查；

步骤13，若检查的结果为不符合预设规范，则将所述代码提交日志作提交失败处理，否则，将所述代码提交日志提交到代码服务器。

本发明的该实施例通过判断代码提交日志规范符合度，强制干预不符合规范的提交，并对不同情况灵活处理，提升代码提交规范度及执行效率。

本发明的一可选的实施例中，所述检查脚本为预推钩pre-push事件的hook脚本。本发明的该实施例中，以gitlab作为代码管理工具，通过调用pre-push事件的hook脚本，该hook可以配置在gitlab服务端对所有仓库生效，也可以配置在某个仓库中，仅对当前仓库生效。

本发明的一可选的实施例中，所述pre-push事件的hook脚本通过以下过程配置在所述服务端：

修改用于仓库管理系统的开源项目gitlab配置文件；

执行sudo gitlab-ctl reconfigure命令使配置生效；

在自定义hook脚本目录下创建以下三个文件夹：第一文件夹、第二文件夹以及第三文件夹，分别对应三类全局hook，在每个文件夹下创建可执行脚本，在对应的hook时期，包括代码入库前，代码入库过程中以及代码入库后，gitlab主动调用所述hook脚本。

该实施例中，鉴于规范化检查是针对全部项目的，因此实施例中，将其配置在服务端，也就是全局hook，配置生效后，在每次提交代码的时候会被触发，即在正式提交入库前，调用hook脚本对本次推送的所有提交逐条做规范检查(一次推送可能包含多条提交)。

具体的，全局hook在gitlab代码服务端配置如下：

修改gitlab配置文件：/etc/gitlab/gitlab.rb中的配置项，设置存放自定义hook脚本的目录：

gitlab_shell['custom_hooks_dir']＝"/opt/gitlab/embedded/service/gitlab-shell/custom_hooks"

执行sudo gitlab-ctl reconfigure命令使配置生效

在自定义hook脚本目录下创建以下三个文件夹：pre-received.d，update.d以及post-receive.d，分别对应三类全局hook，在每个文件夹下可创建可执行脚本，在对应的hook时期，包括代码入库前，代码入库过程中以及代码入库后，gitlab就会主动调用。

本申请的pre-push脚本就是放到上述pre-received.d目录下，在服务器接受代码入库前调用pre-push脚本做规范检查。

本发明的一可选的实施例中，所述代码提交日志包括：本地分支相对于远程分支的所有新提交日志列表作为本次提交的代码提交日志。

本发明的一可选的实施例中，调用配置在代码服务端的检查脚本，对所述代码提交日志进行规范检查，包括：

将获取到提交日志列表中的提交日志信息逐条与预置规则做比较，若提交日志列表的所有提交日志都符合规则，则正常提交入库，若有任何一条不符合规则，则提交失败。

可选的，所述预置规则为：<type>-<JIRAID>:<subject>，其中<type>表示提交类型；<JIRAID>表示具体缺陷的ID号；<subject>表示本条提交内容的简短描述。

可选的，提交日志列表中的所有提交日志都符合规则，则正常提交入库，若有任何一条不符合规则，则提交失败，包括：

逐条检查提交日志列表中的提交日志格式是否符合要求，则检查<type>是否为预设类型，若属于，则检查<JIRAID>是否真实有效，若有效，则检查该JIRAID是否为非关闭状态，若是则正常提交入库，否则任一条不符合则本次所有提交失败。

Pre-push脚本实现的代码提交日志规范化检查功能具体如下：

提取规范检查对象；

将本地分支相对于远程分支的所有新提交日志列表作为本次提交的检查对象；

与预置规则做比较；

将获取到列表中的提交日志信息逐条与预置规则做比较，若列表所有提交都符合规则，则正常提交入库，若有任何一条不符合规则，则提交失败，并打印失败信息，包括提交日志id及失败原因。

此处预置规则可按各公司需求灵活设置，例如借鉴业内应用较广泛的angular规范结合缺陷跟踪管理工具JIRA的方式：<type>-<JIRAID>:<subject>，其中<type>表示提交类型，具体可以是：feat，fix，refactor，style，docs，test，chore；<JIRAID>表示具体某一缺陷的ID号；<subject>表示本条提交内容的简短描述。其中<JIRAID>在检查时还可以通过JIRA API接口到JIRA服务器查询该JIRA是否真实有效、状态是否符合要求。

检查流程如图2所示：提交代码触发hook检查，获取本次提交日志列表，逐条检查提交日志格式是否符合，若符合则检查<type>是否属于7种类型之一，若属于则检查<JIRAID>是否真实有效，若有效则检查该JIRAID是否为非关闭状态，若是则成功提交，否则任一条不符合则强制本次所有提交失败。

本发明的一可选的实施例中，代码提交日志的处理方法，还包括以下至少一项：

1)对于两个分支的结合点的提交日志，通过检查脚本获取提交日志列表的时候，通过预设参数将所述将两个分支的结合点的提交日志删除；

2)对于新分支的提交日志列表，正常提交到代码服务器；

3)对于指定的排除仓库列表，提交代码触发hook检查时，检查当前仓库URL是否在所述指定的排除仓库列表中，如果当前仓库在排除仓库列表中，则直接通过规范检查，正常提交；如果不在，再检查是否为新分支，如果是新分支，则通过规范检查，正常提交；如果不是新分支，再检查除两个分支的结合点之外的所有新提交是否符合规范，所有都符合则正常提交，否则提交失败。

可选的，所述检查脚本对所有仓库生效，或者将仓库分类，在检查脚本中添加不同类别仓库做不同规范检查的逻辑，使不同类别的仓库配置不同检查规则。

该实施例中，特殊提交、新分支或指定仓库跳过规范检查：

如图3所示，对于一些特殊提交，比如merge提交，这里的merge提交是指在执行merge命令后自动生成的一条提交日志，这种提交日志仅仅是两个分支的结合点，非项目功能的修改，其本身对项目来说并没有什么意义，且是自动生成的，没有必要做规范检查，在pre-push脚本获取提交日志列表的时候可以通过git参数--no-merges将该类提交日志去掉。

很多开发过程初始是基于一些开源的代码做修改，开发人员会在开源代码既有的一些历史提交的基础上去做开发，而开源代码的提交历史往往不会符合某个公司的提交规范，开发人员也不可能将开源代码成百上千的历史提交一一改正，因此对于首次推送的包含开源代码历史提交的新分支是没有必要做检查的。

如图4所示，本发明可以去掉新分支的检查，检查是否为新分支流程如下：

提交代码触发hook检查，这时会提取到一个要提交的commit id区间做检查(每条提交日志对应一个commit id，该区间即为提交日志列表),commit id是一个40位的SHA-1哈希值，对于新分支来说，这个区间的起始值是由40位的0组成的，因此只要检查到起始值是40位0，就判断为推送了一个新分支，则判定本次规范检查通过，正常提交；否则，逐条检查提交日志信息。

如图5所示，对于某些仓库，由于其特殊性，本身已经有了一套适用该仓库的专用规范，并不希望跟公司共用一套规范，即对于该仓库需要排除全局hook的限制，可以通过在pre-push脚本中指定一个排除仓库列表，提交代码触发hook检查时，在hook脚本中运行gitremote–v获取当前仓库的URL，检查当前仓库URL是否在指定排除仓库列表中，如果当前仓库在排除仓库列表中，则直接通过规范检查，正常提交；如果不在，再检查是否为新分支，如果是新分支，则通过规范检查，正常提交；如果不是新分支，再检查除merge之外的所有新提交是否符合规范，所有都符合则正常提交，否则提交失败。

如图6所示，不同项目配置不同检查规则：

对于某些非功能开发的仓库，例如文档类仓库，并不存在缺陷一说，因此提交信息并不需要用JIRA跟踪，因此对于不同类型的项目，检查规则可能存在不一致的情况，因此可以将项目URL做一个分类，事先将不同类别的仓库URL列表存放到不同的规则文件中，在pre-push hook脚本中分别处理即可。例如，事先将仓库划分为三类，分别将对应仓库的URL存储到A.rule、B.rule、C.rule三个文件，推送代码触发hook时，在hook脚本中执行gitremote–v获取当前仓库的URL，遍历该URL属于B.rule，提取本次提交的日志列表，执行对应B.rule规则文件事先设置好的检查规则。

本发明的上述实施例通过调用pre-push hook，在代码提交的同时做规范性检查，实时监控代码日志规范符合度，将不符合规范的日志强制提交失败，即凡入库代码皆为符合规范的代码，全面彻底的优化了代码日志提交规范。

另外，该hook在提交时被触发，与代码服务器有交互，因此可以通过管理者配置在代码服务端统一生效，无需开发人员在客户端做任何配置，避免了因个别人员不配合导致的规则漏洞。

本发明的上述实施例适用范围较广，pre-push hook是git本身支持的hook，因此对于所有基于git的代码管理工具皆适用,不同工具的hook脚本存放位置及配置文件有所差异。

本发明的上述实施例方案更为灵活，通过调整hook脚本可以跳过指定类型、新分支、指定仓库的提交日志检查，也可以为不同的项目仓库设置不同的检查规则。

如图7所示，本发明的实施例还提供一种代码提交日志的处理装置70，包括：

获取模块71，用于获取代码提交日志；

处理模块72，用于调用配置在代码服务端的检查脚本，对所述代码提交日志进行规范检查；若检查的结果为不符合预设规范，则将所述代码提交日志作提交失败处理，否则，将所述代码提交日志提交到代码服务器。

可选的，所述检查脚本为预推钩pre-push事件的hook脚本。

可选的，所述pre-push事件的hook脚本通过以下过程配置在所述服务端：

修改用于仓库管理系统的开源项目gitlab配置文件；

执行sudo gitlab-ctl reconfigure命令使配置生效；

在自定义hook脚本目录下创建以下三个文件夹：第一文件夹、第二文件夹以及第三文件夹，分别对应三类全局hook，在每个文件夹下创建可执行脚本，在对应的hook时期，包括代码入库前，代码入库过程中以及代码入库后，gitlab主动调用所述hook脚本。

可选的，所述代码提交日志包括：本地分支相对于远程分支的所有新提交日志列表作为本次提交的代码提交日志。

可选的，调用配置在代码服务端的检查脚本，对所述代码提交日志进行规范检查，包括：

将获取到提交日志列表中的提交日志信息逐条与预置规则做比较，若提交日志列表的所有提交日志都符合规则，则正常提交入库，若有任何一条不符合规则，则提交失败。

可选的，所述预置规则为：<type>-<JIRAID>:<subject>，其中<type>表示提交类型；<JIRAID>表示具体缺陷的ID号；<subject>表示本条提交内容的简短描述。

可选的，提交日志列表中的所有提交日志都符合规则，则正常提交入库，若有任何一条不符合规则，则提交失败，包括：

逐条检查提交日志列表中的提交日志格式是否符合要求，则检查<type>是否为预设类型，若属于，则检查<JIRAID>是否真实有效，若有效，则检查该JIRAID是否为非关闭状态，若是则正常提交入库，否则任一条不符合则本次所有提交失败。

可选的，代码提交日志的处理方法，还包括以下至少一项：

对于两个分支的结合点的提交日志，通过检查脚本获取提交日志列表的时候，通过预设参数将所述将两个分支的结合点的提交日志删除；

对于新分支的提交日志列表，正常提交到代码服务器；

对于指定的排除仓库列表，提交代码触发hook检查时，检查当前仓库URL是否在所述指定的排除仓库列表中，如果当前仓库在排除仓库列表中，则直接通过规范检查，正常提交；如果不在，再检查是否为新分支，如果是新分支，则通过规范检查，正常提交；如果不是新分支，再检查除两个分支的结合点之外的所有新提交是否符合规范，所有都符合则正常提交，否则提交失败。

可选的，所述检查脚本对所有仓库生效，或者将仓库分类，在检查脚本中添加不同类别仓库做不同规范检查的逻辑，使不同类别的仓库配置不同检查规则。

需要说明的是，该装置是与上述方法对应的装置，上述方法实施例中的所有实现方式均适用于该装置的实施例中，也能达到相同的技术效果。

本发明的实施例还提供一种代码提交日志的处理设备，包括：处理器、存储有计算机程序的存储器，所述计算机程序被处理器运行时，执行如上所述的方法。上述方法实施例中的所有实现方式均适用于该实施例中，也能达到相同的技术效果。

本发明的实施例还提供一种计算机可读存储介质，包括指令，当所述指令在计算机上运行时，使得计算机执行如上所述的方法。上述方法实施例中的所有实现方式均适用于该实施例中，也能达到相同的技术效果。

本领域普通技术人员可以意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、或者计算机软件和电子硬件的结合来实现。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

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

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

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。

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

此外，需要指出的是，在本发明的装置和方法中，显然，各部件或各步骤是可以分解和/或重新组合的。这些分解和/或重新组合应视为本发明的等效方案。并且，执行上述系列处理的步骤可以自然地按照说明的顺序按时间顺序执行，但是并不需要一定按照时间顺序执行，某些步骤可以并行或彼此独立地执行。对本领域的普通技术人员而言，能够理解本发明的方法和装置的全部或者任何步骤或者部件，可以在任何计算装置(包括处理器、存储介质等)或者计算装置的网络中，以硬件、固件、软件或者它们的组合加以实现，这是本领域普通技术人员在阅读了本发明的说明的情况下运用他们的基本编程技能就能实现的。

因此，本发明的目的还可以通过在任何计算装置上运行一个程序或者一组程序来实现。所述计算装置可以是公知的通用装置。因此，本发明的目的也可以仅仅通过提供包含实现所述方法或者装置的程序代码的程序产品来实现。也就是说，这样的程序产品也构成本发明，并且存储有这样的程序产品的存储介质也构成本发明。显然，所述存储介质可以是任何公知的存储介质或者将来所开发出来的任何存储介质。还需要指出的是，在本发明的装置和方法中，显然，各部件或各步骤是可以分解和/或重新组合的。这些分解和/或重新组合应视为本发明的等效方案。并且，执行上述系列处理的步骤可以自然地按照说明的顺序按时间顺序执行，但是并不需要一定按照时间顺序执行。某些步骤可以并行或彼此独立地执行。

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

Claims (12)

1.一种代码提交日志的处理方法，其特征在于，所述方法包括：

获取代码提交日志；

调用配置在代码服务端的检查脚本，对所述代码提交日志进行规范检查；

若检查的结果为不符合预设规范，则将所述代码提交日志作提交失败处理，否则，将所述代码提交日志提交到代码服务器。

2.根据权利要求1所述的代码提交日志的处理方法，其特征在于，所述检查脚本为预推钩pre-push事件的hook脚本。

3.根据权利要求2所述的代码提交日志的处理方法，其特征在于，所述pre-push事件的hook脚本通过以下过程配置在所述服务端：

修改用于仓库管理系统的开源项目gitlab配置文件；

执行sudo gitlab-ctl reconfigure命令使配置生效；

在自定义hook脚本目录下创建以下三个文件夹：第一文件夹、第二文件夹以及第三文件夹，分别对应三类全局hook，在每个文件夹下创建可执行脚本，在对应的hook时期，包括代码入库前，代码入库过程中以及代码入库后，gitlab主动调用所述hook脚本。

4.根据权利要求1所述的代码提交日志的处理方法，其特征在于，所述代码提交日志包括：本地分支相对于远程分支的所有新提交日志列表作为本次提交的代码提交日志。

5.根据权利要求4所述的代码提交日志的处理方法，其特征在于，调用配置在代码服务端的检查脚本，对所述代码提交日志进行规范检查，包括：

将获取到提交日志列表中的提交日志信息逐条与预置规则做比较，若提交日志列表的所有提交日志都符合规则，则正常提交入库，若有任何一条不符合规则，则提交失败。

6.根据权利要求5所述的代码提交日志的处理方法，其特征在于，所述预置规则为：<type>-<JIRAID>:<subject>，其中<type>表示提交类型；<JIRAID>表示具体缺陷的ID号；<subject>表示本条提交内容的简短描述。

7.根据权利要求6所述的代码提交日志的处理方法，其特征在于，提交日志列表中的所有提交日志都符合规则，则正常提交入库，若有任何一条不符合规则，则提交失败，包括：

逐条检查提交日志列表中的提交日志格式是否符合要求，则检查<type>是否为预设类型，若属于，则检查<JIRAID>是否真实有效，若有效，则检查该JIRAID是否为非关闭状态，若是则正常提交入库，否则任一条不符合则本次所有提交失败。

8.根据权利要求1所述的代码提交日志的处理方法，其特征在于，还包括以下至少一项：

对于两个分支的结合点的提交日志，通过检查脚本获取提交日志列表的时候，通过预设参数将所述将两个分支的结合点的提交日志删除；

对于新分支的提交日志列表，正常提交到代码服务器；

对于指定的排除仓库列表，提交代码触发hook检查时，检查当前仓库URL是否在所述指定的排除仓库列表中，如果当前仓库在排除仓库列表中，则直接通过规范检查，正常提交；如果不在，再检查是否为新分支，如果是新分支，则通过规范检查，正常提交；如果不是新分支，再检查除两个分支的结合点之外的所有新提交是否符合规范，所有都符合则正常提交，否则提交失败。

9.根据权利要求1所述的代码提交日志的处理方法，其特征在于，所述检查脚本对所有仓库生效，或者将仓库分类，在检查脚本中添加不同类别仓库做不同规范检查的逻辑，使不同类别的仓库配置不同检查规则。

10.一种代码提交日志的处理装置，其特征在于，包括：

获取模块，用于获取代码提交日志；

处理模块，用于调用配置在代码服务端的检查脚本，对所述代码提交日志进行规范检查；若检查的结果为不符合预设规范，则将所述代码提交日志作提交失败处理，否则，将所述代码提交日志提交到代码服务器。

11.一种代码提交日志的处理设备，其特征在于，包括：处理器、存储有计算机程序的存储器，所述计算机程序被处理器运行时，执行如权利要求1至9任一项所述的方法。

12.一种计算机可读存储介质，其特征在于，包括指令，当所述指令在计算机上运行时，使得计算机执行如权利要求1至9任一项所述的方法。

Images