CN109976800A - 基于Gitlab的消息通知方法、装置、设备及存储介质 - Google Patents

Abstract

本公开实施例公开了一种基于Gitlab的消息通知方法、装置、设备及存储介质。该方法包括：监听第一用户触发的事件请求，所述事件请求携带至少一个第二用户的信息；根据所述事件请求生成通知消息，并启动与所述Gitlab关联的即时通信工具；控制所述即时通信工具将所述通知消息发送至所述至少一个第二用户；以通知所述第二用户执行相应的操作。本实施例提供的基于Gitlab的消息通知方法，通过启动与Gitlab关联的即时通信工具向第二用户发送通知消息，无需第一用户手动发送通知消息，实现通知消息的自动发送，提高消息通知的便捷性。

Description

基于Gitlab的消息通知方法、装置、设备及存储介质

技术领域

本公开实施例涉及计算机技术领域，尤其涉及一种基于Gitlab的消息通知方法、装置、设备及存储介质。

背景技术

技术人员在开发一个项目时，不同的第一用户负责不同的分支，第一用户完成自己负责的分支后，需要将该分支的代码合入主干以实现项目的上线。在项目上线前，每一个分支的代码需要其他第一用户进行检查。

现有的做法是，第一用户将一个链接发到一个群组里并通知第二用户对代码进行检查或者单独发给第二用户，第二用户对代码进行检查后，通知第一用户，第一用户收到通知后，点击链接查看第二用户对代码的评论，以根据评论对代码进行修改，需要第一用户手动通知他人，操作繁琐。

发明内容

本公开实施例提供一种基于Gitlab的消息通知方法、装置、设备及存储介质，实现通知消息的自动发送，提高消息通知的便捷性。

第一方面，本公开实施例提供了一种基于Gitlab的消息通知方法，该方法包括：

监听第一用户触发的事件请求，所述事件请求携带至少一个第二用户的信息；

根据所述事件请求生成通知消息，并启动与所述Gitlab关联的即时通信工具；

控制所述即时通信工具将所述通知消息发送至所述至少一个第二用户；以通知所述第二用户执行相应的操作。

进一步地，所述事件请求包括代码合并请求、创建讨论组请求、添加标签请求及项目跟踪请求。

进一步地，若事件请求为代码合并请求，则根据所述事件请求生成通知消息，包括：

根据所述代码合并请求生成通知链接；

控制所述即时通信工具将所述通知消息发送至所述至少一个第二用户，包括：

控制所述即时通信工具将所述通知链接发送至所述至少一个第二用户。

进一步地，在将所述通知链接发送至所述至少一个第二用户之后，还包括：

接收所述第二用户输入的代码确认信息；

判断输入代码确认信息的第二用户的数量是否满足合并条件，若满足，则按照设定方式合并代码。

进一步地，在接收所述第二用户输入的代码确认信息之前，还包括：

接收所述第二用户输入的评论和/或修改信息，并控制所述即时通信工具将所述评论和/或修改信息发送至所述第一用户；

接收所述第一用户根据所述评论和/或修改信息输入的修改指令，根据所述修改指令对代码进行修改，并生成修改通知信息；

控制所述即时通信工具将所述修改通知信息发送至所述第二用户；

若未接收到所述第一用户输入的修改指令，则每隔设定时间返回执行控制所述即时通信工具将所述评论和/或修改信息发送至所述第一用户的操作，直到接收到第一用户根据所述评论和/或修改信息输入的修改指令。

进一步地，按照设定方式合并代码，包括：

若Gitlab中配置自动合并插件，则直接将待合并代码合并至主干上；

若Gitlab中未配置自动合并插件，则控制所述即时通信工具向所述第一用户发送合并提醒信息，并根据用户输入的合并指令将待合并代码合并至主干上。

进一步地，还包括：

接收第一用户输入的强制合并代码信息，并控制即时通信工具将所述强制合并代码信息发送至项目负责人；

根据所述项目负责人输入的强制合并代码指令将待合并代码强制合并至主干上。

进一步地，在判断输入代码确认信息的第二用户数量是否满足合并条件之后，还包括：

若输入代码确认信息的第二用户数量不满足合并条件，则获取未输入代码确认消息的第二用户信息，并生成提醒信息；

控制即时通信工具将所述提醒信息发送至未输入代码确认信息的第二用户，以提醒未输入代码确认信息的第二用户对代码进行确认。

进一步地，若所述事件请求为添加标签请求，则监听第一用户触发的事件请求，包括：

接收第一用户输入的添加标签请求，并根据所述添加标签请求对代码添加上线请求；

根据所述事件请求生成通知消息，包括：

根据所述添加标签请求生成上线信息；

控制所述即时通信工具将所述通知消息发送至所述至少一个第二用户，包括：

控制所述即时通信工具将所述上线信息发送至至少一个第二用户。

进一步地，若所述事件请求为创建讨论组请求，则根据所述事件请求生成通知消息，包括：

根据所述创建讨论组请求生成加入讨论组信息；

控制所述即时通信工具将所述通知消息发送至所述至少一个第二用户，包括：

控制所述即时通信工具将所述加入讨论组信息发送至待加入讨论组的第二用户，以使第二用户加入讨论组。

进一步地，还包括：

当接收到讨论组内任意一个用户发送的讨论信息时，控制所述即时通信工具将所述讨论信息发送至讨论组内其它的用户。

进一步地，所述事件请求为项目跟踪请求，则监听第一用户触发的事件请求，包括：

接收第一用户输入的项目跟踪链接，并对所述项目跟踪链接进行校验；

若校验通过，则接收第一用户上传的代码，所述项目为代码所属的项目；

若检验不通过，则控制所述即时通信工具向所述第一用户发送检验失败消息。

第二方面，本公开实施例还提供了一种基于Gitlab的消息通知装置，该装置包括：

事件请求监听模块，用于监听第一用户触发的事件请求，所述事件请求携带至少一个第二用户的信息；

通知消息生成模块，用于根据所述事件请求生成通知消息，并启动与所述Gitlab关联的即时通信工具；

通知消息发送模块，用于控制所述即时通信工具将所述通知消息发送至所述至少一个第二用户；以通知所述第二用户执行相应的操作。

第三方面，本公开实施例还提供了一种电子设备，所述电子设备包括：

一个或多个处理装置；

存储装置，用于存储一个或多个程序；

当所述一个或多个程序被所述一个或多个处理装置执行，使得所述一个或多个处理装置实现如本公开实施例所述的基于Gitlab的消息通知方法。

第四方面，本公开实施例公开了一种计算机可读介质，其上存储有计算机程序，其特征在于，该程序被处理装置执行时实现如本公开实施例所述的基于Gitlab的消息通知方法。

本公开实施例，通过监听第一用户触发的事件请求，然后根据事件请求生成通知消息，并启动与Gitlab关联的即时通信工具，最后控制即时通信工具将通知消息发送至至少一个第二用户，以通知第二用户执行相应的操作。本实施例提供的基于Gitlab的消息通知方法，通过启动与Gitlab关联的即时通信工具向第二用户发送通知消息，无需第一用户手动发送通知消息，实现通知消息的自动发送，提高消息通知的便捷性。

附图说明

图1是本公开实施例一中的基于Gitlab的消息通知方法的流程图；

图2是本公开实施例二中的基于Gitlab的消息通知方法的流程图；

图3是本公开实施例二中的基于Gitlab的消息通知方法的流程图

图4是本公开实施例三中的基于Gitlab的消息通知装置的结构示意图；

图5是本公开实施例四中的电子设备的结构示意图。

具体实施方式

下面结合附图和实施例对本公开作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本公开，而非对本公开的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本公开相关的部分而非全部结构。

下述各实施例中，每个实施例中同时提供了可选特征和示例，实施例中记载的各个特征可进行组合，形成多个可选方案，不应将每个编号的实施例仅视为一个技术方案。

实施例一

图1为本公开实施例一提供的一种基于Gitlab的消息通知方法的流程图，本实施例可适用于利用Gitlab自动发送消息的情况，该方法可以由基于Gitlab的消息通知装置来执行，该装置可以由硬件和/或软件构成，并一般集成在电子设备中。如图1所示，该方法具体包括如下步骤：

步骤110，监听第一用户触发的事件请求。

其中，事件请求携带至少一个第二用户的信息。Gitlab工具是辅助开发人员开发基于代码的项目的工具。本应用场景下，事件请求包括代码合并请求、创建讨论组请求、添加标签请求及项目跟踪请求等。

具体的，第一用户在开发项目的过程中，当需要借助Gitlab完成某事件时，启动Gitlab工具，并调用该事件对应的插件，Gitlab就会监听到被触发的事件请求。在触发事件请求时，第一用户可以输入第二用户的信息。

步骤120，根据事件请求生成通知消息，并启动与Gitlab关联的即时通信工具。

通知消息的形式可以是链接或信息等。即时通信工具可以是能够实现消息的即时交互的工具，例如：常见的有微信、QQ或者企业即时通信工具等。本实施例中，Gitlab和即时通信工具关联的方式可以是，在Gitlab中添加可以启动即时通信工具的插件。当监听到事件请求时，通过调用该插件启动即时通信工具。

具体的，当监听到第一用户触发的事件请求后，Gitlab工具根据事件请求生成相应的通知消息，然后启动与Gitlab关联的即时通信工具。

步骤130，控制即时通信工具将通知消息发送至至少一个第二用户，以通知第二用户执行相应的操作。

其中，相应的操作可以为第一用户触发的事件请求对应的操作。具体的，即时通信工具启动后，Gitlab工具根据事件请求携带至少一个第二用户的信息，控制即时通信工具将通知消息发送至第二用户中。例如，发送至以第二用户为账户的微信中。

可选的，若事件请求为添加标签请求，则接收第一用户输入的添加标签请求，并根据添加标签请求对代码添加上线请求，然后根据添加标签请求生成上线信息，并启动与Gitlab关联的即时通信工具，最后控制即时通信工具将上线信息发送至至少一个第二用户。

可选的，若事件请求为创建讨论组请求，则接收第一用户触发的创建讨论组请求，然后根据创建讨论组请求生成加入讨论组信息，并启动与Gitlab关联的即时通信工具，最后控制即时通信工具将加入讨论组信息发送至待加入讨论组的第二用户，以使第二用户加入讨论组。可选的，当接收到讨论组内任意一个用户发送的讨论信息时，控制即时通信工具将讨论信息发送至讨论组内其它的用户。

若事件请求为项目跟踪请求，则接收用户输入的项目跟踪链接，并对项目跟踪链接进行校验，若校验通过，则接收第一用户上传的代码，项目为代码所属的项目，若检验不通过，则启动与与Gitlab关联的即时通信工具，并控制即时通信工具向第一用户发送检验失败消息。

其中，项目跟踪链接可以是rocket/jira链接。第一用户通过客户端添加或修改rocket/jira链接，Gitlab对rocket/jira链接进行校验，若校验不通过，则向第一用户发送校验失败的信息，以通知第一用户进行修改。

本实施例的技术方案，通过监听第一用户触发的事件请求，然后根据事件请求生成通知消息，并启动与Gitlab关联的即时通信工具，最后控制即时通信工具将通知消息发送至至少一个第二用户，以通知第二用户执行相应的操作。本实施例提供的基于Gitlab的消息通知方法，通过启动与Gitlab关联的即时通信工具向第二用户发送通知消息，无需第一用户手动发送通知消息，实现通知消息的自动发送，提高消息通知的便捷性。

实施例二

图2为本公开实施例二提供的一种基于Gitlab的消息通知方法的流程图，以上述实施例为基础，当事件请求为代码合并请求时，该方法包括如下步骤：

S210，监听第一用户触发的代码合并请求。

其中，代码合并请求携带至少一个第二用户的信息。本实施例中，企业技术人员在开发项目时，通常将开发项目分成若干个分支，分别由不同的第一用户负责不同的分支，第一用户在编译好负责的分支代码后，需要将分支代码合并至主干上。第一用户首先编译好的待合并代码上传至Gitlab工具，并触发代码合并请求，Gitlab对第一用户触发的代码合并请求进行实时的监听。具体的，代码合并请求携带第二用户信息的方式可以是，在Gitlab工具界面的“description”栏中添加第二用户的联系方式，联系方式可以是邮箱或者第二用户在与Gitlab工具关联的即时通信工具中的身份识别码(ID)。

S220，根据代码合并请求生成通知链接，并启动与Gitlab关联的即时通信工具，控制即时通信工具将通知链接发送至至少一个第二用户。

其中，Gitlab工具监听到第一用户触发的代码合并请求后，生成通知链接，并启动与Gitlab关联的即时通信工具，最后控制即时通信工具并将通知链接发送至代码合并请求中携带的第二用户。以便第二用户通过点击通知链接查看待合并代码，以对待合并代码进行评论或确认。

S230，接收第二用户输入的代码确认信息。

具体的，第二用户查看待合并代码后，认为待合并代码已经没有问题，则输入代码确认信息。Gitlab工具控制即时通信工具将代码确认信息发送至第一用户。本实施例中，代码确认消息的形式可以“reviewer+1”。

可选的，在接收第二用户输入的代码确认信息之前，还包括如下步骤：接收第二用户输入的评论和/或修改信息，并控制即时通信工具将评论和/或修改信息发送至第一用户；接收第一用户根据评论和/或修改信息输入的修改指令，根据修改指令对代码进行修改，并生成修改通知信息；控制即时通信工具将修改通知信息发送至第二用户；若未接收到第一用户输入的修改指令，则每隔设定时间返回执行控制即时通信工具将评论和/或修改信息发送至第一用户的操作，直到接收到第一用户根据评论和/或修改信息输入的修改指令。

其中，设定时间可以设置为5-10分钟之间的任意值。具体的，第二用户在查看待合并代码时，认为待合并代码中的某些地方需要修改，则可以将修改或评论信息填入评论区域，然后提交。第二用户提交之后，Gitlab工具控制即时通信工具将第二用户输入的评论和/或修改信息发送至第一用户，第一用户根据评论和/或修改信息对待合并代码修改后点击提交，然后生成修改通知信息发送至第二用户，以通知第二用户查看修改后的待合并代码，直到第二用户对待合并代码确认。若未接收到第一用户输入的修改指令，则每隔设定时间返回执行控制即时通信工具将评论和/或修改信息发送至第一用户的操作，直到接收到第一用户根据评论和/或修改信息输入的修改指令。这样做的好处是，提醒第一用户尽快修改代码，从而提高代码合并的效率。

S240，判断输入代码确认信息的第二用户的数量是否满足合并条件，若满足，则按照设定方式合并代码。

其中，合并条件可以是输入代码确认信息的第二用户数量占代码合并请求携带的第二用户数量的比例达到设定阈值，设定阈值可以是60％-100％之间的任意值。优选的，合并条件是代码合并请求携带的第二用户全部输入代码确认信息。

可选的，按照设定方式合并代码，可通过下述方式实施：若Gitlab中配置自动合并插件，则直接将待合并代码合并至主干上；若Gitlab中未配置自动合并插件，则控制所述即时通信工具向所述第一用户发送合并提醒信息，并根据第一用户输入的合并指令将待合并代码合并至主干上。

具体的，若Gitlab中配置自动合并插件，当输入代码确认信息的第二用户数量满足合并条件后，自动将待合并代码合并至主干上。若Gitlab中未配置自动合并插件，当输入代码确认信息的第二用户数量满足合并条件后，则控制即时通信工具向第一用户发送合并提醒信息，并根据第一用户输入的合并指令将待合并代码合并至主干上。其中，合并指令可以是“@merge”的形式。

可选的，还包括如下步骤：接收第一用户输入的强制合并代码信息，并控制即时通信工具将强制合并代码信息发送至项目负责人；根据项目负责人输入的强制合并代码指令将待合并代码强制合并至主干上。

具体的，在特殊情况下，待合并代码需要强制合并至主干上，则第一用户可以在Gitlab工具输入强制合并代码信息，Gitlab控制即时通信工具通知项目负责人，以使项目项目负责人对待合并代码进行强制合并。示例性的，第一用户可以在Gitlab工具中的“MRdiscussion”中输入“force-merge”。

可选的，在判断输入代码确认信息的第二用户数量是否满足合并条件之后，还包括如下步骤：若输入代码确认信息的第二用户数量不满足合并条件，则获取未输入代码确认消息的第二用户信息，并生成提醒确认信息；控制即时通信工具将提醒确认信息发送至未输入代码确认信息的第二用户，以提醒未输入代码确认信息的第二用户对待合并代码进行确认。

图3为本公开实施例二提供的一种基于Gitlab的消息通知方法的流程图，本实施例以上述实施例中各个可选方案为基础进行具体化。如图3所示，该方法的流程如下：负责项目某个分支的第一用户(creator)创建Merge Request(MR)，并通过客户端添加/修改rocket/jira链接，对rocket/jira链接进行校验，若未通过，则向creator发送链接错误的通知消息，以提醒creator进行修改。创建MR成功后，提交MR，向每个reviewer发送通知消息，以通知reviewer对上传的代码进行评论。reviewer评论后定时向creator发送评论的通知消息，待creator解决了评论后重新提交，并向输入评论的reviewer发送通知消息。reviewer输入“+1”的信息后，向creator发送确认的通知消息。判断“+1”数量是否达到合并条件，若达到，则判断是否配置自动合并，若配置，则直接将代码合并至主干，若未配置，则creator输入merge，以实现将代码合并至主干。“+1”数量未达到合并条件且需要强制合并的情况下，creator输入@项目负责人，并向项目负责人发送强制合并的通知消息，项目负责人将代码合并至主干。合并后向creator发送合并的通知消息，判断是否配置打tag，若配置，则打上下tag。

本公开实施例的技术方案，通过监听第一用户触发的代码合并请求，然后根据代码合并请求生成通知链接，并启动与Gitlab关联的即时通信工具，控制即时通信工具将通知链接发送至至少一个第二用户，再然后接收第二用户输入的代码确认信息，最后判断输入代码确认信息的第二用户数量是否满足合并条件，若满足，则按照设定方式将待合并代码合并至主干上。可以实现代码的自动合并，提高代码合并的便捷性。

实施例三

图4本公开实施例二提供的一种基于Gitlab的消息通知装置的结构示意图。如图4所示，该装置包括：事件请求监听模块410，通知消息生成模块420和通知消息发送模块430。

事件请求监听模块410，用于监听第一用户触发的事件请求，事件请求携带至少一个第二用户的信息；

通知消息生成模块420，用于根据事件请求生成通知消息，并启动与Gitlab关联的即时通信工具；

通知消息发送模块430，用于控制即时通信工具将通知消息发送至至少一个第二用户；以通知第二用户执行相应的操作。

可选的，事件请求包括代码合并请求、创建讨论组请求、添加标签请求及项目跟踪请求。

可选的，若事件请求为代码合并请求，通知消息生成模块420，还用于：

根据代码合并请求生成通知链接；

通知消息发送模块430，还用于：

控制即时通信工具将通知链接发送至至少一个第二用户。

可选的，还包括：代码合并模块，用于：

接收第二用户输入的代码确认信息；

判断输入代码确认信息的第二用户的数量是否满足合并条件，若满足，则按照设定方式合并代码。

可选的，还包括：

评论和/或修改信息接收模块，用于接收第二用户输入的评论和/或修改信息，并控制即时通信工具将评论和/或修改信息发送至第一用户；

修改指令接收模块，用于接收第一用户根据评论和/或修改信息输入的修改指令，根据修改指令对代码进行修改，并生成修改通知信息；

通知消息发送模块430，还用于：控制即时通信工具将修改通知信息发送至第二用户；

若未接收到第一用户输入的修改指令，则每隔设定时间返回执行控制即时通信工具将评论和/或修改信息发送至第一用户的操作，直到接收到第一用户根据评论和/或修改信息输入的修改指令。

可选的，代码合并模块，还用于：

若Gitlab中配置自动合并插件，则直接将待合并代码合并至主干上；

若Gitlab中未配置自动合并插件，则控制即时通信工具向第一用户发送合并提醒信息，并根据第一用户输入的合并指令将待合并代码合并至主干上。

可选的，代码合并模块，还用于：

接收第一用户输入的强制合并代码信息，并控制即时通信工具将强制合并代码信息发送至项目负责人；

根据项目负责人输入的强制合并代码指令将待合并代码强制合并至主干上。

可选的，还包括：

若输入代码确认信息的第二用户数量不满足合并条件，则获取未输入代码确认消息的第二用户信息，并生成提醒信息；

控制即时通信工具将提醒信息发送至未输入代码确认信息的第二用户，以提醒未输入代码确认信息的第二用户对代码进行确认。

可选的，若事件请求为添加标签请求，事件请求监听模块410，还用于

接收第一用户输入的添加标签请求，并根据添加标签请求对代码添加上线请求；

通知消息生成模块420，还用于：

根据添加标签请求生成上线信息；

通知消息发送模块430，还用于：

控制即时通信工具将上线信息发送至至少一个第二用户。

可选的，若事件请求为创建讨论组请求，通知消息生成模块320，还用于：

根据创建讨论组请求生成加入讨论组信息；

通知消息发送模块430，还用于：

控制即时通信工具将加入讨论组信息发送至待加入讨论组的第二用户，以使第二用户加入讨论组。

可选的，还包括：

当接收到讨论组内任意一个用户发送的讨论信息时，控制即时通信工具将讨论信息发送至讨论组内其它的用户。

可选的，若事件请求为项目跟踪请求，事件请求监听模块410，还用于：

接收用户输入的项目跟踪链接，并对项目跟踪链接进行校验；

若校验通过，则接收第一用户上传的代码，项目为代码所属的项目；

若检验不通过，则控制即时通信工具向第一用户发送检验失败消息。

上述装置可执行本公开前述所有实施例所提供的方法，具备执行上述方法相应的功能模块和有益效果。未在本实施例中详尽描述的技术细节，可参见本公开前述所有实施例所提供的方法。

实施例四

下面参考图5，其示出了适于用来实现本公开实施例的电子设备500的结构示意图。本公开实施例中的电子设备可以包括但不限于诸如移动电话、笔记本电脑、数字广播接收器、PDA(个人数字助理)、PAD(平板电脑)、PMP(便携式多媒体播放器)、车载终端(例如车载导航终端)等等的移动终端以及诸如数字TV、台式计算机等等的固定终端，或者各种形式的服务器，如独立服务器或者服务器集群。图5示出的电子设备仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图5所示，电子设备500可以包括处理装置(例如中央处理器、图形处理器等)501，其可以根据存储在只读存储装置(ROM)502中的程序或者从存储装置505加载到随机访问存储装置(RAM)503中的程序而执行各种适当的动作和处理。在RAM 503中，还存储有电子设备500操作所需的各种程序和数据。处理装置501、ROM 502以及RAM 503通过总线504彼此相连。输入/输出(I/O)接口505也连接至总线504。

通常，以下装置可以连接至I/O接口505：包括例如触摸屏、触摸板、键盘、鼠标、摄像头、麦克风、加速度计、陀螺仪等的输入装置506；包括例如液晶显示器(LCD)、扬声器、振动器等的输出装置507；包括例如磁带、硬盘等的存储装置508；以及通信装置509。通信装置509可以允许电子设备500与其他设备进行无线或有线通信以交换数据。虽然图5示出了具有各种装置的电子设备500，但是应理解的是，并不要求实施或具备所有示出的装置。可以替代地实施或具备更多或更少的装置。

特别地，根据本公开的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行内容的推荐方法的程序代码。在这样的实施例中，该计算机程序可以通过通信装置509从网络上被下载和安装，或者从存储装置505被安装，或者从ROM 502被安装。在该计算机程序被处理装置501执行时，执行本公开实施例的方法中限定的上述功能。

需要说明的是，本公开上述的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储装置(RAM)、只读存储装置(ROM)、可擦式可编程只读存储装置(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储装置(CD-ROM)、光存储装置件、磁存储装置件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本公开中，计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读信号介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：电线、光缆、RF(射频)等等，或者上述的任意合适的组合。

上述计算机可读介质可以是上述电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。

上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被该处理装置执行时，使得该电子设备：监听第一用户触发的事件请求，所述事件请求携带至少一个第二用户的信息；根据所述事件请求生成通知消息，并启动与所述Gitlab关联的即时通信工具；控制所述即时通信工具将所述通知消息发送至所述至少一个第二用户，以通知所述第二用户执行相应的操作。

可以以一种或多种程序设计语言或其组合来编写用于执行本公开的操作的计算机程序代码，上述程序设计语言包括面向对象的程序设计语言—诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。

附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，该模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本公开实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现。其中，模块的名称在某种情况下并不构成对该模块本身的限定，例如，获取模块还可以被描述为“获取推广内容关联的可操作控件的模块”。

注意，上述仅为本公开的较佳实施例及所运用技术原理。本领域技术人员会理解，本公开不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本公开的保护范围。因此，虽然通过以上实施例对本公开进行了较为详细的说明，但是本公开不仅仅限于以上实施例，在不脱离本公开构思的情况下，还可以包括更多其他等效实施例，而本公开的范围由所附的权利要求范围决定。

Claims (15)

1.一种基于Gitlab的消息通知方法，其特征在于，包括：

监听第一用户触发的事件请求，所述事件请求携带至少一个第二用户的信息；

根据所述事件请求生成通知消息，并启动与所述Gitlab关联的即时通信工具；

控制所述即时通信工具将所述通知消息发送至所述至少一个第二用户，以通知所述第二用户执行相应的操作。

2.根据权利要求1所述的方法，其特征在于，所述事件请求包括代码合并请求、创建讨论组请求、添加标签请求及项目跟踪请求。

3.根据权利要求2所述的方法，其特征在于，若事件请求为代码合并请求，则根据所述事件请求生成通知消息，包括：

根据所述代码合并请求生成通知链接；

控制所述即时通信工具将所述通知消息发送至所述至少一个第二用户，包括：

控制所述即时通信工具将所述通知链接发送至所述至少一个第二用户。

4.根据权利要求3所述的方法，其特征在于，在将所述通知链接发送至所述至少一个第二用户之后，还包括：

接收所述第二用户输入的代码确认信息；

判断输入代码确认信息的第二用户的数量是否满足合并条件，若满足，则按照设定方式合并代码。

5.根据权利要求4所述的方法，其特征在于，在接收所述第二用户输入的代码确认信息之前，还包括：

接收所述第二用户输入的评论和/或修改信息，并控制所述即时通信工具将所述评论和/或修改信息发送至所述第一用户；

接收所述第一用户根据所述评论和/或修改信息输入的修改指令，根据所述修改指令对代码进行修改，并生成修改通知信息；

控制所述即时通信工具将所述修改通知信息发送至所述第二用户；

若未接收到所述第一用户输入的修改指令，则每隔设定时间返回执行控制所述即时通信工具将所述评论和/或修改信息发送至所述第一用户的操作，直到接收到第一用户根据所述评论和/或修改信息输入的修改指令。

6.根据权利要求4所述的方法，其特征在于，按照设定方式合并代码，包括：

若Gitlab中配置自动合并插件，则直接将待合并代码合并至主干上；

若Gitlab中未配置自动合并插件，则控制所述即时通信工具向所述第一用户发送合并提醒信息，并根据第一用户输入的合并指令将待合并代码合并至主干上。

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

接收第一用户输入的强制合并代码信息，并控制即时通信工具将所述强制合并代码信息发送至项目负责人；

根据所述项目负责人输入的强制合并代码指令将待合并代码强制合并至主干上。

8.根据权利要求4所述的方法，其特征在于，在判断输入代码确认信息的第二用户数量是否满足合并条件之后，还包括：

若输入代码确认信息的第二用户数量不满足合并条件，则获取未输入代码确认消息的第二用户信息，并生成提醒信息；

控制即时通信工具将所述提醒信息发送至未输入代码确认信息的第二用户，以提醒未输入代码确认信息的第二用户对代码进行确认。

9.根据权利要求2所述的方法，其特征在于，若所述事件请求为添加标签请求，则监听第一用户触发的事件请求，包括：

接收第一用户输入的添加标签请求，并根据所述添加标签请求对代码添加上线请求；

根据所述事件请求生成通知消息，包括：

根据所述添加标签请求生成上线信息；

控制所述即时通信工具将所述通知消息发送至所述至少一个第二用户，包括：

控制所述即时通信工具将所述上线信息发送至至少一个第二用户。

10.根据权利要求2所述的方法，其特征在于，若所述事件请求为创建讨论组请求，则根据所述事件请求生成通知消息，包括：

根据所述创建讨论组请求生成加入讨论组信息；

控制所述即时通信工具将所述通知消息发送至所述至少一个第二用户，包括：

控制所述即时通信工具将所述加入讨论组信息发送至待加入讨论组的第二用户，以使第二用户加入讨论组。

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

当接收到讨论组内任意一个用户发送的讨论信息时，控制所述即时通信工具将所述讨论信息发送至讨论组内其它的用户。

12.根据权利要求2所述的方法，其特征在于，若所述事件请求为项目跟踪请求，则监听第一用户触发的事件请求，包括：

接收第一用户输入的项目跟踪链接，并对所述项目跟踪链接进行校验；

若校验通过，则接收第一用户上传的代码，所述项目为代码所属的项目；

若检验不通过，则控制所述即时通信工具向所述第一用户发送检验失败消息。

13.一种基于Gitlab的消息通知装置，其特征在于，包括：

事件请求监听模块，用于监听第一用户触发的事件请求，所述事件请求携带至少一个第二用户的信息；

通知消息生成模块，用于根据所述事件请求生成通知消息，并启动与所述Gitlab关联的即时通信工具；

通知消息发送模块，用于控制所述即时通信工具将所述通知消息发送至所述至少一个第二用户；以通知所述第二用户执行相应的操作。

14.一种电子设备，其特征在于，所述电子设备包括：

一个或多个处理装置；

存储装置，用于存储一个或多个程序；

当所述一个或多个程序被所述一个或多个处理装置执行，使得所述一个或多个处理装置实现如权利要求1-12中任一所述的基于Gitlab的消息通知方法。

15.一种计算机可读介质，其上存储有计算机程序，其特征在于，该程序被处理装置执行时实现如权利要求1-12中任一所述的基于Gitlab的消息通知方法。