CN118051256A - Code branch management method, device, equipment, storage medium and product - Google Patents

Abstract

The application provides a code branch management method, a device, equipment, a storage medium and a product. Relates to the technical field of computers. The method comprises the following steps: obtaining a code snapshot of the software to be developed under the current version in a production branch; creating a first development main branch based on the code snapshot according to a preset development requirement, and creating a second development main branch according to the development requirement of the software to be developed before the first development main branch is online under the current version; if the development of the second development main branch is completed, merging the second development main branch into the production branch, and merging the second development main branch into the first development main branch; and if the development of the first development main branch is completed, taking the first development main branch as a new version of the software to be developed to be online to the production branch. The scheme of the application considers different development demands and creates different development branches, and the development branches can be combined with the production branches, thereby improving the efficiency of code management in software development.

Description

Code branch management method, device, equipment, storage medium and product

Technical Field

The present application relates to the field of computer technologies, and in particular, to a method, an apparatus, a device, a storage medium, and a product for managing code branches.

Background

Code branch management is mainly used to manage code of different versions and functions in software development. By creating different branches, a development team can develop multiple functions simultaneously without affecting the stability of the main code library.

The current mainstream code branch management scheme can develop a plurality of functions by establishing a plurality of characteristic branches, the characteristic branches are merged into a development branch after the development of the characteristic branches is completed, after the development branch is developed to a certain extent, the development branches test the development content in the development branch and update documents, and the development branches are merged into a main branch through a distribution branch to complete the update of a new version. However, in the scheme, only one development branch usually exists, so that parallel development of multiple versions cannot be realized in the development process, and then the development of multiple functions is integrated on one development branch, so that the problems of difficult integration, delay in delivery and the like are caused. Therefore, a problem that needs to be solved at present is how to improve the efficiency of code management in software development.

Disclosure of Invention

The application provides a code branch management method, a device, equipment, a storage medium and a product, which are used for improving the efficiency of code management in software development.

In one aspect, the present application provides a code branch management method, including: acquiring a code snapshot of the software to be developed under the current version in a production branch; the production branch stores all codes of the software to be developed, and the current version is a version corresponding to the current production environment; creating a first development main branch based on the code snapshot according to a predetermined development requirement; detecting whether development requirements of software to be developed under a current version exist before a first development main branch is on line; if the development requirement exists, creating a second development main branch based on the code snapshot according to the development requirement of the software to be developed under the current version; if the second development main branch is detected to be developed, merging the second development main branch into the production branch; merging the second development main branch to the first development main branch after merging the second development main branch to the production branch; and if the development completion of the first development main branch is detected, taking the first development main branch as a new version of the software to be developed to be online to the production branch.

In one possible implementation, the first development main branch and the second development main branch are deployed at a central code repository, the method further comprising: creating a central personal branch corresponding to the first development main branch and a central personal branch corresponding to the second development main branch based on the central code repository; based on the local code warehouse, creating a local personal branch corresponding to the first development main branch and a local personal branch corresponding to the second development main branch; after receiving the code update of the local personal branch, synchronizing the local personal branch with the central personal branch; detecting whether the code updating of the local personal branch is finished; if so, merging the synchronized central personal branch into the corresponding first development main branch or the corresponding second development main branch in the central code warehouse to finish the development of the first development main branch or the second development main branch.

In one possible implementation manner, after ending the development of the first development main branch or the second development main branch, the method further includes: constructing corresponding initial test environments and pre-production test environments based on the first development main branch, and constructing corresponding initial test environments and pre-production test environments based on the second development main branch; wherein at least one of test hardware performance, test data size, and test security of the pre-production environment is higher than the initial test environment; and if the test result of the first development main branch or the second development main branch in the corresponding initial test environment and pre-production test environment is detected to be passing, locking the first development main branch or the second development main branch.

In one possible implementation manner, the method further includes, before the first development main branch created based on the code snapshot is uploaded to the production branch as the new version of the software to be developed, the steps of: detecting whether at least one other first development main branch exists before the first development main branch is on line; if so, merging the first development main branch with the last line time closest to the line time of the first development main branch in at least one other first development main branch into the first development main branch.

In one possible implementation, after merging the second development main branch into the production branch, further comprising: performing a first identifier marking on the production branch based on the second development main branch; the first identifier characterizes version information of a current version of the software to be developed.

In one possible implementation, after the first development main branch is brought up to the production branch as the new version of the software to be developed, the method further includes: performing a second identifier marking on the production branch based on the first development main branch; the second identifier characterizes version information of a new version of the software to be developed.

In another aspect, the present application provides a code branch management apparatus, comprising: the acquisition module is used for acquiring a code snapshot of the software to be developed under the current version in the production branch; wherein the production branch stores all codes of the software to be developed; the creation module is used for creating a first development main branch based on the code snapshot according to the preset development requirement; the detection module is used for detecting whether development requirements of the software to be developed under the current version exist before the first development main branch is on line; if the development requirement exists, creating a second development main branch based on the code snapshot according to the development requirement of the software to be developed under the current version; if the second development main branch is detected to be developed, merging the second development main branch into the production branch; the online module is used for merging the second development main branch to the first development main branch after merging the second development main branch to the production branch; and if the development completion of the first development main branch is detected, taking the first development main branch as a new version of the software to be developed to be online to the production branch.

In another aspect, the present application provides an electronic device, including: a processor, a memory communicatively coupled to the processor; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory to implement the method as described above.

In another aspect, the application provides a computer readable storage medium having stored therein computer executable instructions which when executed by a processor are adapted to carry out a method as described above.

In another aspect, the application provides a computer program product comprising a computer program which, when executed by a processor, implements a method as above.

The code branch management method, the device, the equipment, the storage medium and the product provided by the application acquire the code snapshot of the software to be developed under the current version in the production branch; creating a first development main branch based on the code snapshot according to a preset development requirement, and creating a second development main branch according to the development requirement of the software to be developed before the first development main branch is online under the current version; if the development of the second development main branch is completed, merging the second development main branch into the production branch, and merging the second development main branch into the first development main branch after merging the second development main branch into the production branch; and if the development of the first development main branch is completed, taking the first development main branch as a new version of the software to be developed to be online to the production branch. The scheme of the application considers different development demands and creates different development branches, and the development branches can be combined with the production branches, thereby improving the efficiency of code management in software development.

Drawings

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

Fig. 1 is a schematic flow chart illustrating a code branching management method according to the first embodiment;

fig. 2 is a flow chart schematically showing a further code branching management method according to the first embodiment;

fig. 3 is a flow chart schematically showing another code branch management method according to the first embodiment;

fig. 4 is a flow chart schematically showing another code branch management method according to the first embodiment;

fig. 5 is a flow chart schematically showing another code branch management method according to the first embodiment;

fig. 6 is a flowchart schematically showing another code branch management method according to the first embodiment;

fig. 7 is a schematic diagram schematically showing the structure of a code branching management apparatus according to the second embodiment;

fig. 8 schematically shows a structure of an electronic device according to a third embodiment.

Specific embodiments of the present application have been shown by way of the above drawings and will be described in more detail below. The drawings and the written description are not intended to limit the scope of the inventive concepts in any way, but rather to illustrate the inventive concepts to those skilled in the art by reference to the specific embodiments.

Detailed Description

Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numbers in different drawings refer to the same or similar elements, unless otherwise indicated. The implementations described in the following exemplary examples do not represent all implementations consistent with the application. Rather, they are merely examples of apparatus and methods consistent with aspects of the application as detailed in the accompanying claims.

The technical scheme of the application is used for acquiring, transmitting, storing, using and processing the data, and the like, which meet the relevant regulations of national laws and regulations. It should be noted that, in the embodiments of the present application, some existing solutions in the industry such as software, components, models, etc. may be mentioned, and they should be regarded as exemplary, only for illustrating the feasibility of implementing the technical solution of the present application, but it does not mean that the applicant has or must not use the solution.

It should be noted that the brief description of the terminology in the present application is for the purpose of facilitating understanding of the embodiments described below only and is not intended to limit the embodiments of the present application. Unless otherwise indicated, these terms should be construed in their ordinary and customary meaning. The terms "comprising" and "having" and any variations thereof in the present description and claims and in the above-described figures are intended to cover a non-exclusive inclusion, such that a product or apparatus that comprises a list of elements is not necessarily limited to those elements expressly listed but may include other elements not expressly listed or inherent to such product or apparatus. The term "module" as used in this disclosure refers to any known or later developed hardware, software, firmware, artificial intelligence, fuzzy logic, or combination of hardware and/or software code that is capable of performing the function associated with that element.

Software configuration management refers to a process of effectively managing and controlling various configuration items (including source code, documents, library files, configuration files, etc.) in a software development process. Software configuration management aims to ensure traceability, controllability and reproducibility in the software development process so as to improve the software development quality and efficiency. Wherein software configuration management is typically performed on the software under development by means of code branch management.

The current mainstream code branch management scheme can develop a plurality of functions by establishing a plurality of characteristic branches, and the characteristic branches are merged into development branches after the development of the characteristic branches is completed. And after the development branches are developed to a certain degree, testing and document updating are carried out on the development contents in the development branches by the release branches, and the development contents are merged into the main branches through the distribution branches to complete updating of the new version. However, although the scheme can realize parallel development of a plurality of functions through characteristic branching, the functions in a single characteristic cannot be independently on line. The production branch often needs to wait until the code is released last, and continuous integration of the code cannot be realized, so that more subsequent merging conflicts are caused. Especially, when a plurality of teams work, the joint debugging of different teams is long in integration time, the quality cannot be guaranteed, and the like. Second, a single development branch results in the inability to achieve parallel development of multiple software versions during the development process.

The technical content provided by the application aims to solve the technical problems of the related technology. In the code branch management method, the device, the equipment, the storage medium and the product, a code snapshot of the software to be developed under the current version is obtained in the production branch; creating a first development main branch based on the code snapshot according to a preset development requirement, and creating a second development main branch according to the development requirement of the software to be developed before the first development main branch is online under the current version; if the development of the second development main branch is completed, merging the second development main branch into the production branch, and merging the second development main branch into the first development main branch after merging the second development main branch into the production branch; and if the development of the first development main branch is completed, taking the first development main branch as a new version of the software to be developed to be online to the production branch. The scheme of the application considers different development demands and creates different development branches, and the development branches can be combined with the production branches, thereby improving the efficiency of code management in software development.

The technical scheme of the present application and the technical scheme of the present application will be described in detail with specific examples. The following embodiments may be combined with each other, and the same or similar concepts or processes may not be described in detail in some embodiments. In describing the present application, the terms should be construed broadly in the art unless explicitly stated and limited otherwise. Embodiments of the present application will be described below with reference to the accompanying drawings.

Example 1

A flow chart of a code branch management method is shown in fig. 1, and an execution body of this example may be a code branch management apparatus, as shown in fig. 1, where the method includes:

Step 101, obtaining a code snapshot of software to be developed under a current version in a production branch; the production branch stores all codes of the software to be developed, and the current version is a version corresponding to the current production environment;

102, creating a first development main branch based on a code snapshot according to a preset development requirement;

Step 103, detecting whether development requirements of the software to be developed under the current version exist before the first development main branch is on line; if the development requirement exists, creating a second development main branch based on the code snapshot according to the development requirement of the software to be developed under the current version; if the second development main branch is detected to be developed, merging the second development main branch into the production branch;

step 104, merging the second development main branch to the first development main branch after merging the second development main branch to the production branch; and if the development completion of the first development main branch is detected, taking the first development main branch as a new version of the software to be developed to be online to the production branch.

In practical application, the execution main body of the method is a code branch management device, and various implementation modes are available, for example, the method can be realized by a computer program, such as application software and the like; or may be embodied as a medium storing a related computer program, e.g., a usb disk, a cloud disk, etc.; or may also be implemented by physical means, e.g. a chip or the like, incorporating or installing the relevant computer program.

Specifically, the production branch, also known in the related art as the Main branch, master branch, or Main branch, stores all historical versions of stable code of the software to be developed that can be deployed directly in the production environment, as well as new versions of code that have passed testing and are ready to be released. The main branch only has one and does not accept direct commit of code, accepting only merging of other branches. In this example, by taking a snapshot of the code of the software under development in the current version in the production branch, a copy of the software under development in the current version may be obtained and used for subsequent software version development. The code snapshot may include, among other things, files, directory structures, or code content of the software to be developed. In practical application, code snapshot is obtained regularly and historical code snapshot is kept, and code security and more stable code snapshot are selected for subsequent software version development; or the method can be executed after the development requirement is received to acquire the code snapshot of the software to be developed under the current version.

A first development main branch is created based on the code snapshot according to predetermined development requirements. In practical application, the predetermined development requirement is a development requirement determined in advance of one month or one quarter in the software development plan, and the development period for the predetermined development requirement is relatively long and may be several months to one year. The content of the predetermined development requirements may be the repair of known errors, the improvement of new or existing functions, the optimization of software performance, etc. Specifically, a first development main branch may be created by a version control tool based on a code snapshot. The procedure for branch creation is disclosed for the related art and will not be further described here. In addition to considering the predetermined development requirement, it is also necessary to detect whether there is a development requirement of the software to be developed under the current version before the first development main branch is on line; if so, creating a second development main branch based on the code snapshot according to the development requirement of the software to be developed under the current version. The development requirement of the software to be developed under the current version is characterized as an urgent development requirement under the current version, and the development period aiming at the requirement is relatively short, such as one week or several days, and is unequal. The content of the corresponding development requirement can be the urgent adjustment or the increased requirement with smaller scale, and optionally, the content of the development requirement can also be the urgent problem or the bug fix with sudden.

After the first development main branch and the second development main branch are created, code development is performed on the first development main branch and the second development main branch by a developer. If the second development main branch is detected to be developed, merging the second development main branch into the production branch. Specifically, after the second development main branch is completed, code inspection and function test can be performed on the codes in the second development main branch, and after the second development main branch is combined to the production branch, test is performed to verify the functions and stability of the combined codes. In practical application, suitable merging strategies such as merging submission, re-base, fast forward merging and the like can be selected according to requirements. Similarly, after the second development main branch is merged into the production branch, the second development main branch is merged into the first development main branch. It should be noted that, the time for merging the second main development branch into the first main development branch is not limited, for example, the second main development branch may be merged during the development of the first main development branch, or may be merged after the development of the first main development branch is completed. The present example may bring in the development content in the second development main branch under the current version by merging the second development main branch into the production branch; the second development main branch is combined to the first development main branch on the basis, so that frequent code interaction can be realized and the integration degree of codes can be improved. And after the development of the first development main branch is completed, the first development main branch is used as a new version of the software to be developed to be online to the production branch. Optionally, by detecting the code stability of the first development main branch, the strategies such as gray release, backup, rollback and the like can be performed to improve the success rate of online of the new version.

According to the code branch management method provided by the example, the code snapshot of the software to be developed under the current version is obtained in the production branch; creating a first development main branch based on the code snapshot according to a preset development requirement, and creating a second development main branch according to the development requirement of the software to be developed before the first development main branch is online under the current version; if the development of the second development main branch is completed, merging the second development main branch into the production branch, and merging the second development main branch into the first development main branch after merging the second development main branch into the production branch; and if the development of the first development main branch is completed, taking the first development main branch as a new version of the software to be developed to be online to the production branch. The scheme of the application considers different development demands and creates different development branches, and the development branches can be combined with the production branches, thereby improving the efficiency of code management in software development.

In practical application, considering the software development efficiency, the development branches can be developed by a plurality of parallel development sub-branches. As yet another example, a flow diagram of a code branch management method is schematically shown in fig. 2. On the basis of any example, the method further comprises:

Step 201, based on a central code warehouse, creating a central personal branch corresponding to a first development main branch and a central personal branch corresponding to a second development main branch; based on the local code warehouse, creating a local personal branch corresponding to the first development main branch and a local personal branch corresponding to the second development main branch;

step 202, after receiving the code update of the local personal branch, synchronizing the local personal branch with the central personal branch;

step 203, detecting whether the code updating of the local personal branch is finished; if so, merging the synchronized central personal branch into the corresponding first development main branch or the corresponding second development main branch in the central code warehouse to finish the development of the first development main branch or the second development main branch.

In this example, the number of local code warehouses may be one or more, the local code warehouses clonally storing either the first development main branch or the second development main branch of the central code warehouse. In practice, when a developer locally clones a central code repository, the location of the remote repository may be specified using the uniform resource locator of the central code repository. This uniform resource locator may be an address formulated according to the hypertext transfer protocol, secure shell protocol, etc. In this example, the reliability and performance of the code repository may be improved by providing clustered code repositories. Corresponding personal branches are created in the local code warehouse and the central code warehouse, and particularly, a plurality of personal branches are arranged to develop the development branches in a distributed mode. In practice, development branches may be created by individuals or teams, and one development branch may correspond to one or more individual branches based on the scale of the development function. After receiving the code update of the local personal branch, the local personal branch and the central personal branch are synchronized. If the code updating of the local personal branch is detected to be finished, merging the synchronized central personal branch into a corresponding first development main branch or a corresponding second development main branch in a central code warehouse to finish the development of the first development main branch or the second development main branch. Optionally, when the central personal branch is merged to the corresponding development branch, an audit mechanism may be set; for example, after passing an audit by a developing colleague with audit qualification, the central individual branch can be merged into the corresponding development branch. The scheme of the example can improve the security of storage and modification by setting a central code warehouse and a local code warehouse, and can improve the efficiency of code development by setting parallel development of personal branches.

As yet another example, a flow diagram of a code branch management method is schematically shown in fig. 3. On the basis of any example, after step 203, the method further includes:

Step 301, constructing a corresponding initial test environment and a pre-production test environment based on the first development main branch, and constructing a corresponding initial test environment and a corresponding pre-production test environment based on the second development main branch; wherein at least one of test hardware performance, test data size, and test security of the pre-production environment is higher than the initial test environment;

step 302, if it is detected that the test result of the first development main branch or the second development main branch in the corresponding initial test environment and pre-production test environment is passed, locking the first development main branch or the second development main branch.

The corresponding test environment may be constructed based on the first development main branch or the second development main branch, considering that the test environment corresponding to each development branch is different. Alternatively, the same software version may correspond to the same test environment. The testing environment is mainly used for testing functions and performances, such as system integration testing by a development team, so that normal interaction among all modules is ensured, and the system functions meet the requirements in the requirement specification and the performances meet the expectations. The test accuracy can be improved by setting test environments with different grades; wherein, the test hardware can comprise a test server, a computer and a workstation; the test data scale may include small-scale data for functional or unit testing, or large-scale data for stress testing; test security may include protective measures to ensure that test data and test systems are not unauthorized access, modification, or corruption. And after detecting that the test result of the first development main branch or the second development main branch in the corresponding initial test environment and pre-production test environment is passing, locking the first development main branch or the second development main branch. After the test of the first development main branch or the second development main branch passes, the representatives can be directly combined with other branches or deployed into a production environment, and the subsequent code modification can be forbidden in a locking mode, so that the safety of the development branches is improved.

To the existence of multiple versions in parallel development in the actual software development process, inheritance of multiple version codes needs to be considered. On the basis of any one of the examples, as yet another example, the code branch management method further includes:

Detecting whether at least one other first development main branch exists before the first development main branch is on line; if so, merging the first development main branch with the last line time closest to the line time of the first development main branch in at least one other first development main branch into the first development main branch.

In practical application, according to a predetermined development requirement, if two or more first development main branches exist at the same time to develop based on the same code snapshot, the development content of multiple development versions can be reserved by inheriting the first development main branch from another first development main branch before the first development main branch. In practical application, if another first development main branch is merged into the first development main branch, code conflict exists, and code review is performed by reserving codes in the first development main branch of a new version or notifying relevant developers to improve the consistency of the codes. The solution of this example can implement the inheritance of the code of the new version to the old version by merging the first development main branches of different versions.

As yet another example, a flow diagram of a code branch management method is schematically shown in fig. 4. On the basis of either example, after merging the second development main branch into the production branch in step 103, further comprises:

Step 401, performing a first identifier marking on the production branch based on the second development main branch; the first identifier characterizes version information of a current version of the software to be developed.

In particular, the first identifier may be configured to include different fields for identifying a secondary version of the software to be developed under the current version. In practical applications, the different minor fields can be distinguished by setting suffixes such as revisions, antecedents, extensions and the like based on different requirements. In the scheme of the example, the first identifier is used for marking different secondary versions of the available to-be-developed software, so that multiple secondary versions under the same version can be effectively managed.

As yet another example, a flow diagram of a code branch management method is schematically shown in fig. 5. On the basis of any example, after the first development main branch is taken as the new version of the software to be developed to the production branch in step 104, the method further includes:

Step 501, performing a second identifier marking on the production branch based on the first development main branch; the second identifier characterizes version information of a new version of the software to be developed.

In particular, a number field marked as increment or decrement by the second identifier, a date field when the new version is online, or a Tag (Tag) combined with any character or number may be provided for identifying the new version of the software to be developed. The solution of this example can be used to identify new versions of the software to be developed by making a second identifier tag, to assist the development team in subsequent problem tracking and backtracking, and to facilitate better version management.

A flow diagram of a code branch management method is schematically shown in fig. 6. As shown in fig. 6, a code snapshot of software to be developed under a current version (V1.0) is acquired in a production branch, and a first development main branch a and a first development main branch B are created based on the code snapshot according to a predetermined development requirement; and creating a second main development branch based on the code snapshot under development requirements of the software to be developed under the current version (V1.0). After the first development main branch A, the first development main branch B and the second development main branch are established, respectively establishing corresponding personal branches; code development is performed by the individual branch corresponding to each development branch, and is merged into the corresponding development branch (not shown in fig. 5) after the code development is completed; as the development of the second development main branch is completed as the development of the code proceeds, the second development main branch is merged into the production branch and then marked with V1.0.1 as an identifier, and the second development main branch is merged into the first development main branch a as shown in fig. 5; when the development of the first development main branch A is completed, the first development main branch A is used as a new version of software to be developed to be online to a production branch, and the identifier is marked as V2.0; correspondingly, when the development of the first development main branch B is completed, the first development main branch B is taken as a new version of the software to be developed to be online to the production branch, and the identifier is marked as V3.0. It should be noted that V2.0 already contains the development content of the second main development branch V1.0.1, so the second main development branch does not need to be merged into the first main development branch B; in addition, if there is a development requirement under the current version (V2.0) after V2.0 is online, the development requirement also needs to be merged into the first development main branch B.

According to the code branch management method provided by the embodiment, the code snapshot of the software to be developed under the current version is obtained in the production branch; creating a first development main branch based on the code snapshot according to a preset development requirement, and creating a second development main branch according to the development requirement of the software to be developed before the first development main branch is online under the current version; if the development of the second development main branch is completed, merging the second development main branch into the production branch, and merging the second development main branch into the first development main branch after merging the second development main branch into the production branch; and if the development of the first development main branch is completed, taking the first development main branch as a new version of the software to be developed to be online to the production branch. The scheme of the application considers different development demands and creates different development branches, and the development branches can be combined with the production branches, thereby improving the efficiency of code management in software development.

Example two

Fig. 7 is a schematic structural diagram of a code branch management apparatus according to a second embodiment of the present application, where, as shown in fig. 7, the apparatus includes:

An obtaining module 51, configured to obtain a code snapshot of software to be developed under a current version in a production branch; the production branch stores all codes of the software to be developed, and the current version is a version corresponding to the current production environment;

A creation module 52 for creating a first development main branch based on the code snapshot according to a predetermined development requirement;

The detection module 53 is configured to detect whether a development requirement of the software to be developed under the current version exists before the first development main branch is on line; if the development requirement exists, creating a second development main branch based on the code snapshot according to the development requirement of the software to be developed under the current version; if the second development main branch is detected to be developed, merging the second development main branch into the production branch;

An on-line module 54 for merging the second development main branch to the first development main branch after merging the second development main branch to the production branch; and if the development completion of the first development main branch is detected, taking the first development main branch as a new version of the software to be developed to be online to the production branch.

In practical applications, the code branching management apparatus may be implemented in various ways, for example, by a computer program, for example, application software, etc.; or may be embodied as a medium storing a related computer program, e.g., a usb disk, a cloud disk, etc.; or may also be implemented by physical means, e.g. a chip or the like, incorporating or installing the relevant computer program.

Specifically, the production branch, also known in the related art as the Main branch, master branch, or Main branch, stores all historical versions of stable code of the software to be developed that can be deployed directly in the production environment, as well as new versions of code that have passed testing and are ready to be released. The main branch only has one and does not accept direct commit of code, accepting only merging of other branches. In this example, by taking a snapshot of the code of the software under development in the current version in the production branch, a copy of the software under development in the current version may be obtained and used for subsequent software version development. The code snapshot may include, among other things, files, directory structures, or code content of the software to be developed. In practical application, code snapshot is obtained regularly and historical code snapshot is kept, and code security and more stable code snapshot are selected for subsequent software version development; or the method can be executed after the development requirement is received to acquire the code snapshot of the software to be developed under the current version.

A first development main branch is created based on the code snapshot according to predetermined development requirements. In practical application, the predetermined development requirement is a development requirement determined in advance of one month or one quarter in the software development plan, and the development period for the predetermined development requirement is relatively long and may be several months to one year. The content of the predetermined development requirements may be the repair of known errors, the improvement of new or existing functions, the optimization of software performance, etc. Specifically, a first development main branch may be created by a version control tool based on a code snapshot. The procedure for branch creation is disclosed for the related art and will not be further described here. In addition to considering the predetermined development requirement, it is also necessary to detect whether there is a development requirement of the software to be developed under the current version before the first development main branch is on line; if so, creating a second development main branch based on the code snapshot according to the development requirement of the software to be developed under the current version. The development requirement of the software to be developed under the current version is characterized as an urgent development requirement under the current version, and the development period aiming at the requirement is relatively short, such as one week or several days, and is unequal. The content of the corresponding development requirement can be the urgent adjustment or the increased requirement with smaller scale, and optionally, the content of the development requirement can also be the urgent problem or the bug fix with sudden.

After the first development main branch and the second development main branch are created, code development is performed on the first development main branch and the second development main branch by a developer. If the second development main branch is detected to be developed, merging the second development main branch into the production branch. Specifically, after the second development main branch is completed, code inspection and function test can be performed on the codes in the second development main branch, and after the second development main branch is combined to the production branch, test is performed to verify the functions and stability of the combined codes. In practical application, suitable merging strategies such as merging submission, re-base, fast forward merging and the like can be selected according to requirements. Similarly, after the second development main branch is merged into the production branch, the second development main branch is merged into the first development main branch. It should be noted that, the time for merging the second main development branch into the first main development branch is not limited, for example, the second main development branch may be merged during the development of the first main development branch, or may be merged after the development of the first main development branch is completed. The present example may bring in the development content in the second development main branch under the current version by merging the second development main branch into the production branch; the second development main branch is combined to the first development main branch on the basis, so that frequent code interaction can be realized and the integration degree of codes can be improved. And after the development of the first development main branch is completed, the first development main branch is used as a new version of the software to be developed to be online to the production branch. Optionally, by detecting the code stability of the first development main branch, the strategies such as gray release, backup, rollback and the like can be performed to improve the success rate of online of the new version.

The code branch management device provided by the example obtains a code snapshot of the software to be developed under the current version in the production branch; creating a first development main branch based on the code snapshot according to a preset development requirement, and creating a second development main branch according to the development requirement of the software to be developed before the first development main branch is online under the current version; if the development of the second development main branch is completed, merging the second development main branch into the production branch, and merging the second development main branch into the first development main branch after merging the second development main branch into the production branch; and if the development of the first development main branch is completed, taking the first development main branch as a new version of the software to be developed to be online to the production branch. The scheme of the application considers different development demands and creates different development branches, and the development branches can be combined with the production branches, thereby improving the efficiency of code management in software development.

As an example, the apparatus further comprises a development module 55 for:

Creating a central personal branch corresponding to the first development main branch and a central personal branch corresponding to the second development main branch based on the central code repository; based on the local code warehouse, creating a local personal branch corresponding to the first development main branch and a local personal branch corresponding to the second development main branch;

after receiving the code update of the local personal branch, synchronizing the local personal branch with the central personal branch;

detecting whether the code updating of the local personal branch is finished; if so, merging the synchronized central personal branch into the corresponding first development main branch or the corresponding second development main branch in the central code warehouse to finish the development of the first development main branch or the second development main branch.

In this example, the number of local code warehouses may be one or more, the local code warehouses clonally storing either the first development main branch or the second development main branch of the central code warehouse. In practice, when a developer locally clones a central code repository, the location of the remote repository may be specified using the uniform resource locator of the central code repository. This uniform resource locator may be an address formulated according to the hypertext transfer protocol, secure shell protocol, etc. In this example, the reliability and performance of the code repository may be improved by providing clustered code repositories. Corresponding personal branches are created in the local code warehouse and the central code warehouse, and particularly, a plurality of personal branches are arranged to develop the development branches in a distributed mode. In practice, development branches may be created by individuals or teams, and one development branch may correspond to one or more individual branches based on the scale of the development function. After receiving the code update of the local personal branch, the local personal branch and the central personal branch are synchronized. If the code updating of the local personal branch is detected to be finished, merging the synchronized central personal branch into a corresponding first development main branch or a corresponding second development main branch in a central code warehouse to finish the development of the first development main branch or the second development main branch. Optionally, when the central personal branch is merged to the corresponding development branch, an audit mechanism may be set; for example, after passing an audit by a developing colleague with audit qualification, the central individual branch can be merged into the corresponding development branch. The scheme of the example can improve the security of storage and modification by setting a central code warehouse and a local code warehouse, and can improve the efficiency of code development by setting parallel development of personal branches.

As one example, the development module 55 is further configured to:

constructing corresponding initial test environments and pre-production test environments based on the first development main branch, and constructing corresponding initial test environments and pre-production test environments based on the second development main branch; wherein at least one of test hardware performance, test data size, and test security of the pre-production environment is higher than the initial test environment;

and if the test result of the first development main branch or the second development main branch in the corresponding initial test environment and pre-production test environment is detected to be passing, locking the first development main branch or the second development main branch.

The corresponding test environment may be constructed based on the first development main branch or the second development main branch, considering that the test environment corresponding to each development branch is different. Alternatively, the same software version may correspond to the same test environment. The testing environment is mainly used for testing functions and performances, such as system integration testing by a development team, so that normal interaction among all modules is ensured, and the system functions meet the requirements in the requirement specification and the performances meet the expectations. The test accuracy can be improved by setting test environments with different grades; wherein, the test hardware can comprise a test server, a computer and a workstation; the test data scale may include small-scale data for functional or unit testing, or large-scale data for stress testing; test security may include protective measures to ensure that test data and test systems are not unauthorized access, modification, or corruption. And after detecting that the test result of the first development main branch or the second development main branch in the corresponding initial test environment and pre-production test environment is passing, locking the first development main branch or the second development main branch. After the test of the first development main branch or the second development main branch passes, the representatives can be directly combined with other branches or deployed into a production environment, and the subsequent code modification can be forbidden in a locking mode, so that the safety of the development branches is improved.

As one example, the online module 54 is further configured to:

Detecting whether at least one other first development main branch exists before the first development main branch is on line; if so, merging the first development main branch with the last line time closest to the line time of the first development main branch in at least one other first development main branch into the first development main branch.

In practical application, according to a predetermined development requirement, if two or more first development main branches exist at the same time to develop based on the same code snapshot, the development content of multiple development versions can be reserved by inheriting the first development main branch from another first development main branch before the first development main branch. In practical application, if another first development main branch is merged into the first development main branch, code conflict exists, and code review is performed by reserving codes in the first development main branch of a new version or notifying relevant developers to improve the consistency of the codes. The solution of this example can implement the inheritance of the code of the new version to the old version by merging the first development main branches of different versions.

As an example, the detection module 53 is further configured to: performing a first identifier marking on the production branch based on the second development main branch; the first identifier characterizes version information of a current version of the software to be developed.

In particular, the first identifier may be configured to include different fields for identifying a secondary version of the software to be developed under the current version. In practical applications, the different minor fields can be distinguished by setting suffixes such as revisions, antecedents, extensions and the like based on different requirements. In the scheme of the example, the first identifier is used for marking different secondary versions of the available to-be-developed software, so that multiple secondary versions under the same version can be effectively managed.

The online module 54 is further configured to: performing a second identifier marking on the production branch based on the first development main branch; the second identifier characterizes version information of a new version of the software to be developed.

In particular, a number field marked as increment or decrement by the second identifier, a date field when the new version is online, or a Tag (Tag) combined with any character or number may be provided for identifying the new version of the software to be developed. The solution of this example can be used to identify new versions of the software to be developed by making a second identifier tag, to assist the development team in subsequent problem tracking and backtracking, and to facilitate better version management.

The code branch management device provided by the embodiment obtains the code snapshot of the software to be developed under the current version in the production branch; creating a first development main branch based on the code snapshot according to a preset development requirement, and creating a second development main branch according to the development requirement of the software to be developed before the first development main branch is online under the current version; if the development of the second development main branch is completed, merging the second development main branch into the production branch, and merging the second development main branch into the first development main branch after merging the second development main branch into the production branch; and if the development of the first development main branch is completed, taking the first development main branch as a new version of the software to be developed to be online to the production branch. The scheme of the application considers different development demands and creates different development branches, and the development branches can be combined with the production branches, thereby improving the efficiency of code management in software development.

Example III

Fig. 8 is a schematic structural diagram of an electronic device according to a third embodiment of the present application, where the electronic device includes:

A processor 291, the electronic device further comprising a memory 292; a communication interface (Communication Interface) 293 and bus 294 may also be included. The processor 291, the memory 292, and the communication interface 293 may communicate with each other via the bus 294. Communication interface 293 may be used for information transfer. The processor 291 may invoke logic instructions in the memory 292 to perform the methods of the examples described above.

Further, the logic instructions in memory 292 described above may be implemented in the form of software functional units and stored in a computer-readable storage medium when sold or used as a stand-alone product.

The memory 292 is a computer readable storage medium, and may be used to store a software program, a computer executable program, and program instructions/modules corresponding to the methods in the embodiments of the present application. The processor 291 executes functional applications and data processing by running software programs, instructions and modules stored in the memory 292, i.e., implements the methods in the method examples described above.

Memory 292 may include a storage program area that may store an operating system, at least one application program required for functionality, and a storage data area; the storage data area may store data created according to the use of the terminal device, etc. Further, memory 292 may include high-speed random access memory, and may also include non-volatile memory.

Embodiments of the present application also provide a computer-readable storage medium having stored therein computer-executable instructions that, when executed by a processor, are configured to implement the method of any of the embodiments.

Embodiments of the present application also provide a computer program product comprising a computer program stored in a computer readable storage medium, from which at least one processor can read the computer program, the at least one processor implementing the method of any of the embodiments when executing the computer program.

Other embodiments of the application will be apparent to those skilled in the art from consideration of the specification and practice of the application disclosed herein. This application is intended to cover any variations, uses, or adaptations of the application following, in general, the principles of the application and including such departures from the present disclosure as come within known or customary practice within the art to which the application pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the application being indicated by the following claims.

It is to be understood that the application is not limited to the precise arrangements and instrumentalities shown in the drawings, which have been described above, and that various modifications and changes may be effected without departing from the scope thereof. The scope of the application is limited only by the appended claims.

Claims (10)

1. A code branch management method, comprising:

Acquiring a code snapshot of the software to be developed under the current version in a production branch; the production branch stores all codes of the software to be developed, and the current version is a version corresponding to the current production environment;

creating a first development main branch based on the code snapshot according to a predetermined development requirement;

Detecting whether development requirements of the software to be developed under the current version exist before the first development main branch is online; if so, creating a second development main branch based on the code snapshot according to the development requirement of the software to be developed under the current version; merging the second development main branch to the production branch if the second development main branch is detected to be developed;

merging the second development main branch to the first development main branch after merging the second development main branch to the production branch; and if the first development main branch is detected to be developed, taking the first development main branch as a new version of the software to be developed to be online to the production branch.

2. The method of claim 1, wherein the first development main branch and the second development main branch are deployed at a central code repository, the method further comprising:

Creating a central personal branch corresponding to the first development main branch and a central personal branch corresponding to the second development main branch based on the central code repository; based on a local code warehouse, creating a local personal branch corresponding to the first development main branch and a local personal branch corresponding to the second development main branch;

Synchronizing the local personal branch with the central personal branch after receiving the code update of the local personal branch;

Detecting whether the code updating of the local personal branch is finished; and if so, merging the synchronized central personal branch into the corresponding first development main branch or the corresponding second development main branch in the central code warehouse to finish the development of the first development main branch or the second development main branch.

3. The method of claim 2, wherein after ending the development of the first development main branch or the second development main branch, further comprising:

Constructing corresponding initial test environments and pre-production test environments based on the first development main branch, and constructing corresponding initial test environments and pre-production test environments based on the second development main branch; wherein at least one of test hardware performance, test data size, and test security of the pre-production environment is higher than the initial test environment;

and if the test result of the first development main branch or the second development main branch in the corresponding initial test environment and pre-production test environment is detected to be passing, locking the first development main branch or the second development main branch.

4. The method of claim 1, wherein the first development main branch created based on the code snapshot is plural, and wherein before the first development main branch is brought up to the production branch as a new version of software to be developed, further comprising:

Detecting whether at least one other first development main branch exists before the first development main branch is on line; if so, merging a first development main branch with the last online time of the first development main branch in the at least one other first development main branch to the first development main branch.

5. The method of any one of claims 1 to 4, wherein after merging the second development main branch into the production branch, further comprising:

Performing a first identifier marking on the production branch based on the second development main branch; the first identifier characterizes version information of a current version of the software to be developed.

6. The method of any of claims 1 to 4, wherein after the first development main branch is brought up to the production branch as a new version of software to be developed, further comprising:

performing a second identifier marking on the production branch based on the first development main branch; the second identifier characterizes version information of a new version of the software to be developed.

7. A code branch management apparatus, comprising:

The acquisition module is used for acquiring a code snapshot of the software to be developed under the current version in the production branch; the production branch stores all codes of the software to be developed, and the current version is a version corresponding to the current production environment;

The creation module is used for creating a first development main branch based on the code snapshot according to preset development requirements;

The detection module is used for detecting whether development requirements of the software to be developed under the current version exist before the first development main branch is on line; if so, creating a second development main branch based on the code snapshot according to the development requirement of the software to be developed under the current version; merging the second development main branch to the production branch if the second development main branch is detected to be developed;

The online module is used for merging the second development main branch to the first development main branch after merging the second development main branch to the production branch; and if the first development main branch is detected to be developed, taking the first development main branch as a new version of the software to be developed to be online to the production branch.

8. An electronic device, comprising: a processor, and a memory communicatively coupled to the processor; the memory stores computer-executable instructions; the processor executes computer-executable instructions stored in the memory to implement the method of any one of claims 1 to 6.

9. A computer readable storage medium having stored therein computer executable instructions which when executed by a processor are adapted to carry out the method of any one of claims 1 to 6.

10. A computer program product comprising a computer program which, when executed by a processor, implements the method of any of claims 1 to 6.