A code submission log processing method and device

Abstract

Embodiments of the present invention provide a method and apparatus for processing code commit logs. The method includes: acquiring code commit logs; invoking a check script configured on a code server to perform a specification check on the code commit logs; if the check result is that the code commit logs do not conform to preset specifications, then processing the code commit logs as commit failures; otherwise, submitting the code commit logs to the code server. The solution of the present invention improves code commit specification compliance and execution efficiency by judging the code commit log specification compliance, forcibly intervening in non-compliant commits, and flexibly handling different situations.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a method and device for processing a code submission log. Background Art

[0002] In the process of software development team collaboration, tools such as GIT (an open source distributed version control system used to handle any small or large project in an agile and efficient manner) and SVN (an open source version control system that uses a branch management system for efficient management) are usually used to manage the version of the entire software development process. When developers edit the code and need to submit it, they often need to write a submission log, and the main purpose of the submission log is to tell people on the project what was done in this code submission, so as to facilitate later reading, modification, maintenance, and revocation operations.

[0003] However, individual operations without tools and specifications often result in a variety of submission logs. To avoid this phenomenon, companies have chosen different specifications that suit them to maintain a readable code that is convenient for tracking project history and code review. However, if the specifications are only followed consciously by individuals, they often have little effect, which greatly reduces the efficiency of standardized execution of code submission logs. Summary of the invention

[0004] The present invention provides a method and device for processing code submission logs, which can improve the code submission standardization and execution efficiency by judging the compliance of code submission logs, forcibly intervening in submissions that do not comply with the standards, and flexibly handling different situations.

[0005] To solve the above technical problems, the embodiments of the present invention provide the following solutions:

[0006] A method for processing a code submission log, the method comprising:

[0007] Get code submission log;

[0008] Calling the check script configured on the code server to perform a standard check on the code submission log;

[0009] If the result of the check is that the preset specification is not met, the code submission log is treated as a submission failure, otherwise, the code submission log is submitted to the code server.

[0010] Optionally, the check script is a hook script for a pre-push event.

[0011] Optionally, the hook script of the pre-push event is configured on the server side through the following process:

[0012] Modify the open source project gitlab configuration file for the warehouse management system;

[0013] Run the sudo gitlab-ctl reconfigure command to make the configuration take effect;

[0014] Create the following three folders in the custom hook script directory: the first folder, the second folder, and the third folder, which correspond to the three types of global hooks respectively. Create an executable script in each folder. During the corresponding hook period, including before, during, and after the code is stored in the library, Gitlab actively calls the hook script.

[0015] Optionally, the code submission log includes: a list of all new submission logs of the local branch relative to the remote branch as the code submission log for this submission.

[0016] Optionally, a check script configured on the code server is called to perform a standard check on the code submission log, including:

[0017] The submission log information in the submission log list is compared with the preset rules one by one. If all the submission logs in the submission log list meet the rules, they are submitted to the database normally. If any one does not meet the rules, the submission fails.

[0018] Optionally, the preset rule is: <type> - <jiraid> : <subject>,in <type>Indicates the submission type; <jiraid>An ID number that indicates the specific defect; <subject>Indicates a short description of the content of this submission.

[0019] Optionally, if all the submission logs in the submission log list meet the rules, they will be submitted to the repository normally. If any one of them does not meet the rules, the submission will fail, including:

[0020] Check the submission log format in the submission log list one by one to see if it meets the requirements. <type>Is it a preset type? If yes, check <jiraid>Is it true and valid? If it is valid, check whether the JIRAID is in a non-closed state. If it is, submit it to the warehouse normally. Otherwise, if any of the conditions are not met, all submissions will fail.

[0021] Optionally, the method for processing code submission logs further includes at least one of the following:

[0022] For the submission log of the junction point of two branches, when obtaining the submission log list through the inspection script, the submission log of the junction point of the two branches is deleted through the preset parameters;

[0023] For the new branch's commit log list, submit it to the code server normally;

[0024] For the specified exclusion repository list, when the submission code triggers the hook check, check whether the current repository URL is in the specified exclusion repository list. If the current repository is in the exclusion repository list, it passes the specification check directly and is submitted normally. If not, check whether it is a new branch. If it is a new branch, it passes the specification check and is submitted normally. If it is not a new branch, check whether all new submissions except the junction of the two branches meet the specifications. If all meet the specifications, it is submitted normally, otherwise the submission fails.

[0025] Optionally, the inspection script is effective for all warehouses, or the warehouses are classified, and logic for performing different standard inspections on warehouses of different categories is added to the inspection script, so that different inspection rules are configured for warehouses of different categories.

[0026] An embodiment of the present invention further provides a device for processing a code submission log, comprising:

[0027] Acquisition module, used to obtain code submission logs;

[0028] The processing module is used to call the inspection script configured on the code server to perform a standard inspection on the code submission log; if the inspection result is that it does not meet the preset specifications, the code submission log is treated as a submission failure, otherwise, the code submission log is submitted to the code server.

[0029] An embodiment of the present invention further provides a communication device, comprising: a processor and a memory storing a computer program, wherein when the computer program is executed by the processor, the method described above is executed.

[0030] An embodiment of the present invention further provides a computer-readable storage medium, comprising instructions, which, when executed on a computer, enable the computer to execute the method described above.

[0031] The above solution of the present invention includes at least the following beneficial effects:

[0032] The above scheme of the present invention obtains the code submission log; calls the check script configured on the code server to perform a standard check on the code submission log; if the check result is that it does not meet the preset specifications, the code submission log is treated as a submission failure, otherwise, the code submission log is submitted to the code server. The compliance of the code submission log is judged, and submissions that do not meet the specifications are intervened forcibly, and different situations are handled flexibly, thereby improving the compliance of code submission and execution efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] Figure 1 A schematic diagram of a process flow of a method for processing code submission logs according to an embodiment of the present invention;

[0034] Figure 2 A schematic diagram of a check flow of a code submission log of an embodiment of the present invention;

[0035] Figure 3 A schematic diagram of a check flow of a special submission log according to an embodiment of the present invention;

[0036] Figure 4 A schematic diagram of a flow chart for checking whether it is a new branch according to an embodiment of the present invention;

[0037] Figure 5 It is a schematic diagram of the inspection process of a special warehouse according to an embodiment of the present invention;

[0038] Figure 6 A flowchart of configuring different inspection rules for different projects in an embodiment of the present invention;

[0039] Figure 7 A schematic diagram of a module of a device for processing code submission logs according to an embodiment of the present invention. DETAILED DESCRIPTION

[0040] The exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although the exemplary embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present invention can be implemented in various forms and should not be limited by the embodiments set forth herein. On the contrary, these embodiments are provided in order to enable a more thorough understanding of the present invention and to fully convey the scope of the present invention to those skilled in the art.

[0041] like Figure 1 As shown, an embodiment of the present invention provides a method for processing a code submission log, the method comprising:

[0042] Step 11, obtain the code submission log;

[0043] Step 12: Call the check script configured on the code server to perform a standard check on the code submission log;

[0044] Step 13: If the result of the check is that the code does not meet the preset specification, the code submission log is treated as a submission failure; otherwise, the code submission log is submitted to the code server.

[0045] This embodiment of the present invention determines the compliance of code submission log specifications, forcibly intervenes in submissions that do not comply with specifications, and flexibly handles different situations, thereby improving code submission standardization and execution efficiency.

[0046] In an optional embodiment of the present invention, the check script is a hook script for a pre-push event. In this embodiment of the present invention, gitlab is used as a code management tool. By calling the hook script for the pre-push event, the hook can be configured on the gitlab server to take effect on all repositories, or it can be configured in a certain repository and only take effect on the current repository.

[0047] In an optional embodiment of the present invention, the hook script of the pre-push event is configured on the server side through the following process:

[0048] Modify the open source project gitlab configuration file for the warehouse management system;

[0049] Run the sudo gitlab-ctl reconfigure command to make the configuration take effect;

[0050] Create the following three folders in the custom hook script directory: the first folder, the second folder, and the third folder, which correspond to the three types of global hooks respectively. Create an executable script in each folder. During the corresponding hook period, including before, during, and after the code is stored in the library, Gitlab actively calls the hook script.

[0051] In this embodiment, since the standardization check is for all projects, it is configured on the server side, that is, a global hook. After the configuration takes effect, it will be triggered each time the code is submitted, that is, before the formal submission to the warehouse, the hook script is called to perform a standardization check on all submissions pushed this time (one push may include multiple submissions).

[0052] Specifically, the global hook is configured on the gitlab code server as follows:

[0053] Modify the gitlab configuration file: / etc / gitlab / gitlab.rb configuration items and set the directory where the custom hook script is stored:

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

[0055] Run the sudo gitlab-ctl reconfigure command to make the configuration take effect.

[0056] Create the following three folders in the custom hook script directory: pre-received.d, update.d, and post-receive.d, which correspond to three types of global hooks respectively. You can create an executable script in each folder. Gitlab will actively call it during the corresponding hook period, including before, during, and after the code is stored in the library.

[0057] The pre-push script for this application is placed in the above-mentioned pre-received.d directory. The pre-push script is called to perform a compliance check before the server accepts the code into the library.

[0058] In an optional embodiment of the present invention, the code submission log includes: a list of all new submission logs of the local branch relative to the remote branch as the code submission log for this submission.

[0059] In an optional embodiment of the present invention, a check script configured on the code server is called to perform a standard check on the code submission log, including:

[0060] The submission log information in the submission log list is compared with the preset rules one by one. If all the submission logs in the submission log list meet the rules, they are submitted to the database normally. If any one does not meet the rules, the submission fails.

[0061] Optionally, the preset rule is: <type> - <jiraid> : <subject>,in <type>Indicates the submission type; <jiraid>An ID number that indicates the specific defect; <subject>Indicates a short description of the content of this submission.

[0062] Optionally, if all the submission logs in the submission log list meet the rules, they will be submitted to the repository normally. If any one of them does not meet the rules, the submission will fail, including:

[0063] Check the submission log format in the submission log list one by one to see if it meets the requirements. <type>Is it a preset type? If yes, check <jiraid>Is it true and valid? If it is valid, check whether the JIRAID is in a non-closed state. If it is, submit it to the warehouse normally. Otherwise, if any of the conditions are not met, all submissions will fail.

[0064] The code submission log standardization check function implemented by the Pre-push script is as follows:

[0065] Extract specification inspection objects;

[0066] Take the list of all new commit logs of the local branch relative to the remote branch as the inspection object for this commit;

[0067] Compare with preset rules;

[0068] Compare the submission log information in the obtained list with the preset rules one by one. If all submissions in the list meet the rules, they will be submitted to the database normally. If any one does not meet the rules, the submission fails and the failure information is printed, including the submission log id and the reason for the failure.

[0069] The preset rules here can be flexibly set according to the needs of each company. For example, we can refer to the widely used angular specification in the industry and combine it with the defect tracking management tool JIRA: <type> - <jiraid> : <subject>,in <type>Indicates the submission type, which can be: feat, fix, refactor, style, docs, test, chore; <jiraid>Indicates the ID number of a specific defect; <subject>A short description of the content of this submission. <jiraid>During the inspection, you can also use the JIRA API interface to query the JIRA server whether the JIRA is authentic and valid and whether the status meets the requirements.

[0070] Check the process as Figure 2 As shown: Submit code to trigger hook check, get the list of submitted logs, check whether the submitted log format is consistent one by one, and if it is consistent, check <type>Is it one of the 7 types? If yes, check <jiraid>Is it true and valid? If it is valid, check whether the JIRAID is in a non-closed state. If it is, submit successfully. Otherwise, if any of the conditions are not met, all submissions will be forced to fail.

[0071] In an optional embodiment of the present invention, the method for processing code submission logs further includes at least one of the following:

[0072] 1) For the submission log of the junction point of two branches, when obtaining the submission log list through the inspection script, the submission log of the junction point of the two branches is deleted according to the preset parameters;

[0073] 2) For the new branch's commit log list, submit it to the code server normally;

[0074] 3) For the specified exclusion repository list, when the submission code triggers the hook check, check whether the current repository URL is in the specified exclusion repository list. If the current repository is in the exclusion repository list, it passes the specification check directly and is submitted normally; if not, check whether it is a new branch. If it is a new branch, it passes the specification check and is submitted normally; if it is not a new branch, check whether all new submissions except the junction of the two branches meet the specifications. If all meet the specifications, it is submitted normally, otherwise the submission fails.

[0075] Optionally, the inspection script is effective for all warehouses, or the warehouses are classified, and logic for performing different standard inspections on warehouses of different categories is added to the inspection script, so that different inspection rules are configured for warehouses of different categories.

[0076] In this example, the specification check is skipped for a specific commit, new branch, or specific repository:

[0077] like Figure 3 As shown in the figure, for some special commits, such as merge commits, the merge commit here refers to a commit log automatically generated after executing the merge command. This commit log is only the junction of two branches and a modification of non-project functions. It itself has no meaning for the project and is automatically generated. There is no need to do a standard check. When the pre-push script obtains the commit log list, this type of commit log can be removed through the git parameter --no-merges.

[0078] Many development processes are initially based on modifications to some open source code. Developers will develop based on some existing historical commits of the open source code. The submission history of the open source code often does not conform to the submission specifications of a certain company, and it is impossible for developers to correct hundreds of historical commits of the open source code one by one. Therefore, it is not necessary to check the new branch that contains the historical commits of the open source code that is pushed for the first time.

[0079] like Figure 4 As shown, the present invention can remove the check of new branches, and the process of checking whether it is a new branch is as follows:

[0080] The commit code triggers the hook check, and then a commit id interval to be submitted is extracted for inspection (each commit log corresponds to a commit id, and the interval is the commit log list). The commit id is a 40-bit SHA-1 hash value. For a new branch, the starting value of this interval is composed of 40 bits of 0. Therefore, as long as the starting value is 40 bits of 0, it is judged that a new branch has been pushed, and it is determined that this specification check has passed and is submitted normally; otherwise, the submission log information is checked one by one.

[0081] like Figure 5 As shown, for some warehouses, due to their particularity, they already have a set of special specifications applicable to the warehouse, and do not want to share a set of specifications with the company. That is, for the warehouse, it is necessary to exclude the restrictions of the global hook. You can specify an excluded warehouse list in the pre-push script. When submitting the code to trigger the hook check, run gitremote-v in the hook script to get the URL of the current warehouse, and check whether the current warehouse URL is in the specified excluded warehouse list. If the current warehouse is in the excluded warehouse list, it will pass the specification check directly and submit normally; if not, check whether it is a new branch. If it is a new branch, it will pass the specification check and submit normally; if it is not a new branch, check whether all new submissions except merge meet the specifications. If all meet the specifications, submit normally, otherwise the submission fails.

[0082] like Figure 6 As shown, different inspection rules are configured for different projects:

[0083] For some non-functional development warehouses, such as document warehouses, there are no defects, so the submission information does not need to be tracked by JIRA. Therefore, for different types of projects, the inspection rules may be inconsistent. Therefore, the project URL can be classified, and the URL lists of warehouses of different categories can be stored in different rule files in advance, and they can be processed separately in the pre-push hook script. For example, the warehouse is divided into three categories in advance, and the URLs of the corresponding warehouses are stored in three files A.rule, B.rule, and C.rule respectively. When the push code triggers the hook, execute gitremote-v in the hook script to obtain the URL of the current warehouse, traverse the URL belonging to B.rule, extract the log list of this submission, and execute the inspection rules set in advance in the corresponding B.rule rule file.

[0084] The above-mentioned embodiment of the present invention calls the pre-push hook to perform a compliance check while the code is submitted, monitors the compliance of the code log specifications in real time, and forces the submission of logs that do not comply with the specifications to fail. That is, all the codes entered into the warehouse are compliant with the specifications, which comprehensively and thoroughly optimizes the code log submission specifications.

[0085] In addition, the hook is triggered at submission time and interacts with the code server. Therefore, it can be configured by the administrator to take effect uniformly on the code server without the need for developers to make any configuration on the client side, thus avoiding rule loopholes caused by the non-cooperation of individual personnel.

[0086] The above-mentioned embodiments of the present invention have a wide range of applications. The pre-push hook is a hook supported by git itself, and is therefore applicable to all git-based code management tools. The storage locations and configuration files of the hook scripts of different tools are different.

[0087] The above-mentioned embodiment of the present invention is more flexible. By adjusting the hook script, the submission log check of the specified type, new branch, and specified repository can be skipped, and different check rules can be set for different project repositories.

[0088] like Figure 7 As shown, an embodiment of the present invention further provides a code submission log processing device 70, comprising:

[0089] An acquisition module 71 is used to acquire a code submission log;

[0090] The processing module 72 is used to call the check script configured on the code server to perform a standard check on the code submission log; if the check result is that it does not meet the preset standards, the code submission log is treated as a submission failure, otherwise, the code submission log is submitted to the code server.

[0091] Optionally, the check script is a hook script for a pre-push event.

[0092] Optionally, the hook script of the pre-push event is configured on the server side through the following process:

[0093] Modify the open source project gitlab configuration file for the warehouse management system;

[0094] Run the sudo gitlab-ctl reconfigure command to make the configuration take effect;

[0095] Create the following three folders in the custom hook script directory: the first folder, the second folder, and the third folder, which correspond to the three types of global hooks respectively. Create an executable script in each folder. During the corresponding hook period, including before, during, and after the code is stored in the library, Gitlab actively calls the hook script.

[0096] Optionally, the code submission log includes: a list of all new submission logs of the local branch relative to the remote branch as the code submission log for this submission.

[0097] Optionally, a check script configured on the code server is called to perform a standard check on the code submission log, including:

[0098] The submission log information in the submission log list is compared with the preset rules one by one. If all the submission logs in the submission log list meet the rules, they are submitted to the database normally. If any one does not meet the rules, the submission fails.

[0099] Optionally, the preset rule is: <type> - <jiraid> : <subject>,in <type>Indicates the submission type; <jiraid>An ID number that indicates the specific defect; <subject>Indicates a short description of the content of this submission.

[0100] Optionally, if all the submission logs in the submission log list meet the rules, they will be submitted to the repository normally. If any one of them does not meet the rules, the submission will fail, including:

[0101] Check the submission log format in the submission log list one by one to see if it meets the requirements. <type>Is it a preset type? If yes, check <jiraid>Is it true and valid? If it is valid, check whether the JIRAID is in a non-closed state. If it is, submit it to the warehouse normally. Otherwise, if any of the conditions are not met, all submissions will fail.

[0102] Optionally, the method for processing code submission logs further includes at least one of the following:

[0103] For the submission log of the junction point of two branches, when obtaining the submission log list through the inspection script, the submission log of the junction point of the two branches is deleted through the preset parameters;

[0104] For the new branch's commit log list, submit it to the code server normally;

[0105] For the specified exclusion repository list, when the submission code triggers the hook check, check whether the current repository URL is in the specified exclusion repository list. If the current repository is in the exclusion repository list, it passes the specification check directly and is submitted normally. If not, check whether it is a new branch. If it is a new branch, it passes the specification check and is submitted normally. If it is not a new branch, check whether all new submissions except the junction of the two branches meet the specifications. If all meet the specifications, it is submitted normally, otherwise the submission fails.

[0106] Optionally, the inspection script is effective for all warehouses, or the warehouses are classified, and logic for performing different standard inspections on warehouses of different categories is added to the inspection script, so that different inspection rules are configured for warehouses of different categories.

[0107] It should be noted that the device is a device corresponding to the above method, and all implementation methods in the above method embodiments are applicable to the embodiments of the device and can achieve the same technical effects.

[0108] The embodiment of the present invention also provides a code submission log processing device, including: a processor, a memory storing a computer program, and when the computer program is executed by the processor, the method described above is executed. All implementation methods in the above method embodiment are applicable to this embodiment and can achieve the same technical effect.

[0109] The embodiment of the present invention further provides a computer-readable storage medium, including instructions, which, when executed on a computer, enable the computer to execute the method described above. All implementations in the above method embodiment are applicable to this embodiment and can achieve the same technical effect.

[0110] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.

[0111] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0112] In the embodiments provided by the present invention, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0113] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0114] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0115] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium, including several instructions for a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present invention. The aforementioned storage medium includes: various media that can store program codes, such as USB flash drives, mobile hard disks, ROM, RAM, magnetic disks, or optical disks.

[0116] In addition, it should be noted that in the apparatus and method of the present invention, it is obvious that each component or each step can be decomposed and / or recombined. These decompositions and / or recombinations should be regarded as equivalent schemes of the present invention. Moreover, the steps of performing the above-mentioned series of processing can naturally be performed in chronological order according to the order of description, but it is not necessary to perform them in chronological order, and some steps can be performed in parallel or independently of each other. For those of ordinary skill in the art, it is understood that all or any steps or components of the method and apparatus of the present invention can be implemented in any computing device (including processors, storage media, etc.) or a network of computing devices in hardware, firmware, software or a combination thereof, which can be achieved by those of ordinary skill in the art using their basic programming skills after reading the description of the present invention.

[0117] Therefore, the purpose of the present invention can also be achieved by running a program or a group of programs on any computing device. The computing device can be a well-known general device. Therefore, the purpose of the present invention can also be achieved by simply providing a program product containing a program code that implements the method or device. That is to say, such a program product also constitutes the present invention, and the storage medium storing such a program product also constitutes the present invention. Obviously, the storage medium can be any well-known storage medium or any storage medium developed in the future. It should also be pointed out that in the device and method of the present invention, it is obvious that each component or each step can be decomposed and / or recombined. These decompositions and / or recombinations should be regarded as equivalent schemes of the present invention. In addition, the steps of performing the above-mentioned series of processing can naturally be performed in chronological order according to the order of description, but it is not necessary to perform them in chronological order. Some steps can be performed in parallel or independently of each other.

[0118] The above is a preferred embodiment of the present invention. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present invention. These improvements and modifications should also be regarded as the scope of protection of the present invention.< / jiraid> < / type> < / subject> < / jiraid> < / type> < / subject> < / jiraid> < / type> < / jiraid> < / type> < / jiraid> < / subject> < / jiraid> < / type> < / subject> < / jiraid> < / type> < / jiraid> < / type> < / subject> < / jiraid> < / type> < / subject> < / jiraid> < / type> < / jiraid> < / type> < / subject> < / jiraid> < / type> < / subject> < / jiraid> < / type>

Claims

1. A method for processing code submission logs, characterized in that: The method comprises: Get code submission log; Calling the check script configured on the code server to perform a standard check on the code submission log; If the result of the check is that it does not meet the preset specifications, the code submission log is treated as submission failure, otherwise, the code submission log is submitted to the code server; Also includes: For the submission log of the junction point of two branches, when obtaining the submission log list through the inspection script, the submission log of the junction point of the two branches is deleted according to the preset parameters; For the new branch's commit log list, submit it to the code server normally; For the specified exclusion repository list, when the submission code triggers the hook check, check whether the current repository URL is in the specified exclusion repository list. If the current repository is in the exclusion repository list, it passes the specification check directly and is submitted normally. If not, check whether it is a new branch. If it is a new branch, it passes the specification check and is submitted normally. If it is not a new branch, check whether all new submissions except the junction of the two branches meet the specifications. If all meet the specifications, it is submitted normally, otherwise the submission fails.

2. The method for processing code submission logs according to claim 1, characterized in that: The checking script is a hook script for the pre-push event.

3. The method for processing code submission logs according to claim 2, characterized in that: The hook script of the pre-push event is configured on the server side through the following process: Modify the open source project gitlab configuration file for the warehouse management system; Run the sudo gitlab-ctl reconfigure command to make the configuration take effect; Create the following three folders in the custom hook script directory: the first folder, the second folder, and the third folder, which correspond to the three types of global hooks respectively. Create an executable script in each folder. During the corresponding hook period, including before, during, and after the code is stored in the library, Gitlab actively calls the hook script.

4. The method for processing code submission logs according to claim 1, characterized in that: The code submission log includes: a list of all new submission logs of the local branch relative to the remote branch as the code submission log for this submission.

5. The method for processing code submission logs according to claim 4, characterized in that: Call the check script configured on the code server to perform a standard check on the code submission log, including: The submission log information in the submission log list is compared with the preset rules one by one. If all the submission logs in the submission log list meet the rules, they are submitted to the database normally. If any one does not meet the rules, the submission fails.

6. The method for processing code submission logs according to claim 5, characterized in that: The preset rules are: <type> - <jiraid> : <subject>,in <type>Indicates the submission type; <jiraid>An ID number that indicates the specific defect; <subject> Indicates a short description of the content of this submission.< / subject> < / jiraid> < / type> < / subject> < / jiraid> < / type> 7. The method for processing code submission logs according to claim 6, characterized in that: If all submission logs in the submission log list comply with the rules, they will be submitted normally. If any one does not comply with the rules, the submission will fail, including: Check the submission log format in the submission log list one by one to see if it meets the requirements. <type>Is it a preset type? If yes, check <jiraid> Is it true and valid? If it is valid, check whether the JIRAID is in a non-closed state. If it is, submit it to the warehouse normally. Otherwise, if any of the conditions are not met, all submissions will fail.< / jiraid> < / type> 8. The method for processing code submission logs according to claim 1, characterized in that: The inspection script is effective for all warehouses, or the warehouses are classified, and logic for performing different standard inspections on warehouses of different categories is added to the inspection script, so that different inspection rules are configured for warehouses of different categories.

9. A code submission log processing device, characterized in that: include: Acquisition module, used to obtain code submission logs; A processing module, used to call a check script configured on the code server to perform a standard check on the code submission log; If the result of the check is that it does not meet the preset specifications, the code submission log is treated as submission failure, otherwise, the code submission log is submitted to the code server; Also includes: For the submission log of the junction point of two branches, when obtaining the submission log list through the inspection script, the submission log of the junction point of the two branches is deleted according to the preset parameters; For the new branch's commit log list, submit it to the code server normally; For the specified exclusion repository list, when the submission code triggers the hook check, check whether the current repository URL is in the specified exclusion repository list. If the current repository is in the exclusion repository list, it passes the specification check directly and is submitted normally. If not, check whether it is a new branch. If it is a new branch, it passes the specification check and is submitted normally. If it is not a new branch, check whether all new submissions except the junction of the two branches meet the specifications. If all meet the specifications, it is submitted normally, otherwise the submission fails.

10. A code submission log processing device, characterized in that: include: A processor and a memory storing a computer program, wherein when the computer program is executed by the processor, the method according to any one of claims 1 to 8 is performed.

11. A computer-readable storage medium, characterized in that: The method comprises instructions, which, when executed on a computer, cause the computer to execute the method according to any one of claims 1 to 8.

Images