CN107025112A - 一种基于git hooks和缺陷管理工具的监管及跟踪方法 - Google Patents
一种基于git hooks和缺陷管理工具的监管及跟踪方法 Download PDFInfo
- Publication number
- CN107025112A CN107025112A CN201710228456.7A CN201710228456A CN107025112A CN 107025112 A CN107025112 A CN 107025112A CN 201710228456 A CN201710228456 A CN 201710228456A CN 107025112 A CN107025112 A CN 107025112A
- Authority
- CN
- China
- Prior art keywords
- git
- bug
- management tool
- code
- hooks
- 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
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
-
- 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
本发明公开了一种基于git hooks和缺陷管理工具的监管及跟踪方法,其特征在于,包括以下步骤:(1)通过git客户端向git上的工程分支提交代码;(2)git服务端收到分支代码的push请求时,将调用git hooks服务端的pre‑receive脚本;(3)pre‑receive脚本根据从缺陷管理工具中获取到ID的具体信息判断该ID的状态是否允许提交代码;(4)当步骤(3)判断结果全为“是”时“提交成功”;否则“提交失败”。本发明不仅步骤简单、方便操作,而且能规范代码提交流程,可便于问题追踪,适合推广使用。
Description
技术领域
本发明涉及一种监管及跟踪方法,尤其涉及一种基于git hooks和缺陷管理工具的监管及跟踪方法。
背景技术
目前,现有的大多数gitlab使用者都只是使用默认的git hooks,从而忽视了githooks的可定制、将git与缺陷管理工具结合起来控制代码的提交动作、以及将代码提交记录到缺陷管理工具,便于问题追踪定位。
发明内容
本发明的目的在于克服目前大多数gitlab使用者没有很好的利用git hooks的可定制性,并结合缺陷管理工具来监控并跟踪代码的提交的缺陷,提供一种能通过定制githooks,并结合bugzilla来控制代码的提交,从而便于问题追踪定位的基于git hooks和缺陷管理工具的监管及跟踪方法。
本发明的目的通过下述技术方案实现:
一种基于git hooks和缺陷管理工具的监管及跟踪方法,包括以下步骤:
(1)通过git客户端向git上的工程分支提交代码,提交代码时填写Message中的信息,Message中的信息包括需求ID或者bug ID;
(2)git服务端收到分支代码的push请求时,将调用git hooks服务端的pre-receive脚本;pre-receive脚本根据git命令获取到代码的提交记录以及Message中的需求ID或者bug ID,并根据需求ID或者bug ID从缺陷管理工具中获取到ID的具体信息;
(3)pre-receive脚本根据从缺陷管理工具中获取到ID的具体信息判断该ID的状态是否允许提交代码、该ID对应的bug是否为可修改状态、提交代码的git分支与该ID对应的分支是否一致;
(4)当步骤(3)判断结果全为“是”时,则pre-receive脚本将代码的提交记录写入缺陷管理工具的相关ID下,并且在写入成功后返回给git客户端“提交成功”;否则返回给git客户端“提交失败”。
进一步的,步骤(1)中Message的格式为【需求#ID】comments、【requirement#ID】comments、【错误#ID】comments或【bug#ID】comments。
再进一步的,步骤(2)中从缺陷管理工具中获取到的ID的具体信息包括:需求或者bug对应的git分支、需求或者bug对应的状态以及该bug的优先级。
为了更好地实现本发明,步骤(2)中pre-receive脚本通过缺陷管理工具的API接口获取ID的具体信息。
为了确保效果,所述缺陷管理工具为bugzilla或redmine。
本发明较现有技术相比,具有以下优点及有益效果:
(1)本发明不仅步骤简单、方便操作,而且能规范代码提交流程,可便于问题追踪;通过定制git hooks并结合缺陷管理工具来监控和跟踪代码的提交,不仅能够减少乱提代码造成的问题,同时能够在出现问题的时候快速追踪定位,保证产品质量,减少开发测试成本。
(2)本发明对于代码的提交只做了三种条件的控制,如果有其他需要,可以根据情况随意增加,方便扩展。
(3)本发明的缺陷管理工具可以根据需要选用bugzilla或redmine或者其他任意提供了API接口的类似工具,因此使得本发明实施时更加灵活方便。
具体实施方式
下面结合实施例对本发明作进一步地详细说明,但本发明的实施方式并不限于此。
实施例
本发明的基于git hooks和缺陷管理工具的监管及跟踪方法,首先通过git客户端向git上的工程分支提交代码,提交代码时填写Message中的信息,该Message中的信息包括需求ID或者bug ID。其中,Message的格式可以为【需求#ID】comments、【requirement#ID】comments、【错误#ID】comments或【bug#ID】comments。
然后,git服务端收到分支代码的push请求时,将调用git hooks服务端的pre-receive脚本。git具有在特定事件发生之前或之后执行特定脚本代码的功能,git hooks就是那些在git执行特定事件(如commit、push、receive等)后触发运行的脚本。git hooks脚本所在的位置可以分为两类:本地hooks,触发事件如commit、merge等;服务端hooks,触发事件如receive等。服务器端hooks的pre-receive脚本为定制脚本,在push代码到远程仓库的时候触发。
然后,pre-receive脚本根据git命令获取到代码的提交记录以及Message中的需求ID或者bug ID,并根据需求ID或者bug ID从缺陷管理工具中获取到ID的具体信息,所述pre-receive脚本是通过缺陷管理工具的API接口获取ID的具体信息。其中,从缺陷管理工具中获取到的ID的具体信息包括:需求或者bug对应的git分支、需求或者bug对应的状态以及该bug的优先级。所述缺陷管理工具为bugzilla、redmine或者其他提供了API接口的类似工具,使用时可根据需要进行选用,本实施例中的缺陷管理工具以bugzilla为例进行说明。
再然后,pre-receive脚本根据从bugzilla中获取到ID的具体信息判断该ID的状态是否允许提交代码、该ID对应的bug是否为可修改状态、提交代码的git分支与该ID对应的分支是否一致。实施时,需求或者bug对应的git分支记为“gitBranch”,需求或者bug对应的状态记为“bugStatus”,该bug的优先级记为“bugPriority”。接下来判断该ID的状态是否允许提交代码,当“bugStatus”为已验收、已拒绝、已发布或已关闭状态时不允许提交代码,否则允许提交代码。判断该ID对应的bug是否为可修改状态时,当“bugPriority”为p1时ID对应的bug为可修改状态,当“bugPriority”为p2时ID对应的bug则为不可修改状态。其中,在bugzilla中“p1”的定义是“可修改”,而p2的定义是“不可修改”。判断提交代码的git分支与该ID对应的分支是否一致时,预先在将通过git客户端向git上的工程分支提交代码时记为“X”分支,当“gitBranch”为X分支时候允许提交代码,否则不允许提交代码。上述三个判断结果全为“是”时,即判断ID的状态为允许提交代码、且判断该ID对应的bug为可修改状态、同时判断提交代码的git分支与该ID对应的分支一致时,则pre-receive脚本将代码的提交记录写入缺陷管理工具的相关ID下,并且在写入成功后将结果“提交成功”返回给git客户端;否则将写入失败结果“提交失败”返回给git客户端。
如上所述,便可较好的实现本发明。
Claims (5)
1.一种基于git hooks和缺陷管理工具的监管及跟踪方法,其特征在于,包括以下步骤:
(1)通过git客户端向git上的工程分支提交代码,提交代码时填写Message中的信息,Message中的信息包括需求ID或者bug ID;
(2)git服务端收到分支代码的push请求时,将调用git hooks服务端的pre-receive脚本;pre-receive脚本根据git命令获取到代码的提交记录以及Message中的需求ID或者bugID,并根据需求ID或者bug ID从缺陷管理工具中获取到ID的具体信息;
(3)pre-receive脚本根据从缺陷管理工具中获取到ID的具体信息判断该ID的状态是否允许提交代码、该ID对应的bug是否为可修改状态、提交代码的git分支与该ID对应的分支是否一致;
(4)当步骤(3)判断结果全为“是”时,则pre-receive脚本将代码的提交记录写入缺陷管理工具的相关ID下,并且在写入成功后返回给git客户端“提交成功”;否则返回给git客户端“提交失败”。
2.根据权利要求1所述的一种基于git hooks和缺陷管理工具的监管及跟踪方法,其特征在于:步骤(1)中Message的格式为【需求#ID】comments、【requirement#ID】comments、【错误#ID】comments或【bug#ID】comments。
3.根据权利要求1或2所述的一种基于git hooks和缺陷管理工具的监管及跟踪方法,其特征在于:步骤(2)中从缺陷管理工具中获取到的ID的具体信息包括:需求或者bug对应的git分支、需求或者bug对应的状态以及该bug的优先级。
4.根据权利要求3所述的一种基于git hooks和缺陷管理工具的监管及跟踪方法,其特征在于:步骤(2)中pre-receive脚本通过缺陷管理工具的API接口获取ID的具体信息。
5.根据权利要求4所述的一种基于git hooks和缺陷管理工具的监管及跟踪方法,其特征在于:所述缺陷管理工具为bugzilla或redmine。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201710228456.7A CN107025112A (zh) | 2017-04-10 | 2017-04-10 | 一种基于git hooks和缺陷管理工具的监管及跟踪方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201710228456.7A CN107025112A (zh) | 2017-04-10 | 2017-04-10 | 一种基于git hooks和缺陷管理工具的监管及跟踪方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN107025112A true CN107025112A (zh) | 2017-08-08 |
Family
ID=59527871
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201710228456.7A Pending CN107025112A (zh) | 2017-04-10 | 2017-04-10 | 一种基于git hooks和缺陷管理工具的监管及跟踪方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN107025112A (zh) |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108563570A (zh) * | 2018-04-10 | 2018-09-21 | 武汉斗鱼网络科技有限公司 | 自动存储代码处理记录的方法、可读存储介质及电子设备 |
CN109359035A (zh) * | 2018-09-19 | 2019-02-19 | 杭州安恒信息技术股份有限公司 | 一种代码质量实时跟踪方法 |
CN109814889A (zh) * | 2019-01-30 | 2019-05-28 | 北京百度网讯科技有限公司 | 用于更新源代码库的方法和装置 |
CN110554882A (zh) * | 2019-08-27 | 2019-12-10 | 上海易点时空网络有限公司 | 代码管理方法及装置 |
CN111459799A (zh) * | 2020-03-03 | 2020-07-28 | 西北大学 | 一种基于Github的软件缺陷检测模型建立、检测方法及系统 |
CN113176881A (zh) * | 2021-04-29 | 2021-07-27 | 广州嘉为科技有限公司 | 基于DevOps的全过程度量方法、系统、设备及介质 |
CN114706567A (zh) * | 2022-06-07 | 2022-07-05 | 广州易方信息科技股份有限公司 | 通过gitlab提交代码关联PM系统任务进度的方法及装置 |
CN114880227A (zh) * | 2022-05-11 | 2022-08-09 | 杭州云合智网技术有限公司 | 一种应用于芯片领域的代码仓库管理方法及系统 |
Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104199667A (zh) * | 2014-09-10 | 2014-12-10 | 南靖万利达科技有限公司 | 一种新建mtk工程和提交代码的方法及系统 |
-
2017
- 2017-04-10 CN CN201710228456.7A patent/CN107025112A/zh active Pending
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104199667A (zh) * | 2014-09-10 | 2014-12-10 | 南靖万利达科技有限公司 | 一种新建mtk工程和提交代码的方法及系统 |
Non-Patent Citations (1)
Title |
---|
SJ: "《Git Hook 整合 Redmine API 自动提交版本变更记录至 Issue》", 20 January 2015 * |
Cited By (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN108563570A (zh) * | 2018-04-10 | 2018-09-21 | 武汉斗鱼网络科技有限公司 | 自动存储代码处理记录的方法、可读存储介质及电子设备 |
CN108563570B (zh) * | 2018-04-10 | 2022-02-08 | 武汉斗鱼网络科技有限公司 | 自动存储代码处理记录的方法、可读存储介质及电子设备 |
CN109359035A (zh) * | 2018-09-19 | 2019-02-19 | 杭州安恒信息技术股份有限公司 | 一种代码质量实时跟踪方法 |
CN109359035B (zh) * | 2018-09-19 | 2022-04-29 | 杭州安恒信息技术股份有限公司 | 一种代码质量实时跟踪方法 |
CN109814889A (zh) * | 2019-01-30 | 2019-05-28 | 北京百度网讯科技有限公司 | 用于更新源代码库的方法和装置 |
CN110554882A (zh) * | 2019-08-27 | 2019-12-10 | 上海易点时空网络有限公司 | 代码管理方法及装置 |
CN111459799A (zh) * | 2020-03-03 | 2020-07-28 | 西北大学 | 一种基于Github的软件缺陷检测模型建立、检测方法及系统 |
CN111459799B (zh) * | 2020-03-03 | 2023-03-10 | 西北大学 | 一种基于Github的软件缺陷检测模型建立、检测方法及系统 |
CN113176881A (zh) * | 2021-04-29 | 2021-07-27 | 广州嘉为科技有限公司 | 基于DevOps的全过程度量方法、系统、设备及介质 |
CN114880227A (zh) * | 2022-05-11 | 2022-08-09 | 杭州云合智网技术有限公司 | 一种应用于芯片领域的代码仓库管理方法及系统 |
CN114880227B (zh) * | 2022-05-11 | 2024-04-05 | 云合智网(上海)技术有限公司 | 一种应用于芯片领域的代码仓库管理方法及系统 |
CN114706567A (zh) * | 2022-06-07 | 2022-07-05 | 广州易方信息科技股份有限公司 | 通过gitlab提交代码关联PM系统任务进度的方法及装置 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN107025112A (zh) | 一种基于git hooks和缺陷管理工具的监管及跟踪方法 | |
US8990714B2 (en) | Replaying captured network interactions | |
US11307948B2 (en) | Fault injection method and apparatus, electronic device and storage medium | |
CN111737127B (zh) | 用于测试地图服务的方法和装置 | |
CN107135218B (zh) | 登录态获取、发送方法、凭证配置方法、客户端及服务器 | |
CN108920354A (zh) | 埋点管理方法、装置、计算机设备和存储介质 | |
CN111552633A (zh) | 接口的异常调用测试方法、装置、计算机设备及存储介质 | |
KR102488582B1 (ko) | 애플리케이션 실행 상태 검증 방법 및 장치 | |
CN108510287B (zh) | 客户回访的判断方法、电子装置及计算机可读存储介质 | |
CN104978530B (zh) | 一种应用安全管理方法、装置、服务器以及系统 | |
US20230289393A1 (en) | Methods and systems for generating custom content using universal deep linking across web and mobile applications | |
US10659311B2 (en) | Method and apparatus for processing delivery data, and storage medium | |
CN107911227B (zh) | 一种断点数据跟进方法、电子装置及计算机可读存储介质 | |
CN114092951A (zh) | 结合rpa及ai的财务票据处理方法、装置、系统、设备及介质 | |
CN104967622A (zh) | 基于声纹的通讯方法、装置和系统 | |
CN109324848A (zh) | 标题栏与页面元素的联动方法、存储介质、电子设备及系统 | |
CN108702368A (zh) | 将附加信息集成到电信呼叫中 | |
CN111831542A (zh) | Api应用调测方法及装置、存储介质 | |
CN111143434A (zh) | 数据智能核对方法、装置、设备及存储介质 | |
CN104471531A (zh) | 捕获会话中的应用状态 | |
CN107657394A (zh) | 航班延误处理系统及方法 | |
CN103561417A (zh) | 提高移动客户端产品对用户请求的响应质量的方法 | |
CN111274520A (zh) | 网页资源审核方法、装置、设备和介质 | |
CN111311194B (zh) | 审讯过程中笔录与录音录像的联动方法、系统及存储介质 | |
CN105721572A (zh) | 终端中使用行为的监控方法和系统 |
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 | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20170808 |
|
RJ01 | Rejection of invention patent application after publication |