Method, device and electronic equipment for merging code repository branches

Abstract

The application discloses a method and device for merging code version library branches and electronic equipment. The method is applied to the electronic equipment including a code version control system SVN. The method obtains initial merging parameters based on an SVN acquisition command line and a configuration file input. The initial merging parameters include a path of a target branch, a path of a source branch and code version merging parameters of the source branch in the SVN controlled code version library. The source branch is merged into the target branch based on the initial merging parameters through the SVN to obtain a merging branch. A target check report of the merging branch is obtained based on the initial merging parameters and log information of the merging branch. The result of automatically merging the branches in the code version library is obtained according to the target check report, so that the branches in the code version library are automatically merged, and a check report of the branch merging is generated, and the efficiency of code version library development is improved.

Description

Technical Field

[0001] This application relates to the field of software development technology, and more specifically, to a method, apparatus, and electronic device for merging code repository branches. Background Technology

[0002] Currently, software development often requires collaboration among multiple developers, and users typically choose open-source version control systems (such as Subversion, SVN) for code management. SVN is an open-source version control system commonly used by developers for code management. Branches are directories of files within the central repository on the SVN server. As the use of SVN tools for software development becomes increasingly widespread, users have increasingly higher demands for efficiency in SVN-based software development. Summary of the Invention

[0003] In view of the above problems, this application proposes a method, apparatus, electronic device and storage medium for merging branches in a code repository. It can obtain initial merge parameters based on SVN command line and configuration file input, automatically merge branches in the code repository according to the initial merge parameters, and generate a branch merge verification report, thereby improving the efficiency of code repository development.

[0004] In a first aspect, embodiments of this application provide a method for merging code repository branches, applied to an electronic device, the electronic device including a code version control system (SVN). The method includes: obtaining command-line input parameters and configuration file parameters based on the SVN; obtaining initial merge parameters based on the command-line input parameters and the configuration file parameters, wherein the initial merge parameters include the path of the destination branch, the path of the source branch, and the code version merge parameters of the source branch in the code repository controlled by the SVN; merging the source branch into the destination branch through the SVN based on the path of the destination branch, the path of the source branch, and the code version merge parameters of the source branch, to obtain a merged branch; obtaining log information of the merged branch as a first target log; obtaining a target verification report of the merged branch based on the initial merge parameters and the first target log; and determining the merge result of merging the source branch into the destination branch in the code repository based on the target verification report.

[0005] Secondly, embodiments of this application provide an apparatus for merging code repository branches, applied to an electronic device, the electronic device including a code version control system SVN, the apparatus including: an input parameter acquisition module, an initial merge parameter acquisition module, a branch merge module, a first target log acquisition module, a verification report acquisition module, and a merge result determination module. The system includes the following modules: an input parameter acquisition module for acquiring command-line input parameters and configuration file parameters based on the SVN; an initial merge parameter acquisition module for obtaining initial merge parameters based on the command-line input parameters and the configuration file parameters, wherein the initial merge parameters include the path of the destination branch, the path of the source branch, and the code version merge parameters of the source branch in the code repository controlled by the SVN; a branch merge module for merging the source branch into the destination branch through the SVN based on the path of the destination branch, the path of the source branch, and the code version merge parameters of the source branch, to obtain a merged branch; a first target log acquisition module for acquiring the log information of the merged branch as a first target log; a verification report acquisition module for obtaining a target verification report of the merged branch based on the initial merge parameters and the first target log; and a merge result determination module for determining the merge result of merging the source branch into the destination branch in the code repository based on the target verification report.

[0006] Thirdly, embodiments of this application provide an electronic device, including a memory and a processor, wherein the memory is coupled to the processor, the memory stores instructions, and when the instructions are executed by the processor, the processor performs the above-described method.

[0007] Fourthly, embodiments of this application provide a computer-readable storage medium storing program code, which can be invoked by a processor to execute the aforementioned method. The method, apparatus, electronic device, and storage medium for merging code repository branches provided in embodiments of this application obtain command-line input parameters and configuration file parameters based on SVN; based on the command-line input parameters and configuration file parameters, initial merge parameters are obtained, wherein the initial merge parameters include the path of the destination branch, the path of the source branch, and the source branch's code version merge parameters in the SVN-controlled code repository; based on the path of the destination branch, the path of the source branch, and the source branch's code version merge parameters, the source branch is merged into the destination branch via SVN to obtain a merged branch; log information of the merged branch is obtained as a first target log; based on the initial merge parameters and the first target log, a target verification report of the merged branch is obtained; and based on the target verification report, the merge result of merging the source branch into the destination branch in the code repository via SVN is determined. This application obtains initial merge parameters from command-line and configuration file input via SVN, and automatically merges branches in the code repository based on these parameters, generating a branch merge verification report. This achieves automatic branch merging in the code repository, reducing the cost of developing a code repository. Furthermore, the generated branch merge verification report is used to analyze and audit the code repository, improving the efficiency of code repository development. Attached Figure Description

[0008] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0009] Figure 1 A flowchart illustrating a code repository branch merging method provided in related technologies is shown; Figure 2 A flowchart illustrating a method for merging code repository branches according to an embodiment of this application is shown; Figure 3 This illustration shows a flowchart of the workflow of a single-version automatic merge transaction model provided in an embodiment of this application; Figure 4 This application illustrates a schematic diagram of the workflow of a merged code repository branch system according to an embodiment of the present application. Figure 5 A flowchart illustrating a method for merging code repository branches according to an embodiment of this application is shown; Figure 6A flowchart illustrating a method for merging code repository branches according to an embodiment of this application is shown; Figure 7 A flowchart illustrating a method for merging code repository branches according to an embodiment of this application is shown; Figure 8 A flowchart illustrating a method for merging code repository branches according to an embodiment of this application is shown; Figure 9 A flowchart illustrating a method for merging code repository branches according to an embodiment of this application is shown; Figure 10 This invention provides a module block diagram of an apparatus for merging code repository branches according to an embodiment of the present application. Figure 11 A block diagram of an electronic device for performing a method for merging code repository branches according to an embodiment of this application is shown; Figure 12 An embodiment of this application illustrates a storage unit for storing or carrying program code that implements a method for merging code repository branches according to an embodiment of this application. Detailed Implementation

[0010] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings.

[0011] Currently, software configuration management technologies have seen the emergence of methods that manage database data using code management tools like Subversion. Subversion is a centralized code management tool, with its core being a central repository for storing data. This central repository stores files and their hierarchical structure using a tree-like file system, and comprehensively records the change history of files and directories. Subversion is based on a "copy-modify-merge" rotational locking model, allowing multiple users to read the central repository through clients, create local working copies, implement local changes, and merge these local changes into the central repository, thus meeting the needs of multi-user parallel development.

[0012] Currently, the most frequently used processing in software configuration management and code management software engineering practices is "branching." The motivation for creating branches in related technologies is to ensure that, within a preset time period, all modifications made to the code repository by the code management tool can be broken down into multiple different tasks for parallel development. The code and commit records for each task can focus on an independent task, without interference, and without affecting existing functionality in the code repository. In related technologies, SVN provides the function of merging changes between branches, especially the CHERRY-PICK method. Based on command-line operations or a graphical user interface (GUI), users can merge code changes corresponding to selected SVN version numbers from the source branch to the destination branch between the trunk and derived branches, or between derived branches of the same series. In case of merge conflicts, the SVN tool will terminate the merge operation and cannot commit the code changes to the repository, thus not affecting the existing code functionality in the repository.

[0013] In software engineering practice, whether it is a branching strategy based on the main branch or a branching strategy based on parallel development of multiple branches, it is inevitable to merge changes between different branches. Among related technologies, SVN tools provide a human-computer interaction interface for merging operations. However, when faced with a large number of version changes accumulated under the same source branch and version changes from multiple branches, simple manual merging still has two major drawbacks and seriously affects the efficiency of the project: (1) the operation is cumbersome, repetitive, time-consuming, and inconsistent; (2) the integrity and correctness of the merge are difficult to analyze and audit.

[0014] For example, please refer to Figure 1 This document illustrates a flowchart of a single merge process for inter-branch changes using SVN tools in a manual manner. The process involves: first, determining the merge parameters, including the source branch path, destination branch path, and the merge version range; then, manually recording the merge parameters for future reference; inputting these parameters into the SVN tool and triggering the merge; waiting for the local merge to complete; finally, committing the local merge to the SVN-controlled code repository; and finally, manually recording the merge completion for future reference. However, this process relies heavily on manual user intervention and requires continuous monitoring of the merge progress. The waiting time for the local merge to complete is unpredictable. The manual recording for future reference is difficult to standardize across different users, leading to incomplete and incorrect merge results and inefficient analysis and auditing of merge results for software development. Furthermore, even with only a few merge conflicts to resolve, a large number of tedious and repetitive steps can result in low project efficiency when faced with numerous merge requests.

[0015] To address the aforementioned problems, the inventors, through extensive research, discovered and proposed the method, apparatus, electronic device, and storage medium for merging code repository branches provided in this application. This method obtains initial merge parameters by acquiring command-line and configuration file inputs based on SVN. Based on these parameters, it automatically merges branches in the code repository and generates a branch merge verification report, thus achieving automatic branch merging and reducing the cost of developing code repositories. Furthermore, it analyzes and audits the code repository based on the generated branch merge verification report, improving the efficiency of code repository development. The specific method for merging code repository branches will be described in detail in subsequent embodiments.

[0016] Please see Figure 2 , Figure 2 This diagram illustrates a flowchart of a method for merging code repository branches according to an embodiment of this application. This method obtains initial merge parameters by acquiring command-line and configuration file inputs via SVN. Based on these parameters, it automatically merges branches in the code repository and generates a branch merge verification report, thus achieving automatic merging of branches and reducing the cost of developing code repositories. Furthermore, it analyzes and audits the code repository based on the generated branch merge verification report, improving the efficiency of code repository development. In specific embodiments, this method for merging code repository branches can be applied to, for example... Figure 10 The apparatus 200 for merging code repository branches shown, and the electronic device 100 configured with the apparatus 200 for merging code repository branches. Figure 11 The following will use an electronic device as an example to illustrate the specific process of this embodiment. The electronic device includes the code version control system SVN. Of course, it is understood that the electronic device used in this embodiment can include smartphones, tablets, wearable electronic devices, etc., and is not limited here. The following will focus on Figure 2 The process shown will be explained in detail. The method for merging code repository branches may specifically include the following steps: Step S110: Obtain command line input parameters and configuration file parameters based on the SVN.

[0017] In some implementations, the electronic device may include a human-computer interaction (HCI) interface, which may use a command-line style for data interaction. The electronic device may receive command-line input parameters from the user through this HCI interface, such as the source branch SVN-Uniform Resource Locator (URL), the destination branch SVN-URL, and the path to the local copy of the destination branch. Furthermore, the electronic device may automatically control SVN to retrieve the command-line input parameters in response to the user's command-line input and further load configuration file parameters, such as the path to the merge ignore list configuration file from the source branch to the destination branch.

[0018] It is understood that the method for merging code repository branches provided in this application triggers the automatic merging of code repository branches through a command-line style interactive method, which facilitates integration into a continuous integration / continuous delivery (CI / CD) system, deploys an automated pipeline for the automatic merging of code repository branches, and improves the efficiency of merging code repository branches.

[0019] Step S120: Obtain initial merge parameters based on the command line input parameters and the configuration file parameters, wherein the initial merge parameters include the path of the destination branch, the path of the source branch, and the code version merge parameters of the source branch in the SVN-controlled code repository.

[0020] In some implementations, after obtaining command-line input parameters and configuration file parameters, the electronic device can further obtain initial merge parameters based on these parameters. These initial merge parameters may include the path to the destination branch, the path to the source branch, and the source branch's code version merge parameters in the SVN-controlled code repository. The source branch's code version merge parameters may include the starting version number, ending version number, and ignored version number of the source branch merging into the destination branch.

[0021] In some implementations, the command-line input parameters entered by the user may include the starting version number of the source branch to be merged into the destination branch, thereby allowing the user to forcibly specify the starting version of the source branch to be merged into the destination branch, thus increasing the user's initiative in software development.

[0022] In some implementations, electronic devices can pre-set the version number of the source branch from which the target branch is created by default as the starting version for merging the source branch into the target branch, thereby reducing the cumbersomeness of merging code repository branches and improving the efficiency of merging code repository branches.

[0023] In some implementations, the command-line input parameters entered by the user may include the final version number of the source branch to be merged into the destination branch, thereby allowing the user to forcibly specify the final version of the source branch to be merged into the destination branch, thus increasing the user's initiative in software development.

[0024] In some implementations, electronic devices can be pre-set to merge all changed code versions after the starting version of the source branch into the destination branch by default, thereby improving the completeness of batch automatic merging of code repository branches.

[0025] Step S130: Based on the path of the destination branch, the path of the source branch, and the code version merge parameter of the source branch, merge the source branch into the destination branch through SVN to obtain the merged branch.

[0026] In some implementations, after receiving user command line input, the electronic device can respond to the command line input and, based on the obtained merge initialization parameters, merge the source branch corresponding to the merge initialization parameters into the destination branch via SVN to obtain the merged branch.

[0027] The electronic device can construct a set of svn-merge configuration parameters for batch merging based on merge initialization parameters. Furthermore, by traversing this set and using a single-version automatic merge transaction model, it applies the svn-merge configuration parameters for each version, merging the corresponding versions from the source branch into the destination branch. The set of svn-merge configuration parameters can be understood as a collection of versions from the source branch to be merged into the destination branch, or as a sequence of versions from the source branch to be merged into the destination branch. The versions in the source branch within this sequence can be arranged in ascending or descending order of their version numbers.

[0028] In some implementations, to ensure the reliability of merging source branches into destination branches, electronic devices can use a single-version automatic merge transaction model. This involves traversing the svn-merge configuration parameter set, i.e., traversing the version sequence in the source branch that will be merged into the destination branch. The changed code versions in the version sequence are then serially and continuously merged into the destination branch. Furthermore, if there is a conflict in merging a version from the source branch into the destination branch, the merging of that version is stopped to facilitate timely error correction and verification of the merge results, thereby improving the reliability of the merge operation.

[0029] The process of merging a version from the source branch into the destination branch based on the single-version automatic merge transaction model can include five atomic operations (Revert, Update, Merge, Check, Commit). If any atomic operation fails, the entire transaction of merging that version into the destination branch is terminated.

[0030] For example, please refer to Figure 3 This document illustrates the workflow of a single-version automatic merging transaction model. In the preparation phase of merging a branch based on this model, the version number of the source branch to be merged into the target branch is obtained as the merge version number. The root-URL of the source branch (i.e., the top-level directory of the source branch in the code repository) and the root-path of the local working copy of the target branch (i.e., the top-level directory of the target branch in the code repository) are also obtained. Then, the system enters the Revert state to restore and clean up any unexpected changes in the local working copy of the target branch, ensuring consistency between the content of the local working copy and the code repository. Next, it enters the Update state to update the version in the local working copy of the target branch. Then, it enters the Merge state to merge the changed code version from the source branch into the local working copy of the target branch. Finally, it enters the Check state to check for conflicts between the source and target branch versions reported by SVN. If conflicts exist, the merging process ends; otherwise, it analyzes whether there are any changes in the local working copy of the target branch. If no conflicts exist, the merging process ends; otherwise, it enters the Commit state to save the changes in the local working copy of the target branch.

[0031] In some implementations, electronic devices can apply the svn-merge configuration parameter set for each version and merge the corresponding version of the source branch into the destination branch by traversing the svn-merge configuration parameter set and using a single-version automatic merge transaction model, thus obtaining a merged branch.

[0032] It is understood that the method for merging code repository branches provided in this embodiment automatically batch merges branch changes in the code repository based on the code management tool Subversion, freeing users from tedious and repetitive transactional operations and focusing on iterative resolution of merge conflicts, reducing human error and improving the efficiency of automatic merging of code repository branches.

[0033] Step S140: Obtain the log information of the merged branch as the first target log.

[0034] In some implementations, after obtaining the merged branch, the electronic device can acquire the log information of the merged branch as the first target log. The first target log may include version change records in the target branch, the starting version of the source branch to be merged into the target branch, and the ending version of the source branch to be merged into the target branch.

[0035] Step S150: Based on the initial merge parameters and the first target log, obtain the target verification report of the merged branch.

[0036] In some implementations, after obtaining the first target log, the electronic device can obtain a target verification report for the merged branch based on the initial merge parameters and the first target log. Specifically, the electronic device can obtain version change records of the source branch and the target branch within a preset range based on the initial merge parameters and the first target log. Further, the electronic device can compare the changed version content of the source branch within the preset range with the changed version content of the target branch within the preset range. If the content is the same, the version verification is considered successful, and a "correct source branch merge" marker can be added to the merged branch's log information, or a target verification report including the "correct source branch merge" marker can be generated. If the content is different, the version verification is considered unsuccessful, and a "source branch merge error" marker can be added to the merged branch's log information, or a target verification report including the "abnormal source branch merge" marker can be generated. In some implementations, the electronic device can pre-set the order of verifying the code versions of the source branch merged into the target branch. For example, the electronic device can pre-set the starting code version for verifying the source branch merged into the target branch to the source branch version number and the target branch version number when the target branch was created from the source branch.

[0037] In some implementations, the target verification report may also include the source branch URL, the destination branch URL, the archive address of the target verification report, and the commit ID of the version in the source branch.

[0038] Step S160: Determine the merge result of merging the source branch in the code repository into the destination branch based on the target verification report and the SVN.

[0039] In some implementations, during the development and management of the code repository, the electronic device can obtain a target verification report and determine the merging result of merging the source branch into the target branch based on SVN, according to the target verification report. The merging result can include conclusions from a horizontal comparison of the version list of the source branch and the version list of the merged branch, such as: the source branch version is the same as the merged version of the target branch; a version unique to the source branch; a version unique to the target branch; a version not merged from the source branch; or a version unique to the merged branch that is not merged from the source branch.

[0040] For example, please refer to Figure 4This document illustrates a flowchart of a code repository merging branch system according to an embodiment of this application. The system is implemented using Python programming and is based on the command-line interface provided by the Subversion code management tool. The system comprises the following components: Module 1 - Merge Parameter Loading, Module 2 - Main Flow Control, Module 3 - Report Generation and Archiving, Module 4 - Merge Engine, Module 5 - Verification Engine, Module 6 - Subversion Driver, and Module 7 - Data Access Driver.

[0041] Module 1 - Merge Parameter Loading: This module receives user command-line input parameters and loads configuration file input parameters to obtain initial merge parameters, such as the starting version of the source branch, the ending version of the source branch, the ignored version parameters of the source branch, the path of the source branch, and the path of the destination branch. Module 2 - Main Flow Control: This module controls the system's main flow, responding to user command-line input and automatically triggering subsequent corresponding processes, such as initiating batch branch merges, initiating branch merge checks, outputting and archiving branch merge check reports, and storing the history of batch branch merges. Module 3 - Report Generation and Archiving: This module generates branch merge integrity and correctness check reports, pushes reports via email, and archives them. Module 4 - Merge Engine: Based on the initial merge parameters, this module constructs a set of svn-merge configuration parameter sets for batch merging source branches. It then iterates through the svn-merge configuration parameter set and, based on a single-version automatic merge transaction model, applies the svn-merge configuration parameter sets for each version, enabling the corresponding version of the source branch to be merged into the destination branch, thus obtaining the merged branch. Module 5 - The Validation Engine can be used to load the set of svn-merge configuration parameters for batch merging and, based on the actual merge change records of the source and destination branches and the merge branch log (svn log), check the integrity and correctness of the code versions in the source branches being merged into the destination branch. Module 6 - The Subversion Driver can be used to encapsulate the svn command-line interface for external calls, implementing svn command operations such as update, merge, commit, info, and log operations; all svn command operations will check the validity of the command operation and return a boolean value. Module 7 - The Data Access Driver can be used to encapsulate the SQLite database operation interface, such as creating tables, querying records, adding records, and deleting records.

[0042] Understandably, this code repository branch merging system integrates branch merging and checking, allowing users to input initial merge parameters via command line and configuration files. It automatically merges batch versions from the source branch into the target branch based on these parameters, and compares and checks the merged version lists of the source and target branches. It obtains a verification report that includes checks on the completeness and correctness of the branch merging in the code repository. Based on the verification report, it obtains the merging result of the code repository branches automatically merged using SVN, enabling software development and improving software development efficiency.

[0043] This application provides a method for merging code repository branches according to an embodiment. This method obtains command-line input parameters and configuration file parameters based on SVN. Based on these parameters, initial merge parameters are obtained, including the path of the target branch, the path of the source branch, and the source branch's code version merge parameters. Based on these parameters, the source branch is merged into the target branch using SVN to obtain a merged branch. Log information of the merged branch is obtained as a first target log. A target verification report for the merged branch is obtained based on the initial merge parameters and the first target log. The merge result (merging the source branch into the target branch using SVN) is determined based on the target verification report. This application obtains initial merge parameters by acquiring command-line and configuration file inputs from SVN, automatically merges branches in the code repository based on these parameters, and generates a branch merge verification report. This achieves automatic merging of branches in the code repository, reducing the cost of developing a code repository. Furthermore, the generated branch merge verification report is used to analyze and audit the code repository, improving the efficiency of code repository development.

[0044] Please see Figure 5 , Figure 5 A flowchart illustrating a method for merging code repository branches according to an embodiment of this application is shown. This method is applied to the aforementioned electronic device, and will be discussed below regarding... Figure 5 The process shown will be explained in detail. The method for merging code repository branches may specifically include the following steps: Step S210: Obtain command line input parameters and configuration file parameters based on the SVN.

[0045] Step S220: Obtain initial merge parameters based on the command line input parameters and the configuration file parameters, wherein the initial merge parameters include the path of the destination branch, the path of the source branch, and the code version merge parameters of the source branch in the SVN-controlled code repository.

[0046] For a detailed description of steps S210-S220, please refer to the previous description of steps S110-S120, which will not be repeated here.

[0047] Step S230: Based on the path of the destination branch, the path of the source branch, and the code version merge parameter of the source branch, merge the source branch into the destination branch through SVN to obtain the merged branch.

[0048] In some implementations, after obtaining the initial merge parameters, the electronic device can merge the source branch into the destination branch via SVN based on the path of the destination branch, the path of the source branch, and the code version merge parameters of the source branch in the initial merge parameters, thereby obtaining a merged branch.

[0049] The source branch's code version merging parameters can include the starting and ending version numbers of the target branch to which the source branch is being merged. Furthermore, the electronic device can determine all changed code versions from the starting to the ending version number within the source branch based on the source branch's path, using these as the versions to be merged into the target branch. This merged version is then imported into the target branch based on the target branch's path, resulting in a merged branch.

[0050] In some implementations, please refer to Figure 6 Step S230 may include steps S2310-S2330.

[0051] Step S2310: Obtain a list of merged code versions of the source branch according to the merged code version parameter of the source branch, wherein the list of merged code versions includes at least one merged code version.

[0052] In some implementations, the source branch code version merging parameter may include the starting version number and the ending version number of the source branch. Furthermore, the electronic device may construct a set or list of merged code versions of the source branch based on the path of the source branch and all changed code versions from the starting version number to the ending version number. The set or list of merged code versions may include at least one merged code version.

[0053] In some implementations, the source branch code version merging parameters may include the source branch's starting version number, the source branch's ending version number, and the source branch's ignored version number. Furthermore, the electronic device may construct a set or list of merged code versions for the source branch based on all changed code versions in the source branch from the source branch's starting version number to the source branch's ending version number, excluding the source branch's ignored version number. The set or list of merged code versions may include at least one merged code version.

[0054] In some implementation methods, please refer to Figure 7 The code version merge parameter of the source branch may include the starting code version of the source branch and the ending code version of the source branch. Furthermore, step S2310 may include steps S2311-S2313.

[0055] Step S2311: Obtain the log information of the source branch as the initial log, wherein the initial log includes a first ignore merge flag corresponding to the code version in the source branch that is ignored from merging into the destination branch.

[0056] It is understandable that, in some implementations, there may be changed code versions in the source branch that cannot be merged or should not be merged into the destination branch. In this embodiment, to improve the rationality of merging code repository branches, specific versions in the source branch may be ignored when merging the source branch version into the destination branch. For example, there may be changed code versions in the source branch that do not need to be merged into the destination branch between the starting version number and the ending version number. This can be understood as ignoring the merging of changed code versions in the source branch.

[0057] In some implementations, to improve the accuracy of automatically merging code repository branches based on SVN tools, the electronic device can write a predefined first ignore merge flag into the svn-log-message of the source branch according to the SVN-log characteristics. Furthermore, the electronic device can construct a merge version list of the source branch to be merged into the destination branch based on the source branch's log, the path of the destination branch, the path of the source branch, and the code version merge parameters of the source branch.

[0058] In some implementations, the electronic device can obtain the log information of the source branch as an initial log. This initial log may include a first ignore merge flag corresponding to the code version in the source branch that is ignored from merging into the destination branch. The electronic device can define a structured first ignore merge flag and write it into the source branch's log information. It is understood that the structured first ignore merge flag standardizes the feature information of the version in the log information that corresponds to the source branch ignoring the merge into the destination branch, improving the efficiency of optimizing the merge code version list based on the initial log. Furthermore, it facilitates subsequent user operations on the first ignore merge flag.

[0059] For example, please refer to [the document / reference]. Figure 4 Module 4 - the merge engine can be used to obtain the initial log of the source branch when constructing the merge code version list of the source branch, and based on the initial log, identify the first ignore merge flag to obtain the version of the source branch to ignore merge to the destination branch, and exclude the version from the merge code version list.

[0060] Step S2312: Based on the first ignore merge flag, obtain the first ignore merge code version of the source branch.

[0061] In some implementations, the electronic device can obtain a first ignored merge code version of the source branch based on a first ignored flag, that is, a changed code version in the source branch that ignores importing the destination branch.

[0062] Step S2313: Based on the first ignored merge code version of the source branch, the starting code version of the source branch, and the ending code version of the source branch, obtain a list of merge code versions of the source branch.

[0063] In some implementations, after obtaining the first ignored merge code version, the electronic device can obtain a list of merge code versions for the source branch based on the first ignored merge code version, the starting code version of the source branch, and the ending code version of the source branch. Specifically, the electronic device can construct a list of merge code versions for the source branch based on the modified code versions between the starting and ending code versions of the source branch, excluding the first ignored merge code version. These modified code versions can be understood as merge code versions, and the number of modified code versions can be one or more. The electronic device can sort these modified code versions in ascending or descending order of their version numbers to obtain the list of merge code versions.

[0064] In some implementations, see Figure 8 The code version merge parameter of the source branch may include the starting code version of the source branch and the ending code version of the source branch. Furthermore, step S2310 may include steps S2314-S2316.

[0065] Step S2314: Obtain the second ignore merge flag corresponding to the code version in the source branch that is ignored from merging into the destination branch from the command line input parameters.

[0066] In some implementations, the electronic device is pre-configured with a configuration file that allows users to specify ignored file paths based on command-line input. This means users can specify the code version from the source branch to be ignored when merging into the destination branch via the command line. To facilitate obtaining the user-specified code version from the source branch to be ignored when merging into the destination branch, in this embodiment, the electronic device can define a structured configuration of ignored source branch code versions based on an ignore manifest configuration file strategy and write it into the configuration file, thereby allowing users to specify ignored file paths via the command line; the specified ignored file path can be understood as a second ignore merge flag. Furthermore, the electronic device can obtain the second ignore merge flag corresponding to the code version from the source branch to be ignored when merging into the destination branch from the command-line input parameters.

[0067] Step S2315: Based on the second ignore merge flag, obtain the second ignore merge code version of the source branch.

[0068] In some implementations, after the electronic device obtains the second ignore merge flag, it can obtain the second ignore merge code version of the source branch based on the second ignore merge flag. For example, please refer again... Figure 4 Module 4 - the merge engine can be used to obtain the specified ignored file path of the source branch included in the command-line input parameters loaded and imported by Module 1 - the merge parameters, which is the second ignored merge flag. Furthermore, when constructing the merge code version list of the source branch, Module 4 - the merge engine can identify the change code version corresponding to the second ignored merge flag as the second ignored merge code version and exclude this second ignored merge code version from the list of merge code versions for the source branch.

[0069] Step S2316: Based on the second ignored merge code version of the source branch, the starting code version of the source branch, and the ending code version of the source branch, obtain a list of merge code versions of the source branch.

[0070] In some implementations, after the electronic device obtains the second ignored merge code version, the starting code version of the source branch, and the ending code version of the source branch, it can use the changed code versions between the starting code version and the ending code version of the source branch, excluding the second ignored merge code version, as merge code versions to construct a merge code version list for the source branch. The merge code versions in the merge code version list can be sorted in ascending or descending order according to their version numbers.

[0071] In some implementations, when there is no code version in the source branch to ignore when merging into the destination branch, the electronic device can add a list of ignored changed code version numbers when there is a conflict between the code versions in the source branch and the code versions in the destination branch. The electronic device can also add an ignore manifest configuration file path when there is a conflict between the code versions in the source branch and the code versions in the destination branch. Furthermore, the electronic device can construct a merge code version list for the source branch by using all changed code versions between the starting and ending code versions of the source branch, excluding those in the ignore changed code version number list.

[0072] Step S2320: Based on the path of the source branch, determine at least one target merge code version from the merge code list.

[0073] In some implementations, after obtaining a list of merge code versions for the source branch, the electronic device can determine at least one target merge code version from the list of merge code versions based on the path of the source branch. The target merge code version can be understood as the modified code version imported from the source branch into the destination branch.

[0074] Step S2330: Merge the at least one target code version into the target branch using the SVN path to obtain the merged branch.

[0075] In some implementations, after obtaining the target merge code version, the electronic device can use SVN to merge at least one target merge code version into the target branch along the path of the target branch, thus obtaining a merged branch. Optionally, the electronic device can import the target merge code version into the target branch based on the single-version automatic merge model provided in the embodiments of this application, thus obtaining a merged branch. If there is a conflict between the target merge code version and the target branch, the merging of the target merge code version into the target branch is stopped. Furthermore, based on the code management tool Subversion, changes from the source branch are automatically and batch-merged into the target branch, enabling convenient automatic merging of a large number of code version changes accumulated under the same source branch into the target branch, and ensuring that code version changes from multiple target branches originate from the same source branch, thereby improving the uniformity of code version management.

[0076] For example, an electronic device merges at least one target merge version into a target branch via SVN, following the path of the target branch. To obtain the merge branch, the merge engine in the electronic device can combine initial merge parameters and a first ignore merge flag to construct a list of merge versions of the source branch and propose an ignore version number for the source branch. Further, the merge engine in the electronic device can construct a set of version svn-merge configuration parameters based on the list of merge versions of the source branch, iterate through the svn-merge configuration parameter set, apply version svn-merge, obtain the merge branch, and add structured automatic merge feature information containing the merge version number of the source branch to the cvn-commit-log-message. If a merge conflict occurs, the current and subsequent version merges are terminated. Finally, the merge engine in the electronic device can return the merge results of this batch to the main process, which then writes them to the database for archiving.

[0077] Step S240: Obtain the log information of the merged branch as the first target log.

[0078] For a detailed description of step S240, please refer to the previous description of step S140, which will not be described in detail here.

[0079] Step S250: Based on the first target log and the initial merge parameters, obtain the changed code version of the target branch and obtain the ignore check flag corresponding to the target branch, wherein the ignore check flag is used to characterize the unique code version of the target branch.

[0080] In some implementations, merging a branch can be understood as the branch obtained after importing the code version of the source branch into the destination branch; wherein, the log information of the merged branch may include the change record of the code version in the merged branch, or may include the tags of each version in the destination branch.

[0081] In some implementations, considering that there may be unique modified versions in the destination branch that are unrelated to the source branch, in the embodiments of this application, the electronic device may pre-add an ignore check mark to the unique modified versions in the destination branch that are unrelated to the source branch, so as to improve the correctness of the electronic device in verifying the merging of the source branch into the destination branch.

[0082] In some implementations, after obtaining the first target log of the merge branch, the electronic device can deduce the starting and ending code version numbers of the source branch merge by combining the initial merge parameters and the first target log. Alternatively, it can obtain the changed code version of the destination branch and the ignore check flag corresponding to the destination branch based on the first target log and the initial merge parameters; wherein, the ignore check flag is used to characterize the unique code version of the destination branch. The electronic device can obtain the changed code version of the destination branch based on the first target log and the initial merge parameters by having its verification engine extract the version change records of the source branch and the destination branch; wherein, the version change record of the destination branch may include the changed code version of the destination branch. In some implementations, the electronic device can identify the source branch merge starting version forcibly specified by the command-line input parameters based on the feature information of the svn-log-message in the first target log.

[0083] Step S260: Based on the initial merge parameters, the changed code version, and the ignore check flag, obtain the target verification report of the target branch.

[0084] In some implementations, after the electronic device obtains the change code version and ignore check flags of the target branch, it can obtain the target verification report of the target branch based on the initial merge parameters, change code version, and ignore check flags.

[0085] The verification engine in the electronic device can extract the version change records of the source branch and the destination branch based on the first target log and initial merge parameters. It can also identify the first ignore merge flag and the second ignore merge flag of the source branch, as well as the ignore check flag of the destination branch, based on these records. Furthermore, the verification engine can analyze the first ignore merge flag, the second ignore merge flag of the source branch, and the ignore check flag of the destination branch to obtain a target verification report for the destination branch. For example, version change records unique to the source branch are ignored for comparison and only recorded as "source branch unique"; version change records unique to the destination branch are ignored for comparison and only recorded as "destination branch unique"; other version change records in the source and destination branches are also recorded.

[0086] Furthermore, the verification engine in the electronic device can also analyze other code version change records in the source branch and the destination branch to obtain the target verification report for the destination branch. For example, the changed version of the source branch has been merged into the destination branch; the changed version of the source branch has not been merged into the destination branch, but it is not marked as not needing to be merged into the branch; the changed version number of the destination branch is not related to the source branch, but it is not marked as being unique to the destination branch.

[0087] In some implementations, step S260 may include steps S2610 and S2620, or steps S2610 and S2630.

[0088] Step S2610: Based on the ignored check flag, obtain the similarity between the code version corresponding to the initial merge parameter and the changed code version.

[0089] In some implementations, after obtaining the ignore check flag of the target branch, the electronic device can obtain the unique code version of the target branch. Further, based on the unique code version of the target branch, the electronic device can filter modified versions of the target branch that have undergone similarity calculations with the code version corresponding to the initial merge parameter. It can then perform similarity calculations between the modified code versions of the target branch (excluding the unique code version) and the code version corresponding to the initial merge parameter to obtain the similarity between the code version corresponding to the initial merge parameter and the modified code version.

[0090] In some implementations, please refer to Figure 9 Step S2610 may include steps S2611-S2614.

[0091] Step S2611: Obtain the log information of the source branch as the second target log.

[0092] In some implementations, after merging the source branch into the destination branch, the electronic device can retrieve the source branch's log information again and use this log information as a second target log. The second target log may include the source branch's code version change record, a first ignore merge flag for the source branch, and a second ignore merge flag for the source branch.

[0093] Step S2612: If it is determined from the first target log and the second target log that there is an unmerged code version in the source branch that corresponds to the initial merge parameter and has not been merged into the destination branch, then output a first prompt message, wherein the first prompt message is used to prompt for input of a first flag, wherein the first flag is used to indicate that the verification of the unmerged code version is ignored.

[0094] In some implementations, the first target log may include records of code version changes in the target branch, and the second target log may include records of code changes in the source branch. If the electronic device determines, based on the first and second target logs, that a non-merged code version exists in the source branch with the corresponding initial merge parameters but has not been merged into the target branch, then a first prompt message is input. The non-merged code version can be understood as a modified code version of the source branch that has not been merged into the target branch, and this modified code version does not have a first ignore merge flag or a second ignore merge flag. The first prompt message can be a voice prompt, a visual prompt, or an indicator light prompt.

[0095] In some implementations, the electronic device may be pre-configured with permissions for the source branch's code version and the merged branch's code version, which are set by the user for verification. The first prompt message can be used to prompt the user to input a first flag, which indicates that verification of the unmerged code version should be ignored. This can be understood as the first prompt message prompting the user to add the first flag to the source branch's log information to improve the correctness of branch merging in the code repository.

[0096] In some implementations, the electronic device can supplement the source branch's log information with a first marker based on the first prompt information. This first marker can be a first ignore merge marker, thereby improving the correctness of branch merging in the verification code repository. Furthermore, supplementing the first marker by the electronic device solidifies the information about ignoring verified code versions, avoiding the electronic device repeatedly confirming the unmerged code version and generating the first prompt information, thus reducing the power consumption of the electronic device.

[0097] Step S2613: If it is determined from the first target log and the second target log that there is a target change code version in the merged branch that does not correspond to the source branch, then output a second prompt message, wherein the second prompt message is used to prompt for input of a second flag, wherein the second flag is used to indicate that the verification of the target change code version is ignored.

[0098] In some implementations, if the electronic device determines, based on the first target log and the second target log, that there exists a target change code version in the merged branch that does not correspond to the source branch, then it outputs a second prompt message. Here, the target change code version can be understood as the change code version of the destination branch being unrelated to the source branch and not having any ignored check flags. The second prompt message can be a voice prompt, a visual prompt, or an indicator light prompt.

[0099] In some implementations, the electronic device may be pre-configured with permissions for the source branch's code version and the merged branch's code version, which are set by the user for verification. The second prompt message can be used to prompt the user to input a second marker, which can be used to indicate that verification of the target changed code version is ignored. This can be understood as the second prompt message prompting the user to add a second marker to the merged branch's log information to improve the correctness of branch merging in the code version repository.

[0100] In some implementations, the electronic device can supplement the log information of the merged branch with a second marker based on the second prompt information. This second marker can be an ignore check marker to improve the correctness of branch merging in the code version library. Furthermore, supplementing the second marker by the electronic device solidifies the information about ignoring code version checks, avoiding the electronic device repeatedly confirming the target changed code version and generating the second prompt information, thus reducing the power consumption of the electronic device.

[0101] Step S2614: Based on the unmerged code version, the target changed code version, and the unique code version, obtain the similarity between the code version corresponding to the initial merge parameter and the changed code version.

[0102] In some implementations, after the electronic device determines the unmerged code version of the source branch, the target change code version of the destination branch, and the unique code version, it can obtain the similarity between the content of the merged code version in the source branch (which corresponds to the initial merge parameters and excludes the unmerged code version) and the content of the change code in the destination branch (which excludes the unique code version and the target change code version). This similarity can include similarity in file attributes, similarity in the committing device ID of the version number, and similarity in file content.

[0103] Step S2620: If the similarity is greater than the similarity threshold, a first target verification report is generated, wherein the first target verification report is used to indicate that the code version verification of the merged branch has passed.

[0104] The electronic device can be pre-set with a similarity threshold to determine whether the code version verification of the merged branch has passed. The similarity threshold can be that the file changes corresponding to each change code version number in the merged branch are exactly the same as the file changes corresponding to the merged code version number in the associated source branch. For example, if the electronic device detects that the file changes corresponding to each change code version number in the merged branch are the same as the file changes corresponding to the merged code version number in the associated source branch, it generates a first target verification report, which indicates that the code version verification of the merged branch has passed. If the file changes corresponding to each change code version number in the merged branch are the same as the file changes corresponding to the merged code version number in the associated source branch, the electronic device can determine that the code version verification of the merged branch has passed and can add a marker indicating that the source branch was merged correctly to the merged branch's log information.

[0105] Step S2630: If the similarity is less than or equal to the similarity threshold, a second target verification report is generated, wherein the second target verification report is used to characterize that the code version verification of the merged branch fails.

[0106] The electronic device can be pre-set with a similarity threshold to determine whether the code version verification of the merged branch passes. This similarity threshold can be set to ensure that the file changes corresponding to each code version number in the merged branch are identical to the file changes corresponding to the merged code version number in the associated source branch. For example, if the electronic device detects that the file changes corresponding to each code version number in the merged branch are completely different from or not completely identical to the file changes corresponding to the merged code version number in the associated source branch, it generates a second target verification report. This second target verification report indicates that the code version verification of the merged branch has failed. If the file changes corresponding to each code version number in the merged branch are completely different from or not completely identical to the file changes corresponding to the merged code version number in the associated source branch, the electronic device can determine that the code version verification of the merged branch has failed and can add a marker indicating an abnormal merge of the source branch to the merged branch's log information.

[0107] In some implementations, the electronic device can record "source branch specific" information based on the first and second ignore merge flags of the source branch; "destination branch specific" information based on the ignore check flag of the first target log of the merged branch; the unmerged code version obtained based on the first prompt information; the target changed code version obtained based on the second prompt information; and obtain a target verification report based on the source branch merge exception flag added to the log information of the merged branch or the source branch merge correct flag added to the log information of the merged branch, as well as the code version change record of the merged branch. The target verification report is then sent to the main process module of the electronic device, and the main process module writes it into the database for archiving.

[0108] Step S270: Determine the merge result of merging the source branch in the code repository into the destination branch based on the target verification report and the SVN.

[0109] The electronic device can determine the structured merge result of merging the source branch into the destination branch in the code repository based on the target verification report. This facilitates user analysis and self-checking based on the merge result, ensuring the quality of branch merging in the code repository. The merge result may include the source branch URL, destination branch URL, and report archive address; it may also include information about unmerged code versions in the source branch, such as the version number of the unmerged code version, the device ID that committed the unmerged code version, and the svn-log-message of the unmerged code version; it may also include information about the target modified code version in the destination branch, such as the version number of the target modified code version, the device ID that committed the target modified code version, and the svn-log-message of the target modified code version; and it may also include records of automatically merged versions in the merged branch where the source and merged branches have different merged content, such as the version number of the source branch corresponding to the automatically merged version with different content, the version number of the merged branch corresponding to the automatically merged version with different content, the difference files of the automatically merged version with different content, and the differences existing in the automatically merged version with different content. Details of the differences, etc.; may also include the version number of the change version corresponding to the first and second ignore merge markers in the source branch, the device ID that committed the change version, the svn-log-message of the change version, etc.; may also include the unique change version corresponding to the ignore check markers in the destination branch, such as the version number of the unique change version, the device ID that committed the unique change version, the svn-log-message of the unique change version, etc.; may also include a horizontal comparison list of the complete set of version lists of the source and destination branches, such as the version number, commit device ID, svn-log-message of the source branch, the version number, commit device ID, svn-log-message of the destination branch, etc., and the verification conclusion (merge consistent, unique to the source branch or unique to the destination branch, version not merged in the source branch or the target change code version of the destination branch, etc.).

[0110] The method for merging code repository branches provided in one embodiment of this application is compared to... Figure 2 The method for merging code repository branches shown in this embodiment can also obtain the changed code version of the target branch and the ignore check flag corresponding to the target branch based on the first target log and the initial merge parameters. The ignore check flag is used to characterize the unique code version of the target branch. Based on the initial merge parameters, the changed code version and the ignore check flag, the target verification report of the target branch is obtained. While realizing the automatic merging of branches in the code repository, the cost of developing the code repository is reduced, the efficiency of developing the code repository is improved, and the accuracy of the automatic merging branch verification in the code repository is improved.

[0111] Please see Figure 10, Figure 10 A block diagram of an apparatus for merging repository branches according to an embodiment of this application is shown. This apparatus 200 is applied to the aforementioned electronic device, which includes a version control system (SVN). The following will focus on... Figure 10 The process is described in detail below. The device 200 for merging code repository branches includes: an input parameter acquisition module 210, an initial merge parameter acquisition module 220, a branch merge module 230, a first target log acquisition module 240, a verification report acquisition module 250, and a merge result determination module 260, wherein: The input parameter acquisition module 210 is used to acquire command line input parameters and configuration file parameters based on the SVN.

[0112] The initial merge parameter acquisition module 220 is used to obtain initial merge parameters based on the command line input parameters and the configuration file parameters, wherein the initial merge parameters include the path of the destination branch, the path of the source branch, and the code version merge parameters of the source branch in the SVN-controlled code repository.

[0113] The branch merge module 230 is used to merge the source branch into the destination branch through SVN based on the path of the destination branch, the path of the source branch, and the code version merge parameter of the source branch, thereby obtaining a merged branch.

[0114] The first target log acquisition module 240 is used to acquire the log information of the merged branch as the first target log.

[0115] The verification report acquisition module 250 is used to obtain the target verification report of the merged branch based on the initial merge parameters and the first target log.

[0116] The merge result determination module 260 is used to determine the merge result of merging the source branch in the code repository into the destination branch based on the target verification report.

[0117] Furthermore, the branch merge module 230 may include: a merge list acquisition module, a target merge version determination module, and a branch merge submodule, wherein: The merge list acquisition module is used to determine at least one target merge code version from the merge code list based on the path of the source branch.

[0118] The target merge version determination module is used to generate the updated data through the card business code included in the target code service module.

[0119] The branch merge submodule is used to merge the at least one target merge code version into the target branch via the path of the target branch through the SVN, thereby obtaining the merged branch.

[0120] Further, the source branch code version merge parameter includes the starting code version of the source branch and the ending code version of the source branch. The merge list acquisition module may include: a first ignore merge flag acquisition unit, a first ignore merge code version acquisition unit, and a merge list acquisition first unit, wherein: The first ignore merge flag acquisition unit is used to acquire the log information of the source branch as the initial log, wherein the initial log includes the first ignore merge flag corresponding to the code version in the source branch that ignores merging into the destination branch.

[0121] The first ignore merge code version obtaining unit is used to obtain the first ignore merge code version of the source branch based on the first ignore merge flag.

[0122] The merge list obtains a first unit, which is used to obtain a list of merge code versions of the source branch based on the first ignored merge code version of the source branch, the starting code version of the source branch, and the ending code version of the source branch.

[0123] Further, the source branch code version merge parameter includes the starting code version of the source branch and the ending code version of the source branch. The merge list acquisition module may include: a second ignore merge flag acquisition unit, a second ignore merge code version acquisition unit, and a merge list acquisition second unit, wherein: The second ignore merge flag acquisition unit is used to acquire the second ignore merge flag corresponding to the code version in the source branch that ignores merging into the destination branch from the command line input parameters.

[0124] The second ignore merge code version obtaining unit is used to obtain the second ignore merge code version of the source branch based on the second ignore merge flag.

[0125] The merge list obtains a second unit, which is used to obtain a list of merge code versions of the source branch based on the second ignore merge code version of the source branch, the starting code version of the source branch, and the ending code version of the source branch.

[0126] Furthermore, the verification report acquisition module 250 may include: an ignore check flag acquisition module and a verification report acquisition submodule, wherein: The ignore check flag acquisition module is used to obtain the changed code version of the target branch and the ignore check flag corresponding to the target branch based on the first target log and the initial merge parameters, wherein the ignore check flag is used to characterize the unique code version of the target branch.

[0127] The verification report acquisition submodule is used to obtain the target verification report of the target branch based on the initial merge parameters, the changed code version, and the ignore check flag.

[0128] Further, the verification report acquisition submodule may include: a similarity acquisition unit and a first verification report acquisition unit, or a similarity acquisition unit and a second verification report acquisition unit, wherein: The similarity acquisition unit is used to acquire the similarity between the code version corresponding to the initial merge parameter and the changed code version based on the ignored check flag.

[0129] The first verification report obtaining unit is used to generate a first target verification report if the similarity is greater than a similarity threshold, wherein the first target verification report is used to indicate that the code version verification of the merged branch has passed.

[0130] The second verification report obtaining unit is used to generate a second target verification report if the similarity is less than or equal to the similarity threshold, wherein the second target verification report is used to characterize that the code version verification of the merged branch fails.

[0131] Further, the similarity acquisition unit may include: a second target log acquisition unit, a first prompt information output unit, a second prompt information output unit, and a similarity acquisition subunit, wherein: The second target log acquisition unit is used to acquire the log information of the source branch as the second target log.

[0132] The first prompt information output unit is configured to output a first prompt information if, based on the first target log and the second target log, it is determined that there is an unmerged code version in the source branch that corresponds to the initial merge parameter and has not been merged into the destination branch. The first prompt information is used to prompt for input of a first flag, wherein the first flag is used to indicate that the verification of the unmerged code version is ignored.

[0133] The second prompt information output unit is used to output a second prompt information if it is determined from the first target log and the second target log that there is a target change code version in the merged branch that does not correspond to the source branch. The second prompt information is used to prompt for the input of a second flag, wherein the second flag is used to indicate that the verification of the target change code version is ignored.

[0134] The similarity acquisition subunit is used to acquire the similarity between the code version corresponding to the initial merging parameter and the modified code version based on the unmerged code version, the target modified code version, and the unique code version.

[0135] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the above-described device and module can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0136] In the several embodiments provided in this application, the coupling between modules can be electrical, mechanical, or other forms of coupling.

[0137] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0138] Please see Figure 11 This document illustrates a structural block diagram of an electronic device 100 provided in an embodiment of this application. The electronic device 100 can be a smartphone, tablet computer, e-reader, or other electronic device capable of running applications. The electronic device 100 in this application may include one or more of the following components: a processor 110, a memory 120, and one or more applications, wherein the one or more applications can be stored in the memory 120 and configured to be executed by one or more processors 110, and the one or more applications are configured to perform the methods described in the foregoing method embodiments.

[0139] The processor 110 may include one or more processing cores. The processor 110 connects to various parts within the electronic device 100 using various interfaces and lines, and performs various functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in the memory 120, and by calling data stored in the memory 120. Optionally, the processor 110 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 110 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content to be displayed; and the modem handles wireless communication. It is understood that the modem may also not be integrated into the processor 110 and may be implemented separately using a communication chip.

[0140] The processor 110 may include a Subversion (SVN) code version control system, an open-source version control system that, through the efficient management of a branch management system, can be used by multiple people to collaboratively develop the same project, achieving resource sharing and ultimately centralized management. As an open-source version control system, SVN manages data that changes over time. This data is stored in a central repository. SVN uses a client / server architecture; various versions of the project are stored on the server. Developers can obtain the latest version of the project from the server, copy it to their local machine, and then, based on this, each developer can perform independent development work on their own client and can commit new code to the server at any time; they can also obtain the latest code from the server through update operations, thus maintaining consistency with the versions used by other developers.

[0141] The memory 120 may include random access memory (RAM) or read-only memory (ROM). The memory 120 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 120 may include a program storage area and a data storage area. The program storage area may store instructions for implementing an operating system, instructions for implementing at least one function (such as touch functionality, sound playback functionality, image playback functionality, etc.), and instructions for implementing the various method embodiments described below. The data storage area may also store data created by the electronic device 100 during use (such as phonebook data, audio and video data, chat log data, etc.).

[0142] Please see Figure 12 This diagram illustrates a structural block diagram of a computer-readable storage medium provided in an embodiment of this application. The computer-readable medium 300 stores program code that can be invoked by a processor to execute the methods described in the above method embodiments.

[0143] The computer-readable storage medium 300 may be an electronic memory such as flash memory, EEPROM (Electrically Erasable Programmable Read-Only Memory), EPROM, hard disk, or ROM. Optionally, the computer-readable storage medium 300 includes a non-volatile computer-readable medium. The computer-readable storage medium 300 has storage space for program code 310 that performs any of the method steps described above. This program code can be read from or written to one or more computer program products. The program code 310 may be compressed, for example, in a suitable form.

[0144] In summary, the method, apparatus, electronic device, and storage medium for merging code repository branches provided in this application obtain command-line input parameters and configuration file parameters based on SVN; based on the command-line input parameters and configuration file parameters, initial merge parameters are obtained, wherein the initial merge parameters include the path of the target branch, the path of the source branch, and the source branch's code version merge parameters in the SVN-controlled code repository; based on the path of the target branch, the path of the source branch, and the source branch's code version merge parameters, the source branch is merged into the target branch via SVN to obtain a merged branch; log information of the merged branch is obtained as a first target log; based on the initial merge parameters and the first target log, a target verification report of the merged branch is obtained; and based on the target verification report, the merge result of merging the source branch in the code repository into the target branch based on SVN is determined. This application obtains initial merge parameters based on command-line and configuration file input from SVN, automatically merges branches in the code repository according to the initial merge parameters, and generates a branch merge verification report, thereby realizing automatic merging of branches in the code repository and reducing the cost of developing code repositories. In addition, the code repository is analyzed and audited based on the generated branch merging verification report, which improves the efficiency of code repository development.

[0145] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for merging code repository branches, characterized in that, Applied to electronic devices, including the code version control system SVN, the method includes: Based on the SVN, command line input parameters and configuration file parameters are obtained; Based on the command-line input parameters and the configuration file parameters, the initial merge parameters are obtained, wherein the initial merge parameters include the path of the destination branch, the path of the source branch, and the code version merge parameters of the source branch in the SVN-controlled code repository. Based on the path of the destination branch, the path of the source branch, and the code version merge parameter of the source branch, the source branch is merged into the destination branch through SVN to obtain a merged branch; Obtain the log information of the merged branch as the first target log; Based on the initial merge parameters and the first target log, obtain the target verification report of the merged branch; Based on the target verification report, determine the merging result of merging the source branch in the code repository into the target branch based on the SVN; The step of obtaining the target verification report of the merged branch based on the initial merge parameters and the first target log includes: Based on the first target log and the initial merge parameters, the changed code version of the target branch is obtained, and the ignore check flag corresponding to the target branch is obtained, wherein the ignore check flag is used to characterize the unique code version of the target branch; Based on the initial merge parameters, the changed code version, and the ignore check flag, a target verification report for the target branch is obtained; wherein, obtaining the target verification report for the target branch based on the initial merge parameters, the changed code version, and the ignore check flag includes: obtaining the similarity between the code version corresponding to the initial merge parameters and the changed code version based on the ignore check flag; if the similarity is greater than a similarity threshold, a first target verification report is generated, wherein the first target verification report is used to indicate that the code version verification of the merged branch has passed; or if the similarity is less than or equal to the similarity threshold, a second target verification report is generated, wherein the second target verification report is used to indicate that the code version verification of the merged branch has failed.

2. The method according to claim 1, characterized in that, The method of merging the source branch into the destination branch using SVN, based on the path of the destination branch, the path of the source branch, and the code version merge parameter of the source branch, to obtain a merged branch, includes: Based on the code version merge parameter of the source branch, a merge code version list of the source branch is obtained, wherein the merge code version list includes at least one merge code version; Based on the path of the source branch, at least one target merge code version is determined from the merge code list; The merged branch is obtained by merging at least one target code version into the target branch using the path of the target branch through SVN.

3. The method according to claim 2, characterized in that, The source branch code version merging parameter includes the starting code version and the ending code version of the source branch. Obtaining the merging code version list of the source branch based on the source branch code version merging parameter includes: Obtain the log information of the source branch as the initial log, wherein the initial log includes a first ignore merge flag corresponding to the code version in the source branch that is ignored from merging into the destination branch; Based on the first ignore merge flag, obtain the first ignore merge code version of the source branch; Based on the first ignored merge code version of the source branch, the starting code version of the source branch, and the ending code version of the source branch, a list of merge code versions of the source branch is obtained.

4. The method according to claim 2, characterized in that, The source branch code version merging parameter includes the starting code version and the ending code version of the source branch. Obtaining the merging code version list of the source branch based on the source branch code version merging parameter includes: From the command line input parameters, obtain the second ignore merge flag corresponding to the code version in the source branch that is ignored from merging into the destination branch; Based on the second ignore merge flag, obtain the second ignore merge code version of the source branch; Based on the second ignored merge code version of the source branch, the starting code version of the source branch, and the ending code version of the source branch, a list of merge code versions of the source branch is obtained.

5. The method according to claim 1, characterized in that, The step of obtaining the similarity between the code version corresponding to the initial merge parameter and the changed code version based on the ignored check flag includes: Obtain the log information of the source branch as the second target log; If, based on the first target log and the second target log, it is determined that there exists an unmerged code version in the source branch that corresponds to the initial merge parameter and has not been merged into the target branch, then a first prompt message is output, wherein the first prompt message is used to prompt for input of a first flag, wherein the first flag is used to indicate that the verification of the unmerged code version is ignored; If, based on the first target log and the second target log, it is determined that there is a target change code version in the merged branch that does not correspond to the source branch, then a second prompt message is output. The second prompt message is used to prompt for the input of a second flag, which is used to indicate that the verification of the target change code version is ignored. Based on the unmerged code version, the target modified code version, and the unique code version, the similarity between the code version corresponding to the initial merge parameter and the modified code version is obtained.

6. An apparatus for merging code repository branches, characterized in that, Applied to electronic devices, the electronic devices including the code version control system SVN, the device includes: The input parameter acquisition module is used to acquire command line input parameters and configuration file parameters based on the SVN. The initial merge parameter acquisition module is used to obtain the initial merge parameters based on the command line input parameters and the configuration file parameters. The initial merge parameters include the path of the destination branch, the path of the source branch, and the code version merge parameters of the source branch in the SVN-controlled code repository. The branch merge module is used to merge the source branch into the destination branch through SVN based on the path of the destination branch, the path of the source branch, and the code version merge parameter of the source branch, thereby obtaining a merged branch. The first target log acquisition module is used to acquire the log information of the merged branch as the first target log; The verification report acquisition module is used to obtain the target verification report of the merged branch based on the initial merge parameters and the first target log; The merge result determination module is used to determine the merge result of merging the source branch in the code repository into the destination branch based on the target verification report; The verification report acquisition module includes: an ignore check flag acquisition module and a verification report acquisition submodule; The ignore check flag acquisition module is used to obtain the changed code version of the target branch and the ignore check flag corresponding to the target branch based on the first target log and the initial merge parameters, wherein the ignore check flag is used to characterize the unique code version of the target branch; The verification report acquisition submodule is used to obtain the target verification report of the target branch based on the initial merge parameters, the changed code version, and the ignore check flag; wherein, the verification report acquisition submodule includes: a similarity acquisition unit and a first verification report acquisition unit, or a similarity acquisition unit and a second verification report acquisition unit; The similarity acquisition unit is used to acquire the similarity between the code version corresponding to the initial merge parameter and the changed code version based on the ignored check flag; the first verification report acquisition unit is used to generate a first target verification report if the similarity is greater than the similarity threshold, wherein the first target verification report is used to indicate that the code version of the merged branch has passed the verification. The second verification report obtaining unit is used to generate a second target verification report if the similarity is less than or equal to the similarity threshold, wherein the second target verification report is used to characterize that the code version verification of the merged branch fails.

7. An electronic device, characterized in that, include: One or more processors; Memory; One or more applications, wherein the one or more applications are stored in the memory and configured to be executed by the one or more processors, the one or more applications being configured to perform the method as described in any one of claims 1-5.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium contains program code that can be invoked by a processor to execute the method as described in any one of claims 1-5.

Images