Code push method, device, electronic device and readable medium

Abstract

The present application relates to a code push method, device, electronic device and readable medium, wherein the method comprises: upon receiving a code submission instruction, obtaining the target code to be submitted and the annotation file associated with the target code, wherein the annotation file includes the basic content of the target code and the modified content of the target code; performing a security check on the target code and the annotation file to obtain a first test result; when the first test result indicates that the target code and the annotation file pass the security check, submitting the target code to a local warehouse; upon receiving a push instruction for the target code, determining a remote branch from the push instruction, and verifying whether the local branch and the remote branch to which the target code belongs meet the push conditions; if the remote branch and the local branch meet the push conditions, pushing the target code and the annotation file to the remote branch. The problem of code push accidents caused by non-standard push content is solved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a code push method, device, electronic device and readable medium. Background Art

[0002] Git is an open source distributed version control system that can effectively and quickly handle version management of projects from very small to very large. Code push refers to the process of uploading code changes in the local repository to the remote repository. This usually happens after the developer has completed a series of code modifications, tests, and confirmed that they are correct, and hopes to share these changes with other team members or back them up to the remote repository. When Git pushes code, users are often required to manually enter information such as the remote repository name, local branch name, and remote branch name, and they are also required to manually verify whether the local branch name matches the remote branch name. It is common for users to push modified code to the wrong remote branch. In addition, in the code submission stage before pushing, it is easy for the code to be non-standard and manual review is not in place, resulting in code upload violations.

[0003] Most of the current code push methods still rely on manual review, which can easily lead to push accidents due to various reasons. Finding the cause of the push accident after it occurs will also increase the workload. In other words, there is a problem of code push accidents caused by non-standard push content.

[0004] To address the above-mentioned problems, no effective solution has been proposed yet. Summary of the invention

[0005] The present application provides a code push method, device, electronic device and readable medium to solve the above-mentioned technical problem of "code push accidents caused by non-standard push content".

[0006] According to one aspect of an embodiment of the present application, the present application provides a code push method, comprising: when receiving a code submission instruction, obtaining the target code to be submitted and an annotation file associated with the target code, wherein the annotation file includes the basic content of the target code and the changed content of the target code; performing a security check on the target code and the annotation file to obtain a first test result; when the first test result indicates that the target code and the annotation file pass the security check, submitting the target code to a local repository; when receiving a push instruction for the target code, determining a remote branch from the push instruction, and verifying whether the local branch and the remote branch to which the target code belongs meet the push conditions; if the remote branch and the local branch meet the push conditions, pushing the target code and the annotation file to the remote branch.

[0007] Optionally, a security check is performed on the target code and the annotation file to obtain a first test result, including: checking the validity of the annotation file to obtain a second test result; when the second test result indicates that the annotation file is valid, statically checking the target code to obtain a third test result; when the third test result indicates that there are no defects in the target code, performing a targeted test on the target code according to the submission type of the target code to obtain a fourth test result; when the fourth test result indicates that the target code passes the targeted test, passing the security test for the target code and the annotation file is taken as the first test result.

[0008] Optionally, detecting the validity of the annotation file includes: detecting whether the format of the annotation file complies with a preset format specification; and detecting whether the annotation information in the annotation file includes change information of the target code.

[0009] Optionally, after obtaining the second test result, the method further includes: when the second test result indicates that the annotation file is not valid, stopping the test, and taking the failure of the target code and the annotation file to pass the security test as the first test result; or when the third test result indicates that there is a defect in the target code, stopping the test, and taking the failure of the target code and the annotation file to pass the security test as the first test result; or when the fourth test result indicates that the target code has failed the targeted test, taking the failure of the target code and the annotation file to pass the security test as the first test result.

[0010] Optionally, verifying whether the local branch and remote branch to which the target code belongs meet the push conditions includes: verifying whether the remote branch exists in the remote repository; if the remote branch exists in the remote repository, verifying whether the local branch correctly tracks the remote branch; if the local branch correctly tracks the remote branch, determining that the local branch and the remote branch meet the push conditions.

[0011] Optionally, if any of the following situations exists, it is determined that the local branch and the remote branch do not meet the push condition: the remote branch does not exist in the remote repository; the local branch cannot correctly track the remote branch.

[0012] Optionally, before pushing the target code and annotation file to the remote branch, the method further includes: checking whether there is a code change identifier in the annotation file; if there is no code change identifier in the annotation file, obtaining the code change identifier; and adding the code change identifier to the annotation file.

[0013] According to another aspect of an embodiment of the present application, the present application provides a code pushing device, including: an acquisition module, which is used to acquire the target code to be submitted and the annotation file associated with the target code when a code submission instruction is received, wherein the annotation file includes the basic content of the target code and the changed content of the target code; a detection module, which is used to perform a security check on the target code and the annotation file to obtain a first detection result; a submission module, which is used to submit the target code to a local repository when the first detection result indicates that the target code and the annotation file pass the security check; a verification module, which is used to determine the remote branch from the push instruction when a push instruction for the target code is received, and to verify whether the local branch and the remote branch to which the target code belongs meet the push conditions; a push module, which is used to push the target code and the annotation file to the remote branch if the remote branch and the local branch meet the push conditions.

[0014] According to another aspect of an embodiment of the present application, the present application provides an electronic device, including a memory, a processor, a communication interface and a communication bus, wherein the memory stores a computer program that can be run on the processor, the memory and the processor communicate through the communication bus and the communication interface, and the steps of the above method are implemented when the processor executes the computer program.

[0015] According to another aspect of an embodiment of the present application, the present application also provides a computer-readable medium having a non-volatile program code executable by a processor, and the program code enables the processor to execute the above method.

[0016] The above technical solution provided by the embodiment of the present application has the following advantages compared with the related art:

[0017] The present application adopts a code push method, including: when receiving a code submission instruction, obtaining the target code to be submitted and the annotation file associated with the target code, wherein the annotation file includes the basic content of the target code and the modified content of the target code; performing a security check on the target code and the annotation file to obtain a first test result; when the first test result indicates that the target code and the annotation file pass the security check, submitting the target code to the local warehouse; when receiving a push instruction for the target code, determining the remote branch from the push instruction, and verifying whether the local branch and the remote branch to which the target code belongs meet the push conditions; if the remote branch and the local branch meet the push conditions, pushing the target code and the annotation file to the remote branch. By automatically performing a security check when the code is submitted, and verifying and confirming that the local branch and the remote branch meet the push conditions before pushing the code, the standardization of the entire code push process is guaranteed, and the problem of code push accidents caused by non-standard push content is solved. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0019] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the related technologies, the drawings required for use in the embodiments or the related technical descriptions are briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0020] Figure 1 A flowchart of an optional code push method provided according to an embodiment of the present application;

[0021] Figure 2 A schematic diagram of an optional system for executing code push according to an embodiment of the present application;

[0022] Figure 3 A block diagram of an optional code push device provided according to an embodiment of the present application;

[0023] Figure 4 A schematic diagram of an optional electronic device structure provided in an embodiment of the present application. DETAILED DESCRIPTION

[0024] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0025] In the subsequent description, the suffixes such as "module", "component" or "unit" used to represent elements are only used to facilitate the description of the present application and have no specific meaning. Therefore, "module" and "component" can be used interchangeably.

[0026] Git is an open source distributed version control system that can effectively and quickly handle version management of projects from very small to very large. Code push refers to the process of uploading code changes in the local repository to the remote repository. This usually happens after the developer has completed a series of code modifications, tests, and confirmed that they are correct, and hopes to share these changes with other team members or back them up to the remote repository. When Git pushes code, users are often required to manually enter information such as the remote repository name, local branch name, and remote branch name, and they are also required to manually verify whether the local branch name matches the remote branch name. It is common for users to push modified code to the wrong remote branch. In addition, in the code submission stage before pushing, it is easy for the code to be non-standard and manual review is not in place, resulting in code upload violations.

[0027] Most of the current code push methods still rely on manual review, which can easily lead to push accidents due to various reasons. Finding the cause of the push accident after it occurs will also increase the workload. In other words, there is a problem of code push accidents caused by non-standard push content.

[0028] In order to solve the problems mentioned in the background technology, according to one aspect of the embodiment of the present application, a code push method is provided, such as Figure 1 As shown, including:

[0029] Step 101, upon receiving a code submission instruction, obtaining the target code to be submitted and an annotation file associated with the target code, wherein the annotation file includes the basic content of the target code and the modified content of the target code;

[0030] Step 102, performing security detection on the target code and the annotation file to obtain a first detection result;

[0031] Step 103, when the first test result indicates that the target code and the annotation file pass the security test, submit the target code to the local warehouse;

[0032] Step 104, when receiving a push instruction for the target code, determine the remote branch from the push instruction, and verify whether the local branch and the remote branch to which the target code belongs meet the push condition;

[0033] Step 105: If the remote branch and the local branch meet the push conditions, the target code and the annotation file are pushed to the remote branch.

[0034] In order to solve the problem of code push accidents caused by non-standard push content, the present application provides an embodiment of automatic detection during the code push process. Specifically, by automatically performing security detection when the code is submitted, and verifying that the local branch and the remote branch meet the push conditions before pushing the code, the standardization of the entire code push process is ensured, and the occurrence of code push accidents is reduced.

[0035] The code submission instruction is issued by the user. Before issuing the code submission instruction, the user will pre-store the modified target code and the edited annotation file in the temporary storage area. After the target code and the annotation file pass the security check, the target code and the annotation file will be submitted from the temporary storage area to the local warehouse. If the target code and the annotation file do not pass the security check, the code submission operation will not be performed to prevent non-compliant code submission.

[0036] In this application, you can submit the code multiple times and then push it together, or you can submit it once, push it once, and repeat the operation.

[0037] The code submitted to the local repository is the code waiting to be pushed. Once the user issues a push instruction, it will automatically check whether the remote branch and the local branch meet the push conditions. If the push conditions are met, the code push operation will be executed. If the push conditions are not met, the code push operation will not be executed to avoid push failures.

[0038] Figure 2 A schematic diagram of a system for executing code push provided for this application. As shown in the figure, the system can be understood as an upgraded version based on git. In addition to the functions of conventional git, the system also has some upgraded customized functions (automatic detection). Users can view help information (such as detailed instructions for submitting code, pushing code, and installing code) through the system; users can also submit code through the system, and the system will automatically perform security detection, where security detection includes rule detection and static code detection; users can also push code through the system, and after receiving the push instruction entered by the user, the system automatically performs branch matching detection; users can also install the system and use it directly.

[0039] By adopting the technical solution of the present application, code compliance can be automatically detected when submitting code, problems can be discovered earlier and the workload of manual review can be reduced, which greatly improves the compliance rate of the code. When pushing code, erroneous pushes can be prevented in time, which can reduce the losses caused by push accidents.

[0040] As an optional embodiment, a security check is performed on the target code and the annotation file to obtain a first test result, including: checking the validity of the annotation file to obtain a second test result; when the second test result indicates that the annotation file is valid, statically checking the target code to obtain a third test result; when the third test result indicates that there are no defects in the target code, performing a targeted test on the target code according to the submission type of the target code to obtain a fourth test result; when the fourth test result indicates that the target code passes the targeted test, passing the security test for the target code and the annotation file is taken as the first test result.

[0041] The security testing provided in this application mainly includes testing of the validity of annotation files, testing of the compliance of target codes, and targeted testing of target codes based on submission types. Only when all three aspects are tested can it be determined that the target code and annotation files have passed the security testing.

[0042] Specifically, checking the validity of the annotation file includes checking whether the format of the annotation file is standardized and whether the content is accurate and clear. The specific test content is shown below.

[0043] Specifically, static detection of the target code includes detecting whether there are risks in the writing of the code (eg, memory leaks, non-standard variable definitions).

[0044] Preferably, cppcheck can be used to perform static detection on the target code. cppcheck is a static code analysis tool that can check whether the code has potential errors without running the program, such as unused variables, invalid pointer dereferences, memory leak indicators, non-compliant code, etc. Of course, other code detection tools can also be configured to perform static detection according to actual needs.

[0045] Specifically, different submission types (such as whether the submitted code is the original code, the different upload paths where the code is located, and the different libraries to which the code belongs, etc.) may involve different types of code changes, which may bring different security risks. Therefore, this application also performs targeted detection on the target code according to the submission type of the target code, which involves a lot of detection content.

[0046] In the security testing of the code submission stage, this application actually performs rule testing, which is to formulate different rules according to the code, different submission types and other aspects (such as the library where the submitted code is located). The number of rules can be set according to the actual situation, and the number can be increased or decreased and the rules can be customized according to the actual situation. As long as the code and submission type meet the triggering conditions of the rules, the corresponding rules will be automatically used for testing.

[0047] The rule detection method provided in this application is configurable and extensible. The configurability is reflected in that different code detection tools can be configured to perform code detection, and the extensibility is reflected in that the detection rules can be increased or decreased according to actual conditions.

[0048] For example, for submissions of new feature development, you may need to perform a more comprehensive security review, including static code analysis, dynamic testing, penetration testing, etc., to ensure that the new feature does not introduce new security vulnerabilities; for submissions of bug fixes, you may need to focus on the code parts related to the fix and verify that the fix is ​​effective and does not introduce new problems; for submissions of code refactoring, you may need to check whether the refactored code maintains the original security and does not introduce new security risks.

[0049] By performing security checks on both the target code and the annotation files, the compliance of the code and the standardization of code submission can be ensured.

[0050] As an optional embodiment, detecting the validity of the annotation file includes: detecting whether the format of the annotation file complies with a preset format specification; and detecting whether the annotation information in the annotation file includes change information of the target code.

[0051] The annotation file includes a variety of information related to the target code, including but not limited to the code modification content, issue number, issue description, project name, and whether the code is an original modification or a modification based on the original modification (including modification points), etc. The validity of the annotation file needs to be guaranteed to ensure that the annotation file can accurately describe the target code.

[0052] Specifically, check whether the format of the annotation file follows the preset format specifications. You need to first clarify the format specifications of the annotation file, which usually includes the structure of the file, how the annotations are written, the tags or labels used, etc. Next, use automated tools to verify whether the annotation file conforms to these format specifications. Automated tools can parse the content of the annotation file and check whether its structure, syntax, and tags used conform to the predefined specifications.

[0053] If it is found that the annotation file does not comply with the format specification, the specific location that does not comply with the specification and modification suggestions can be provided to the user so that the user can make targeted modifications to the annotation file.

[0054] Specifically, it is detected whether the annotation information in the annotation file includes the change information of the target code. In the annotation file, it is necessary to find the annotation information related to the code change and check whether it contains the necessary change information. For example, it can be checked whether there is a paragraph describing the code change in the annotation file.

[0055] By checking the validity of the annotation file, the quality of the annotation file can be ensured, thereby ensuring the readability of the code.

[0056] As an optional embodiment, after obtaining the second test result, the method also includes: when the second test result indicates that the annotation file is not valid, stopping the test, and taking the failure of the target code and the annotation file to pass the security test as the first test result; or when the third test result indicates that there is a defect in the target code, stopping the test, and taking the failure of the target code and the annotation file to pass the security test as the first test result; or when the fourth test result indicates that the target code has failed the targeted test, taking the failure of the target code and the annotation file to pass the security test as the first test result.

[0057] The security test content provided in this application is a relatively comprehensive and necessary test item. Therefore, if any of the tests fails, the target code and annotation files will be judged as not passing the security test, and the code submission process will be stopped. Only when all the security test items pass the test can the automatic code submission operation be performed.

[0058] Optionally, if the annotation file is not valid, then it is also necessary to obtain the reason for the invalidity and send the reason to the user.

[0059] Optionally, if there is a defect in the target code, it is also necessary to obtain the specific location of the defect and send the defect content to the user.

[0060] Optionally, if the target code fails the targeted detection, it is also necessary to obtain the specific reason for failing the detection and send the reason to the user.

[0061] As an optional embodiment, verifying whether the local branch and remote branch to which the target code belongs meet the push conditions includes: verifying whether the remote branch exists in the remote repository; if the remote branch exists in the remote repository, verifying whether the local branch correctly tracks the remote branch; if the local branch correctly tracks the remote branch, determining that the local branch and the remote branch meet the push conditions.

[0062] When users send push instructions, they will carry the name of the remote branch, and the local branch can be automatically pulled when editing the code. After receiving the name of the remote branch, it will automatically verify whether the local branch and the remote branch to which the target code belongs meet the push conditions, mainly verifying the validity of the remote branch and the matching of the local branch and the remote branch.

[0063] You can first check whether the name of the remote branch is a valid name. If the name is valid, find out whether there is a branch in the remote warehouse that matches the remote branch name sent by the user. If so, it is determined that the remote branch exists in the remote warehouse.

[0064] If the remote branch exists in the remote repository, verify whether the local branch correctly tracks the remote branch: by viewing the tracking information of the local branch, you can know the remote branch it tracks. If the remote branch entered by the user belongs to the remote branch tracked by the local branch, it means that the local branch correctly tracks the remote branch.

[0065] Compared with the prior art, when pushing code, the user needs to manually enter the remote warehouse name, local branch name and remote branch name, but whether the local branch name matches the remote branch name needs to be guaranteed by the user. It often happens that the user pushes the modification to the wrong remote branch, resulting in the remote branch being contaminated. This application only needs to obtain the remote branch name entered by the user, and then automatically obtain the local branch name, and verify whether the local branch and remote branch to which the target code belongs meet the push conditions, including checking the existence of the remote branch and verifying the tracking relationship of the local branch. Through these two aspects of verification, the accuracy and security of code push can be ensured.

[0066] As an optional embodiment, if any of the following situations exists, it is determined that the local branch and the remote branch do not meet the push conditions: the remote branch does not exist in the remote repository; the local branch cannot correctly track the remote branch.

[0067] Only when it is confirmed that the remote branch exists in the remote repository (is valid) and the local branch correctly tracks the remote branch, can it be considered that the local branch and the remote branch meet the push conditions. If any of them is not met, it will be determined that the local branch and the remote branch do not meet the push conditions.

[0068] If any of the push conditions are not met, the code push operation will not be performed, and the reason for not meeting the push conditions will be sent to the user.

[0069] As an optional embodiment, before pushing the target code and annotation file to the remote branch, the method also includes: checking whether there is a code change identifier in the annotation file; if there is no code change identifier in the annotation file, obtaining the code change identifier; and adding the code change identifier to the annotation file.

[0070] A code change identifier (also called Change ID) is an identifier in the Gerrit code review tool that uniquely identifies a code change. In Gerrit, each code change pushed to the code review process automatically generates a code change identifier.

[0071] The code change identifier ensures that each code change has a unique identity, which facilitates the tracking and management of code changes in Gerrit. If the code change identifier is not included when pushing the code, Gerrit will report an error and prompt that the code change identifier is missing, which will cause the push to fail. Therefore, before pushing the code, you need to do a check to check whether the code change identifier already exists in the annotation file. If so, no other operations are required. If not, the code change identifier needs to be added to the annotation file.

[0072] When the code is pushed, the target code and annotation files will be pushed to the remote branch together, so that users of the remote branch can view the code and related descriptions.

[0073] By supplementing and checking the code change identifier before pushing, the standardization of code push can be further improved, avoiding push failures caused by missing code change identifiers.

[0074] The present application adopts a code push method, including: when receiving a code submission instruction, obtaining the target code to be submitted and the annotation file associated with the target code, wherein the annotation file includes the basic content of the target code and the modified content of the target code; performing a security check on the target code and the annotation file to obtain a first test result; when the first test result indicates that the target code and the annotation file pass the security check, submitting the target code to the local warehouse; when receiving a push instruction for the target code, determining the remote branch from the push instruction, and verifying whether the local branch and the remote branch to which the target code belongs meet the push conditions; if the remote branch and the local branch meet the push conditions, pushing the target code and the annotation file to the remote branch. By automatically performing a security check when the code is submitted, and verifying and confirming that the local branch and the remote branch meet the push conditions before pushing the code, the standardization of the entire code push process is guaranteed, and the problem of code push accidents caused by non-standard push content is solved.

[0075] According to another aspect of the embodiment of the present application, the present application provides a code push device, such as Figure 3 As shown, including:

[0076] The acquisition module 301 is used to acquire the target code to be submitted and the annotation file associated with the target code when receiving the code submission instruction, wherein the annotation file includes the basic content of the target code and the modified content of the target code;

[0077] A detection module 302 is used to perform security detection on the target code and the annotation file to obtain a first detection result;

[0078] A submission module 303, configured to submit the target code to a local repository when the first detection result indicates that the target code and the annotation file have passed the security detection;

[0079] The verification module 304 is used to determine the remote branch from the push instruction when receiving the push instruction for the target code, and verify whether the local branch and the remote branch to which the target code belongs meet the push condition;

[0080] The push module 305 is used to push the target code and the annotation file to the remote branch if the remote branch and the local branch meet the push conditions.

[0081] It should be noted that the acquisition module 301 in this embodiment can be used to execute step 101 in the embodiment of the present application, the detection module 302 in this embodiment can be used to execute step 102 in the embodiment of the present application, the submission module 303 in this embodiment can be used to execute step 103 in the embodiment of the present application, the verification module 304 in this embodiment can be used to execute step 104 in the embodiment of the present application, and the push module 305 in this embodiment can be used to execute step 105 in the embodiment of the present application.

[0082] Optionally, the detection module 302 includes:

[0083] A first detection submodule is used to detect the validity of the annotation file and obtain a second detection result;

[0084] A second detection submodule is used to perform static detection on the target code to obtain a third detection result when the second detection result indicates that the annotation file is valid;

[0085] A third detection submodule is used to perform targeted detection on the target code according to the submission type of the target code to obtain a fourth detection result when the third detection result indicates that the target code has no defects;

[0086] The first processing submodule is used to take the target code and the annotation file passing the security test as the first test result when the fourth test result indicates that the target code has passed the targeted test.

[0087] Optionally, the first detection submodule is further used to detect whether the format of the annotation file complies with a preset format specification; and detect whether the annotation information in the annotation file includes change information of the target code.

[0088] Optionally, the detection module 302 also includes a second processing submodule, which is used to stop the detection after obtaining the second detection result, when the second detection result indicates that the annotation file is not valid, and take the failure of the target code and the annotation file to pass the security test as the first detection result; or when the third detection result indicates that there is a defect in the target code, stop the detection, and take the failure of the target code and the annotation file to pass the security test as the first detection result; or when the fourth detection result indicates that the target code fails the targeted test, take the failure of the target code and the annotation file to pass the security test as the first detection result.

[0089] Optionally, the verification module 304 is also used to verify whether the remote branch exists in the remote repository; if the remote branch exists in the remote repository, then verify whether the local branch correctly tracks the remote branch; if the local branch correctly tracks the remote branch, then determine that the local branch and the remote branch meet the push conditions.

[0090] Optionally, the verification module 304 is further used to determine that the local branch and the remote branch do not meet the push condition if any of the following situations exists: the remote branch does not exist in the remote repository; the local branch cannot correctly track the remote branch.

[0091] Optionally, the device also includes an adding module, which is used to check whether there is a code change identifier in the annotation file before pushing the target code and annotation file to the remote branch; if the code change identifier does not exist in the annotation file, obtain the code change identifier; and add the code change identifier to the annotation file.

[0092] It should be noted here that the examples and application scenarios implemented by the above modules and corresponding steps are the same, but are not limited to the contents disclosed in the above embodiments.

[0093] According to another aspect of the embodiments of the present application, the present application provides an electronic device, such as Figure 4 As shown, it includes a memory 401, a processor 403, a communication interface 405 and a communication bus 407. The memory 401 stores a computer program that can be run on the processor 403. The memory 401 and the processor 403 communicate through the communication interface 405 and the communication bus 407. When the processor 403 executes the computer program, the steps of the above method are implemented.

[0094] The memory and processor in the above electronic device communicate via a communication bus and a communication interface. The communication bus may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The communication bus may be divided into an address bus, a data bus, a control bus, etc.

[0095] The memory may include a random access memory (RAM) or a non-volatile memory, such as at least one disk memory. Optionally, the memory may also be at least one storage device located away from the aforementioned processor.

[0096] The above-mentioned processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0097] According to another aspect of the embodiments of the present application, a computer-readable medium having a non-volatile program code executable by a processor is provided.

[0098] Optionally, the specific examples in this embodiment may refer to the examples described in the above embodiments, and this embodiment will not be described in detail here.

[0099] When the embodiments of the present application are specifically implemented, reference may be made to the above-mentioned embodiments, which have corresponding technical effects.

[0100] It is understood that the embodiments described herein may be implemented in hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit may be implemented in one or more application specific integrated circuits (ASIC), digital signal processors (DSP), digital signal processing devices (DSPD), programmable logic devices (PLD), field programmable gate arrays (FPGA), general purpose processors, controllers, microcontrollers, microprocessors, other electronic units for performing the functions described in the present application, or a combination thereof.

[0101] For software implementation, the technology described herein can be implemented by a unit that performs the functions described herein. The software code can be stored in a memory and executed by a processor. The memory can be implemented in the processor or outside the processor.

[0102] Those of ordinary skill 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 this application.

[0103] 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.

[0104] In the embodiments provided in the present application, 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 modules is only a logical function division. There may be other division methods in actual implementation, such as multiple modules 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 an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0105] 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.

[0106] In addition, each functional unit in each embodiment of the present application 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.

[0107] If the function is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of the embodiment of the present application is essentially 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, which is stored in a storage medium, including several instructions to make a computer device (which can be a personal computer, a server, or a network device, etc.) perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as a USB flash drive, a mobile hard disk, a ROM, a RAM, a magnetic disk or an optical disk. It should be noted that, in this article, relational terms such as "first" and "second" are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply that there is any such actual relationship or order between these entities or operations. Moreover, the term "include", "include" or any other variant thereof is intended to cover non-exclusive inclusion, so that the process, method, article or device including a series of elements includes not only those elements, but also includes other elements that are not explicitly listed, or also includes elements inherent to such a process, method, article or device. Without more constraints, an element defined by the phrase "comprising a..." does not exclude the existence of other identical elements in the process, method, article or apparatus comprising the element.

[0108] The above description is only a specific implementation of the present application, so that those skilled in the art can understand or implement the present application. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein can be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to the embodiments shown herein, but will conform to the widest range consistent with the principles and novel features applied for herein.

Claims

1. A code push method, characterized in that: include: Upon receiving the code submission instruction, obtaining the target code to be submitted and an annotation file associated with the target code, wherein the annotation file includes the basic content of the target code and the modified content of the target code; Performing security detection on the target code and the annotation file to obtain a first detection result; When the first test result indicates that the target code and the annotation file pass the security test, submitting the target code to a local repository; When receiving a push instruction for the target code, determining a remote branch from the push instruction, and verifying whether the local branch to which the target code belongs and the remote branch meet a push condition; If the remote branch and the local branch meet the push condition, the target code and the annotation file are pushed to the remote branch.

2. The method according to claim 1, characterized in that The performing of security detection on the target code and the annotation file to obtain a first detection result includes: Detecting the validity of the annotation file to obtain a second detection result; When the second detection result indicates that the annotation file has the validity, statically detecting the target code to obtain a third detection result; When the third test result indicates that the target code has no defects, performing targeted testing on the target code according to the submission type of the target code to obtain a fourth test result; When the fourth detection result indicates that the target code has passed the targeted detection, the target code and the annotation file passing the security detection are taken as the first detection result.

3. The method according to claim 2, characterized in that The detecting the validity of the annotation file comprises: Detecting whether the format of the annotation file complies with a preset format specification; Detect whether the annotation information in the annotation file includes the change information of the target code.

4. The method according to claim 2, characterized in that: After obtaining the second detection result, the method further includes: When the second detection result indicates that the annotation file does not have the validity, stop the detection, and take the failure of the target code and the annotation file to pass the security detection as the first detection result; or When the third detection result indicates that the target code has a defect, stop the detection, and take the failure of the target code and the annotation file to pass the security detection as the first detection result; or When the fourth detection result indicates that the target code fails the targeted detection, the failure of the target code and the annotation file to pass the security detection is taken as the first detection result.

5. The method according to claim 1, characterized in that The verifying whether the local branch to which the target code belongs and the remote branch meet the push condition includes: Verify whether the remote branch exists in the remote repository; If the remote branch exists in the remote repository, verify whether the local branch correctly tracks the remote branch; If the local branch correctly tracks the remote branch, it is determined that the local branch and the remote branch satisfy the push condition.

6. The method according to claim 5, characterized in that If any of the following situations exists, it is determined that the local branch and the remote branch do not meet the push condition: The remote branch does not exist in the remote repository; The local branch cannot correctly track the remote branch.

7. The method according to claim 1, characterized in that Before pushing the target code and the annotation file to the remote branch, the method further includes: Checking whether a code change identifier exists in the annotation file; If the code change identifier does not exist in the annotation file, obtaining the code change identifier; The code change identifier is added to the annotation file.

8. A code push device, characterized in that: include: An acquisition module, configured to acquire the target code to be submitted and an annotation file associated with the target code upon receiving a code submission instruction, wherein the annotation file includes the basic content of the target code and the modified content of the target code; A detection module, used for performing a security detection on the target code and the annotation file to obtain a first detection result; A submission module, configured to submit the target code to a local repository when the first detection result indicates that the target code and the annotation file pass the security detection; A verification module, configured to, upon receiving a push instruction for the target code, determine a remote branch from the push instruction, and verify whether a local branch to which the target code belongs and the remote branch satisfy a push condition; A push module is used to push the target code and the annotation file to the remote branch if the remote branch and the local branch meet the push condition.

9. An electronic device, comprising a memory, a processor, a communication interface and a communication bus, wherein the memory stores a computer program that can be run on the processor, and the memory and the processor communicate through the communication bus and the communication interface, characterized in that: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 7 are implemented.

10. A computer readable medium having a non-volatile program code executable by a processor, characterized in that: The program code enables the processor to execute the method according to any one of claims 1 to 7.

Images