A method and related apparatus for branch merging

Abstract

The application discloses a branch merging method and related device, in response to a first commit operation of a first branch to a version library, obtaining a first version file of the first commit operation, and a second branch associated with the first branch, determining branch merging content of to-be-merged content in the first version file according to an automatic merging strategy and a second version file corresponding to the first version file in the second branch, determining a merged version file corresponding to the first version file to the second branch according to the branch merging content corresponding to the to-be-merged content, and saving labor cost. If the branch merging content corresponding to target content in the first version file fails to be determined, a notification message corresponding to the target content is sent to a development account corresponding to the target content, branch merging content of the target content is determined according to a merging instruction of the development account for the target content, and the whole branch merging process is automatically performed, so that the branch merging efficiency is ensured and the branch merging accuracy is ensured.

Description

Technical Field

[0001] This application relates to the field of data processing, and in particular to a branch merging method and related apparatus. Background Technology

[0002] With the development of computer technology and the widespread use of various applications, the requirements for application functionality and performance are gradually increasing. To meet the actual needs of different users, applications need to be developed, upgraded, and updated. During application development, to improve development efficiency, a parallel development approach with multiple branches can be adopted. This method of splitting a project into multiple branches can help maintain team focus and improve branch stability. For example, in the development of game applications, especially content-based games, where players consume game content quickly, a parallel development approach with multiple branches is typically used.

[0003] However, in a multi-branch parallel development approach, there is a need to merge commits from one branch into other branches. Currently, this is usually done manually, which is labor-intensive, prone to errors, and has significant merge delays. Summary of the Invention

[0004] To address the aforementioned technical issues, this application provides a branch merging method and related apparatus, which realizes real-time automatic merging from a first branch to a second branch in response to a first commit operation. This ensures that modifications to the first branch are promptly reflected in the second branch. During the real-time automatic merging process, the branch merging content is determined as automatically as possible to avoid excessive manual intervention and save labor costs. If the branch merging content cannot be determined according to the automatic merging strategy, the content owner can be notified to assist in determining the branch merging content, thereby assisting the automatic merging process. The entire branch merging process is automated, ensuring both efficiency and accuracy in branch merging.

[0005] The embodiments of this application disclose the following technical solutions:

[0006] On the one hand, this application provides a branch merging method, the method comprising:

[0007] In response to the first commit operation to the repository from the first branch, obtain the first version file of the first commit operation, and the second branch associated with the first branch;

[0008] Based on the automatic merging strategy and the second version file of the second branch corresponding to the first version file, determine the branch merging content for the content to be merged in the first version file.

[0009] If the branch merging content corresponding to the target content in the first version file fails to be determined, a notification message corresponding to the target content is sent to the development account corresponding to the target content.

[0010] The branch merging content of the target content is determined according to the merging instruction of the development account for the target content;

[0011] Based on the branch merging content corresponding to the content to be merged, determine the merged version file corresponding to the first version file to the second branch.

[0012] Optionally, determining the branch merge content for the content to be merged in the first version file based on the automatic merge strategy and the second version file corresponding to the first version file in the second branch includes:

[0013] The common ancestor file of the first version file and the second version file is used as the base file;

[0014] Determine the source modification information of the first version file relative to the benchmark file, and the target modification information of the second version file relative to the benchmark file;

[0015] According to the automatic merging strategy, the source modification information and the target modification information are merged to obtain merged modification information. The content corresponding to the merged modification information in the first version file is used as the content to be merged, and the merged modification information is used as the branch merging content of the content to be merged.

[0016] The step of determining the merged version file corresponding to the second branch based on the branch merge content corresponding to the content to be merged includes:

[0017] Based on the branch merging content corresponding to the content to be merged and the baseline file, determine the merged version file corresponding to the first version file for the second branch.

[0018] Optionally, the first version file includes a first table file, the second version file includes a second table file corresponding to the first table file, and the base file includes a third table file corresponding to the first table file;

[0019] Determining the source modification information of the first version file relative to the benchmark file, and the target modification information of the second version file relative to the benchmark file, includes:

[0020] The source modification information is determined based on the first comparison results of the first table file and the third table file at multiple levels; the target modification information is determined based on the second comparison results of the second table file and the third table file at multiple levels; the multiple levels include file level, table level, row level, column level and cell level.

[0021] Optionally, the method further includes:

[0022] The first comparison result is determined based on the comparison results between the first table file and the third table file in terms of file identifier, table identifier, row header, column header, and cell content, respectively.

[0023] The second comparison result is determined based on the comparison results between the second table file and the third table file in terms of file identifier, table identifier, row header, column header, and cell content.

[0024] Optionally, the step of merging the source modification information and the target modification information according to the automatic merging strategy to obtain merged modification information includes:

[0025] According to the automatic merging strategy, if the i-th modification information in the source modification information is the same as the j-th modification information in the target modification information, then the merged modification information of the i-th modification information and the j-th modification information is determined based on the j-th modification information; where i and j are positive integers.

[0026] If there is no modification information in the target modification information that is consistent with the modification object of the i-th modification information, then the merged modification information of the i-th modification information is determined based on the i-th modification information;

[0027] If there is no modification information in the source modification information that is consistent with the modification object of the j-th modification information, then the merged modification information of the j-th modification information is determined based on the j-th modification information;

[0028] If the modified objects of the i-th modification information and the j-th modification information are the same, and the i-th modification information and the j-th modification information are different, then the merging of the i-th modification information is determined to have failed, and the merging of the branch content of the content to be merged corresponding to the i-th modification information is determined to have failed.

[0029] Optionally, the step of responding to a first commit operation to the repository from the first branch, obtaining the first version file of the first commit operation, and the second branch associated with the first branch, includes:

[0030] In response to the first commit operation of the first branch to the repository, a list to be merged is determined based on the first commit operation, and the list to be merged is used to record the merge operations of the second branch;

[0031] Sequentially retrieve the merge operations from the list of operations to be merged;

[0032] After retrieving the first commit from the list to be merged, retrieve the first version file of the first commit and the second branch associated with the first branch.

[0033] Optionally, before obtaining the first version file of the first commit operation and the second branch associated with the first branch in response to the first commit operation to the repository, the method further includes:

[0034] In response to the second commit operation, retrieve the third version file of the second commit operation;

[0035] If it is determined that the third version file has a locked file in the fourth version file corresponding to the second branch that is locked by the second branch, then a lock notification message is sent to the development account corresponding to the locked file.

[0036] The response to the first commit operation of the first branch to the repository, determining the list of branches to be merged based on the first commit operation, includes:

[0037] In response to the first commit operation of the first branch to the repository, the list of branches to be merged is determined based on the first commit operation and the second commit operation.

[0038] Optionally, the method further includes:

[0039] Before retrieving the first commit operation from the list to be merged, retrieve the second commit operation from the list to be merged;

[0040] After obtaining the merged version file corresponding to the third version file and pointing to the second branch, the third version file is used as the base file, and the merged version file corresponding to the third version file is used as the second version file.

[0041] Optionally, if the branch merging content corresponding to the target content in the first version file fails to be determined, a notification message corresponding to the target content is sent to the development account corresponding to the target content, including:

[0042] If the branch merging content corresponding to the target content in the first version file fails to be determined, an instant messaging group including the virtual robot and the development account corresponding to the target content is constructed.

[0043] The virtual robot sends a notification message corresponding to the target content in the instant messaging group.

[0044] Optionally, the step of responding to a first commit operation to the repository from the first branch, obtaining the first version file of the first commit operation, and the second branch associated with the first branch, includes:

[0045] In response to the first commit operation to the repository from the first branch, if the first commit operation corresponds to an auto-merge tag, then obtain the first version file of the first commit operation and the second branch associated with the first branch.

[0046] Optionally, the first branch and the second branch belong to the same development stage of the same project. The first branch is a stable branch or a development branch, and the second branch is a development trunk branch. Alternatively, the first branch is a feature branch or a release branch, and the second branch is a development branch.

[0047] Alternatively, the first branch and the second branch belong to different development stages of the same project, the second development stage to which the second branch belongs is after the first development stage to which the first branch belongs, the first branch is a development trunk branch or a stable branch, and the second branch is a development trunk branch.

[0048] On the other hand, this application provides a branch merging apparatus, the apparatus comprising:

[0049] A capture unit is configured to, in response to a first commit operation to the repository from a first branch, acquire a first version file of the first commit operation and a second branch associated with the first branch;

[0050] The merging unit is used to determine the branch merging content for the content to be merged in the first version file according to the automatic merging strategy and the second version file of the second branch corresponding to the first version file.

[0051] The first notification unit is used to send a notification message corresponding to the target content to the development account corresponding to the target content if the branch merging content corresponding to the target content in the first version file fails to be determined.

[0052] An instruction processing unit is configured to determine the branch merging content of the target content based on the merging instruction from the development account for the target content;

[0053] The version file determination unit is used to determine the merge version file corresponding to the first version file and the second branch based on the branch merge content corresponding to the content to be merged.

[0054] Optionally, the merging unit includes:

[0055] The benchmark file acquisition unit is used to take the common ancestor file of the first version file and the second version file as the benchmark file;

[0056] The modification determination unit is used to determine the source modification information of the first version file relative to the reference file, and the target modification information of the second version file relative to the reference file;

[0057] The merging subunit is used to merge the source modification information and the target modification information according to the automatic merging strategy to obtain merged modification information. The content corresponding to the merged modification information in the first version file is used as the content to be merged, and the merged modification information is used as the branch merging content of the content to be merged.

[0058] The version file determination unit is specifically used for:

[0059] Based on the branch merging content corresponding to the content to be merged and the baseline file, determine the merged version file corresponding to the first version file for the second branch.

[0060] Optionally, the first version file includes a first table file, the second version file includes a second table file corresponding to the first table file, and the base file includes a third table file corresponding to the first table file;

[0061] The modification determination unit is specifically used for:

[0062] The source modification information is determined based on the first comparison results of the first table file and the third table file at multiple levels; the target modification information is determined based on the second comparison results of the second table file and the third table file at multiple levels; the multiple levels include file level, table level, row level, column level and cell level.

[0063] Optionally, the device further includes:

[0064] The first comparison unit is used to determine the first comparison result based on the comparison results of the first table file and the third table file in terms of file identifier, table identifier, row header, column header and cell content, respectively;

[0065] The second comparison unit is used to determine the second comparison result based on the comparison results of the second table file and the third table file in terms of file identifier, table identifier, row header, column header and cell content, respectively.

[0066] Optionally, the merging subunit includes:

[0067] The first subunit is configured to, according to an automatic merging strategy, determine the merged modification information of the i-th modification information and the j-th modification information based on the j-th modification information if the i-th modification information in the source modification information and the j-th modification information are the same; where i and j are positive integers.

[0068] The second subunit is used to determine the merged modification information of the i-th modification information based on the i-th modification information if there is no modification information in the target modification information that is consistent with the modification object of the i-th modification information.

[0069] The third subunit is used to determine the merged modification information of the j-th modification information based on the j-th modification information if there is no modification information in the source modification information that is consistent with the modification object of the j-th modification information.

[0070] The fourth subunit is used to determine that the merging of the i-th modification information fails if the modification objects of the i-th modification information and the j-th modification information are the same, and the i-th modification information and the j-th modification information are different. The branch merging content of the content to be merged corresponding to the i-th modification information is determined to fail.

[0071] Optionally, the capture unit includes:

[0072] The list determination unit is used to determine a list to be merged based on the first commit operation of the first branch to the repository in response to the first commit operation. The list to be merged is used to record the merge operations of the second branch.

[0073] An operation acquisition unit is used to sequentially acquire the operations to be merged from the list to be merged;

[0074] The first information acquisition unit is used to acquire, after acquiring the first commit operation from the list to be merged, the first version file of the first commit operation and the second branch associated with the first branch.

[0075] Optionally, the device further includes:

[0076] The second information acquisition unit is used to acquire the third version file of the second commit operation in response to the second commit operation before acquiring the first version file of the first commit operation and the second branch associated with the first branch in response to the first commit operation to the repository.

[0077] The second notification unit is used to send a lock notification message to the development account corresponding to the lock file if it is determined that the third version file has a lock file locked by the second branch in the fourth version file corresponding to the second branch.

[0078] The list determination unit is specifically used for:

[0079] In response to the first commit operation of the first branch to the repository, the list of branches to be merged is determined based on the first commit operation and the second commit operation.

[0080] Optionally, the device further includes:

[0081] An operation acquisition subunit is used to acquire a second submission operation in the list to be merged before acquiring the first submission operation from the list to be merged.

[0082] The file update unit is used to obtain the merged version file corresponding to the third version file and then use the third version file as the base file and the merged version file corresponding to the third version file as the second version file.

[0083] Optionally, the first notification unit includes:

[0084] A group building unit is used to build an instant messaging group including a virtual robot and the development account corresponding to the target content if the branch merging content corresponding to the target content in the first version file fails to be determined.

[0085] A message sending unit is used to send a notification message corresponding to the target content in the instant messaging group through the virtual robot.

[0086] Optionally, the capture unit is specifically used for:

[0087] In response to the first commit operation to the repository from the first branch, if the first commit operation corresponds to an auto-merge tag, then obtain the first version file of the first commit operation and the second branch associated with the first branch.

[0088] Optionally, the first branch and the second branch belong to the same development stage of the same project. The first branch is a stable branch or a development branch, and the second branch is a development trunk branch. Alternatively, the first branch is a feature branch or a release branch, and the second branch is a development branch.

[0089] Alternatively, the first branch and the second branch belong to different development stages of the same project, the second development stage to which the second branch belongs is after the first development stage to which the first branch belongs, the first branch is a development trunk branch or a stable branch, and the second branch is a development trunk branch.

[0090] On the other hand, this application provides a computer device, the device including a processor and a memory:

[0091] The memory is used to store computer programs and to transfer the computer programs to the processor;

[0092] The processor is configured to execute the branch merging method described above according to instructions in the computer program.

[0093] On the other hand, embodiments of this application provide a computer-readable storage medium for storing a computer program for executing the branch merging method described above.

[0094] On the other hand, embodiments of this application provide a computer program product including a computer program, which, when run on a computer device, causes the computer device to execute the branch merging method described above.

[0095] As can be seen from the above technical solution, in response to the first commit operation to the repository from the first branch, the first version file of the first commit operation and the second branch associated with the first branch are obtained. According to the automatic merge strategy and the second version file in the second branch corresponding to the first version file, the branch merge content is determined for the content to be merged in the first version file. In this way, based on the branch merge content corresponding to the content to be merged, the merge version file corresponding to the first version file to the second branch is determined, realizing real-time automatic merging from the first branch to the second branch in response to the first commit operation. This ensures that the changes in the first branch can be reflected in the second branch in a timely manner, guaranteeing the synchronization of development. Moreover, since the automatic merge is triggered by the commit operation, no manual triggering and control is required, thus saving labor costs. Furthermore, the branch merge triggered by the commit operation has a high merging frequency, and the content to be merged in each merge process is small, with fewer unresolved conflicts, which is conducive to achieving efficient automatic merging. During the process of determining the branch merge content, if the branch merge content corresponding to the target content in the first version file fails to be determined, a notification message corresponding to the target content is sent to the development account corresponding to the target content. The branch merge content of the target content is determined according to the merge instructions of the development account for the target content. In this way, the branch merge content is determined as automatically as possible during the real-time automatic merge process, avoiding excessive manual intervention and saving labor costs. If the branch merge content cannot be determined according to the automatic merge strategy, the content owner can be notified to assist in determining the branch merge content, thereby assisting the automatic merge process. The entire branch merge process is automated, ensuring both the efficiency and accuracy of branch merge. Attached Figure Description

[0096] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the 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.

[0097] Figure 1 A schematic diagram illustrating an application scenario of a branch merging method provided in an embodiment of this application;

[0098] Figure 2 A flowchart of a branch merging method provided in an embodiment of this application;

[0099] Figure 3 This application provides a schematic diagram of a branch structure for multi-branch development.

[0100] Figure 4 This is a schematic diagram of the structure of an automatic merging tool provided in an embodiment of this application;

[0101] Figure 5 A flowchart illustrating another branch merging method provided in this application embodiment;

[0102] Figure 6 A flowchart illustrating yet another branch merging method provided in this application embodiment;

[0103] Figure 7 A schematic diagram of a notification interface provided in an embodiment of this application;

[0104] Figure 8 This application provides a schematic diagram of a version file merging status.

[0105] Figure 9 A schematic diagram illustrating an automatic merging process provided in an embodiment of this application;

[0106] Figure 10 A schematic diagram illustrating a multiple consecutive automatic merging process provided in an embodiment of this application;

[0107] Figure 11 This is a schematic diagram of source modification information provided in an embodiment of this application;

[0108] Figure 12 A schematic diagram for conflict determination provided in an embodiment of this application;

[0109] Figure 13 A schematic diagram of a conflict display page provided in an embodiment of this application;

[0110] Figure 14A structural block diagram of a branch merging device provided in an embodiment of this application;

[0111] Figure 15 A structural diagram of a terminal device provided in an embodiment of this application;

[0112] Figure 16 This is a structural diagram of a server provided in an embodiment of this application. Detailed Implementation

[0113] The embodiments of this application will now be described with reference to the accompanying drawings.

[0114] In multi-branch parallel development, there is a need to merge commits from one branch into other branches. Currently, this is usually done manually, which is labor-intensive, prone to errors, and has significant merge delays.

[0115] To address the aforementioned technical issues, this application provides a branch merging method and related apparatus, which realizes real-time automatic merging from a first branch to a second branch in response to a first commit operation. This ensures that modifications to the first branch are promptly reflected in the second branch. During the real-time automatic merging process, the branch merging content is determined as automatically as possible to avoid excessive manual intervention and save labor costs. If the branch merging content cannot be determined according to the automatic merging strategy, the content owner can be notified to assist in determining the branch merging content, thereby assisting the automatic merging process. The entire branch merging process is automated, ensuring both efficiency and accuracy in branch merging.

[0116] The branch merging method provided in this application can be implemented using a computer device, which can be a terminal device or a server. The server can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services. Terminal devices include, but are not limited to, mobile phones, computers, intelligent voice interaction devices, smart home appliances, vehicle terminals, and aircraft. The terminal devices and servers can be directly or indirectly connected via wired or wireless communication, and this application does not impose any limitations on this connection.

[0117] To facilitate understanding of the technical solutions provided in this application, the following section will introduce a branch merging method provided in an embodiment of this application, in conjunction with a practical application scenario.

[0118] Figure 1This illustration shows an application scenario of a branch merging method provided in an embodiment of this application. The scenario includes a server 10 and a terminal device 20. The terminal device 20 has an application installed for logging into a development account. The server 10 and terminal device 20 interact via a network. The server 10 or terminal device 20 can function as a computer device to execute the branch merging method. The terminal device 20 interacts with the user, receiving notification messages and generating merge instructions when logging into the development account. The following description uses the server 10 as an example of the aforementioned computer device.

[0119] In response to the first commit operation to the repository from the first branch, server 10 obtains the first version file of the first commit operation and the second branch associated with the first branch. Based on the automatic merge strategy and the second version file in the second branch corresponding to the first version file, it determines the branch merge content for the content to be merged in the first version file. In this way, based on the branch merge content corresponding to the content to be merged, the merge version file corresponding to the first version file to the second branch is determined, realizing real-time automatic merging from the first branch to the second branch in response to the first commit operation. This ensures that changes on the first branch can be reflected in the second branch in a timely manner, guaranteeing the synchronization of development. Moreover, since automatic merging is triggered by the commit operation, no manual triggering and control is required, thus saving labor costs. Furthermore, the merging frequency of branch merging triggered by the commit operation is high, the content to be merged in each merging process is small, and the number of unresolved conflicts is small, which is conducive to achieving efficient automatic merging.

[0120] During the process of determining the branch merge content, if the branch merge content corresponding to the target content in the first version file fails to be determined, a notification message corresponding to the target content is sent to the development account corresponding to the target content. The branch merge content of the target content is determined according to the merge instructions of the development account for the target content. In this way, the branch merge content is determined as automatically as possible during the real-time automatic merge process, avoiding excessive manual intervention and saving labor costs. If the branch merge content cannot be determined according to the automatic merge strategy, the content owner can be notified to assist in determining the branch merge content, thereby assisting the automatic merge process. The entire branch merge process is automated, ensuring both the efficiency and accuracy of branch merge.

[0121] Figure 2 This application provides a flowchart of a branch merging method, in which a server is used as the aforementioned computer device for illustration. The branch merging method may include:

[0122] S101, in response to the first commit operation of the first branch to the repository, retrieves the first version file of the first commit operation, and the second branch associated with the first branch.

[0123] To improve development efficiency during application development, a parallel development approach with multiple branches can be adopted. This method of splitting a project into multiple branches helps maintain team focus and improves branch stability. For example, in the development of game applications, especially content-driven games, where players consume game content quickly, a parallel development approach with multiple branches is typically used.

[0124] Different branches within a project can correspond to different functionalities. Multiple branches can include the main development branch, development branches, stable branches, feature branches, and release branches. The main development branch (also called the main, master, or trunk branch) serves as the core branch of the entire project. It can create development branches (development or dev branches) and stable branches (Stable branches). Development branches are used for daily project development, while stable branches are used for maintaining and fixing urgent issues in released versions. Resources from development and stable branches can be merged into the core branch, and resources from stable branches can be merged into development branches. Development branches can spawn feature branches for developing new features; once feature branch development is complete, resources are merged into the development branch. Development branches can also spawn release branches (release or rel branches) for preparing for new version releases.

[0125] Different branches can also correspond to different development stages, see reference. Figure 3The diagram illustrates a branch structure for multi-branch development according to an embodiment of this application. Multiple development stages, from front to back, include an archiving stage, an operation stage, a canary testing stage, a subsequent development stage, and other development stages. The archiving stage may include a main branch, a stable branch, and a release branch, corresponding to the three version files trunk_1.0, stable_1.0, and release_1.0, respectively. The operation stage may include a main branch, a stable branch, and a release branch, corresponding to the three version files trunk_1.1, stable_1.1, and release_1.1, respectively. The canary testing stage may include a main branch, a stable branch, and a release branch, corresponding to the three version files trunk_1.2, stable_1.2, and release_1.2, respectively. The subsequent development stage may include a main branch and a stable branch, corresponding to the two version files trunk_1.3 and stable_1.3, respectively. Other development stages may only include their respective main branches, corresponding to version files trunk_1.4, trunk_1.5, etc. The team's daily development takes place on the main development branch and the development branches they create. When a release is needed, they pull the stable branch and the release branch. Subsequent development stages and other development stages' branches can be used to create and develop content that meets requirements such as confidentiality and stability, such as new scenes or new gameplay.

[0126] During development, the content of the main development branch within the same phase can be copied to the stable branch at regular intervals (e.g., a season). After the stable branch verifies the content, it is then copied to the release branch for deployment. (See reference...) Figure 3 As shown. During development, development can also be carried out on a stable branch at certain intervals (e.g., weekly). The content of the stable branch can be merged into the main branch of the current development stage, and can also be merged into the main branch of the development stage in subsequent stages. This merging can be achieved through automatic merging (automerge). See reference... Figure 3 As shown. If there is an urgent need to fix a critical bug, this can be done on the stable branch. After testing, it can be merged into the release branch. This merging can be done automatically or manually. See the reference section. Figure 3 As shown. For urgent bug fixes, modifications and commits can be made on the development main branch in the official manner, and then overwritten on the stable branch. After the stable branch verifies the content, it is overwritten on the release branch for release.

[0127] Among multiple branches, branches where development has stopped can be archived. After being released via a release branch, the development trunk branch can also be archived, at which point it can access and archive changes from the stable branch. During development, the content of stable and release branches can be publicly available, making it usable by other branches. Before being released via a release branch, the development trunk branch can be in full development mode, accessing and sharing content from other development trunk branches and stable branches. Development trunk branches at other development stages can be partially active, accessing content from other development trunk branches and stable branches for continued development.

[0128] During the data flow described above, the content submitted on the first branch can be automatically merged into the second branch. The second branch is associated with the first branch and is the branch that requires modifications from the first branch; that is, the modifications from the first branch need to be merged into the second branch. When the first and second branches are in the same development stage of the same project, the first branch can be a development branch or a stable branch, and the second branch can be a development trunk branch, thus automatically merging the stable branch or development branch into the development trunk branch. Alternatively, the first branch can be a feature branch or a release branch, and the second branch can be a development branch, thus automatically merging the feature branch or release branch into the development branch. When the first and second branches are in different development stages, the first branch can be a development trunk branch or a stable branch, and the second branch can be a development trunk branch. The second development stage to which the second branch belongs is after the first development stage to which the first branch belongs, thus automatically transferring the modifications from the preceding branch to the subsequent branch. The first and second development stages can be one of the following: archiving stage, operation stage, gray-scale testing stage, and subsequent development stage.

[0129] As an example, see reference Figure 3 As shown, when the stable branch in the operation phase is the first branch, the first version file stable_1.1 can be merged into the main development branch in the operation phase, as well as the main development branch in the canary testing phase; both can be used as the second branch. When the stable branch in the canary testing phase is the first branch, the first version file stable_1.2 can be merged into the main development branch in the canary testing phase, as well as the main development branch in subsequent development phases; both can be used as the second branch. When the stable branch in subsequent development phases is the first branch, the first version file stable_1.3 can be merged into the main development branch in subsequent development phases, as well as the main development branches in other development phases; both can be used as the second branch. When the main development branch in other development phases is the first branch, the first version file trunk_1.3 can be merged into the main development branch in subsequent development phases (as the second branch).

[0130] Currently, the most basic method in the industry is manual synchronization by the committer or a team member skilled in version control software, or by using tools such as Perforce and Git for limited automation in batches according to certain rules. However, manual merging requires continuous human involvement in the entire change flow, resulting in low merging efficiency. When there are many branches to maintain, the workload of merging increases exponentially. Moreover, manual operation during the merging process greatly increases the probability of errors, such as missed merges or duplicate commits. In addition, both manual and batch merging have significant merging delays. Merging delays not only prevent subsequent versions from receiving the latest changes quickly but also increase the probability of other merge conflicts, leading to increased merging costs.

[0131] In this embodiment, the automatic merging process can be triggered by the first commit operation from the first branch to the repository. In response to the first commit operation, the first version file of the first commit operation and the second branch associated with the first branch can be obtained, thereby automatically merging the first version file into the second branch. This allows for immediate merging for each modification commit, solving the problem of merge delay. At the same time, the automatic merging tool (auto_merge) achieves automated merging, eliminating the manpower consumption of manual merging.

[0132] refer to Figure 4 The diagram shown is a structural schematic of an automatic merging tool provided in an embodiment of this application. The automatic merging tool may include a trigger and an automatic merging service. The trigger is used to obtain a first commit operation, and then trigger the automatic synchronization service to perform automatic merging. The automatic merging service controls the automatic merging process without manual control.

[0133] In this embodiment, an auto-merge tag can also be set for the first commit operation. In response to the first commit operation from the first branch to the repository, if the first commit operation has an auto-merge tag, the first version file and the second branch are obtained for automatic synchronization of the first version file. If the first commit operation does not have an auto-merge tag, the first version file can be automatically merged, and the first version file and the second branch can be not obtained. In this way, the content that needs to be automatically merged can be automatically identified according to the configuration of the auto-merge tag, and the commit operations that do not need to be merged can be filtered out, thereby realizing various customized needs.

[0134] In this embodiment of the application, a list to be merged can also be determined. This list is used to record the merging operations of the second branch. Thus, referring to... Figure 5The flowchart shown is another branch merging method provided in this application embodiment. S101 may include: S1011, in response to the first commit operation of the first branch to the repository, a list to be merged can be determined according to the first commit operation; S1012, the operations to be merged in the list to be merged are obtained in sequence, so as to realize the automatic merging of each operation to be merged in sequence; S1013, after obtaining the first commit operation from the list to be merged, the first version file of the first commit operation and the second branch associated with the first branch are obtained. The order of obtaining the operations to be merged in the list to be merged can be determined according to the commit time order, so as to automatically merge them in sequence according to the modification time.

[0135] The merge list can also include other commits besides the first commit, which serve as the mergeable entries for the second branch. These other commits are typically those that failed to merge before the first commit. Failed merges could be due to file locking preventing automatic merging, or unresolved conflicts preventing automatic merging. Of course, if the first commit fails to merge, it can also be added to the merge list to await subsequent commits that trigger the merge process, thus enabling the first commit to be merged.

[0136] When the file is locked, take the second commit operation as an example, refer to... Figure 6 The diagram shows a flowchart of another branch merging method provided in this application embodiment. The method further includes: S201, in response to the second commit operation, the third version file of the second commit operation can be obtained; S202, if it is determined that the fourth version file corresponding to the second branch has a locked file locked by the second branch, then S203, a lock notification message can be sent to the development account corresponding to the locked file so that the staff of the development account can unlock the locked file according to the lock notification message.

[0137] Since the merging process requires waiting for the locked files to unlock before proceeding, sending the lock notification message can be considered the end of the merge process. The merge will then proceed based on subsequent commits. Specifically, in response to the first commit from the first branch to the repository, the list of branches to be merged can be determined based on the first and second commits. This allows for automatic merging of the second commit before the first commit, once the automatic merge process triggered by the first commit begins. For example, see [reference needed]. Figure 6 As shown, before S1013, it may include S301, after obtaining the second commit operation from the list to be merged, obtaining the merge version corresponding to the third version file of the second commit operation to the second branch, that is, performing the automatic merge of the second commit operation. The automatic merge process of the second commit operation can refer to the automatic merge process of the first commit operation.

[0138] If a file is locked, taking the first commit as an example, after obtaining the first version file, S101 may further include: S1014, if it is determined that the second version file corresponding to the first version file in the second branch has a locked file that is locked by the second branch, then S1015, send a lock notification message to the development account corresponding to the locked file so that the staff of the development account can unlock the locked file according to the lock notification message, and then end the merge process, waiting for the next trigger of the merge process to execute the automatic merge corresponding to this commit operation. Alternatively, if the second version file does not have a locked file locked by the second branch, then S102 can be executed to perform an automatic merge.

[0139] The lock notification message can be an instant messaging (IM) message. If a locked file exists, an IM group is created, including a virtual bot and the development account corresponding to the locked file. The virtual bot then sends the lock notification message for the locked file to this IM group. This gives the automatic merging tool automated message notification capabilities. When a locked file is encountered, it automatically identifies the development account and adds a group notification, facilitating the rapid unlocking of locked files, avoiding sending delays, and improving the efficiency of automatic merging.

[0140] refer to Figure 7 The diagram shown is a schematic of a notification interface provided in an embodiment of this application. The notification interface 11 includes relevant content of an instant messaging group. For example, the name of the instant messaging group can be "Automatic Merge Task Blocking Processing," and the name of the virtual robot can be "auto_merge." The notification interface 11 includes the identifier 111 of the virtual robot and a chat bubble 112 for a lock notification message. The lock notification message can include a lock instruction statement and other valid information such as a merge view link. By triggering the merge view link, a file unlock interface can be displayed, thereby unlocking the file.

[0141] After the file is unlocked, the user can manually execute the merge task to generate a merge task execution instruction, or they can choose not to manually execute the merge task and wait for the next commit operation to automatically trigger the merge task. If a merge task execution instruction is obtained, it can be checked again to see if the unlocked file exists (S202 or S1014). If not, subsequent operations can be executed automatically.

[0142] In practice, since multiple commit operations are executed sequentially, if an earlier commit fails to merge, a later commit will also typically fail. Therefore, the earliest failed commit can be used as the anchor commit. When determining the list to be merged, this list can include all commit operations from the anchor commit to the latest commit. Each commit operation corresponds to a changelist, so the list to be merged can also include the changelists corresponding to each commit operation—that is, all changelists from the anchor changelist (the changelist corresponding to the anchor commit) to the latest changelist (the changelist corresponding to the latest commit).

[0143] S102, based on the automatic merging strategy and the second version file corresponding to the first version file in the second branch, determine the branch merging content for the content to be merged in the first version file.

[0144] In this embodiment, the second branch may have a second version file corresponding to the first version file. The first version file is usually a file modified by the first branch and is not completely identical to the second version file. Therefore, the first version file and the second version file can be merged according to an automatic merging strategy. Specifically, the branch merging content can be determined for the content to be merged in the first version file, and the branch merging content is the merged content corresponding to the content to be merged. (See reference...) Figure 4 As shown, the process of determining the content to be merged in a branch can be implemented by an automatic merge service.

[0145] refer to Figure 8 The diagram shown is a schematic diagram of a version file merging state provided in an embodiment of this application. The same group of files can be modified multiple times to obtain multiple version files (referred to as #2, #3, #4 and #5 respectively). Multiple version files can be merged into the second branch in sequence. The merging results of multiple version files can be recorded. For example, #2 and #3 have been successfully merged into the second branch, while #4 has not yet been successfully merged into the second branch.

[0146] The first version file is a group of files, which may include one or more files. The content to be merged can be one or more contents from the first version file. The second version file may also include one or more files. Multiple first version files can be independent of each other, and multiple second version files can also be independent of each other, thus allowing each file to be merged independently.

[0147] Specifically, the content to be merged can be determined based on the comparison results between the first and second version files. In this case, the content to be merged can be the content in the first version file, and the branch merge content is the merge result corresponding to the content to be merged. The content to be merged can include content in the first version file that corresponds to and is the same as that in the second version file, as well as content in the first version file that corresponds to and is different from that in the second version file. For content that corresponds to and is the same, simply keep the original content in either the first or second version file. For content that corresponds to and is different, comparison is needed to determine the branch merge content. Alternatively, the content to be merged can only include content in the first version file that corresponds to and is different from that in the second version file. In this case, the content that corresponds to and is the same does not need to be merged, and the original content in the second version file can be kept.

[0148] Specifically, the content to be merged can be determined based on the comparison results between the first version file and the base file, as well as the comparison results between the second version file and the base file. In this case, the content to be merged can be the content in the first version file, and the branch merge content is the modification information corresponding to the content to be merged. In practice, the common ancestor file of the first version file (denoted as theirs or TheirsFile) and the second version file (denoted as yours or YoursFile) can be obtained first as the base file (denoted as base or BaseFile). The base file can be obtained before or after the first version file. The common ancestor file is the version file corresponding to the first version file after merging and copying the first branch and the second branch. Then, the source modification information (TheirsChange) of the first version file relative to the base file and the target modification information (YoursChange) of the second version file relative to the base file are determined. Then, according to the automatic merge strategy, the source modification information and the target modification information are merged to obtain the merged modification information (MergedChange). The content corresponding to the merged modification information in the first version file is used as the content to be merged, and the merged modification information is used as the branch merge content of the content to be merged, so that automatic merging can be performed later based on the branch merge content. This process involves the participation of the first version file, the second version file, and the baseline file, which can be called a three-way merge, serving as the minimum process for handling changes to a single node.

[0149] refer to Figure 9The diagram shown illustrates an automatic merging process according to an embodiment of this application. The automatic merging process may include: S11, obtaining a base file; S12, obtaining a first version file, which can be implemented in S101; S13, determining the source modification information of the first version file relative to the base file; S14, obtaining a second version file; S15, determining the target modification information of the second version file relative to the base file; S16, merging the source modification information and the target modification information according to the automatic merging strategy to obtain merged modification information, which is used as the branch merging content; S19, determining the merged version file (MergedFile) (corresponding to the subsequent S105).

[0150] In process S16, if the source modification information and target modification information are inconsistent in S17, then in S18, the merge modification information is determined automatically or manually. If the automatic method cannot determine the information, the manual method is initiated. The automatic method includes implementation based on the automatic merge strategy, while the manual method is implemented in subsequent S103 and S104. If the content of the branch to be merged is determined, the merged version file can be determined based on the branch merge content (corresponding to subsequent S105). If the source modification information and target modification information are consistent, the merged version file can be determined based on the second version file.

[0151] If the second commit fails to merge, the list to be merged will include both the second and first commits. Since the second commit occurred before the first commit, it can be retrieved before the first commit. After retrieving the merged version file corresponding to the third version file of the second commit, the third version file is used as the base file, and the merged version file corresponding to the third version file is used as the second version file. In other words, the same file can undergo multiple changes through the first and second commits. Faced with these multiple change nodes (first and second commits), the algorithm can automatically merge them sequentially. These multiple changes usually have dependencies, meaning subsequent automatic merges must rely on the results of previous automatic merges and cannot skip these dependencies. Based on this, in multiple consecutive automatic merge processes, the files stored in the workspace of the second branch are not necessarily the latest version files. This is because the initial automatic merge process relies on the files stored in the workspace of the second branch (yours, i.e., the second version files used in this automatic merge). The merged version file obtained in this automatic merge is the latest version file of the second branch that has just been synchronized, compared to the second version file in this merge. Therefore, it can be used as the second version file for the next merge, and thus as the input for the next automatic synchronization. In other words, the merged version file obtained in the previous merge can be used as the second version file for the next merge, thereby achieving sequential merging.

[0152] refer to Figure 10 The diagram shown illustrates a multi-step automatic merging process provided in an embodiment of this application. The #1 version file stored in the workspace of the second branch is obtained by merging the #2 version file of the first branch. Therefore, the #2 version file of the first branch can be used as the base file (denoted as base1) for both.

[0153] During the first merge, the third version file (theirs1) of the second commit operation is the first branch #3 version file. The second branch modifies the second branch #1 version file to obtain the second branch #2 version file, which is the second branch's fourth version file (yours1) corresponding to the third version file. The third version file and the fourth version file are merged (merge1) to obtain the merged version file corresponding to the third version file in the second branch, which is used as the second version file for the next merge (denoted as yourrs2).

[0154] During the second merge, the third version file is used as the new base file (denoted as base2), the first version file of the first commit (theirs2) is the first branch #4 version file, and the merged version file obtained from the previous merge is used as the second version file (denoted as yours2). The first version file and the second version file are merged (merge2) to obtain the merged version file corresponding to the first version file to the second branch, which can be stored in the second branch as the second branch #3 version file.

[0155] This automatic merging mechanism, as described above, resolves conflicts arising from inconsistencies between source and target modifications using an automatic merging strategy. This determines the branch to be merged. The automatic merging strategy can be configured based on specific needs or be an existing setting in the version control system. For example, different parameters of the `p4resolve` command in Perforce version control software can be used to resolve conflicts case-by-case, thus addressing non-content-related conflicts.

[0156] In this embodiment of the application, the first version file may include at least one type of file such as text or table. Text files are easier to determine the branch content to be merged through an automatic merging strategy. For table files, no conflict resolution method is currently provided.

[0157] In this embodiment, for a table file, if a first version file includes a first table file, a second version file includes a second table file corresponding to the first table file, and a base file includes a third table file corresponding to the first table file, then the source modification information can be determined based on the first comparison results of the first and third table files at multiple levels, and the target modification information can be determined based on the second comparison results of the second and third table files at multiple levels. These multiple levels include file (Excel) level, table (sheet) level, row level, column level, and cell level, etc. In this way, the source and target modification information of the table file can be determined. The source and target modification information of the table can be determined using an Excel diff tool, thereby achieving automatic merging of table files and thus providing a stronger conflict resolution capability.

[0158] Multiple hierarchical levels correspond to different scopes. For example, the file level scope is the entire Excel file, the table level scope is the entire sheet, the row level scope is the entire row, the column level scope is the entire column, and the cell level scope is the entire cell. Scope can be represented by a domain identifier (UUID). These different scopes at multiple levels form a tree structure from largest to smallest, enabling the parsing of the table's tree structure. Both source and target modification information include the object being modified, the modification operation, and the content being modified. Modification operations include add (ADD), delete (REMOVE), and update (UPDATE), and the content being modified includes the added, deleted, and updated content corresponding to the respective modification operations.

[0159] Specifically, file-level comparison results are used to indicate differences at the file level, such as adding or deleting files; table-level comparison results are used to indicate differences at the table level, such as adding or deleting tables; row-level comparison results are used to indicate differences at the row level, such as adding or deleting rows; column-level comparison results are used to indicate differences at the column level, such as adding or deleting columns; and cell-level comparison results are used to indicate differences at the cell level, such as updating content.

[0160] Specifically, the first comparison result can be determined based on the comparison results between the first table file and the third table file in terms of file identifier, table identifier, row header, column header, and cell content; the second comparison result can be determined based on the comparison results between the second table file and the third table file in terms of file identifier, table identifier, row header, column header, and cell content.

[0161] Specifically, during the comparison of the first and third table files, the comparison results of the file identifiers can be used to determine whether there are any file-level deletion or addition operations in the first table file relative to the third table file, thereby determining the source modification information at the file level. Then, for two table files with the same file identifier in the first and third table files, the table identifiers can be used to determine whether there are any table-level deletion or addition operations in the first table file relative to the table in the third table file, thereby determining the source modification information at the table level. Then, for two tables with the same table identifier in the two table files with the same file identifier, the row headers, column headers, and cell contents can be used to determine whether there are any row-level deletion or addition operations, column-level deletion or addition operations, and cell content update operations in the first table file relative to the table in the third table file.

[0162] Accordingly, during the comparison of the second and third table files, the comparison results of the file identifiers can be used to determine whether there are any deletion or addition operations at the file level in the second table file relative to the third table file, thereby determining the source modification information at the file level. Then, for two table files with the same file identifier in the second and third table files, the table identifiers can be used to determine whether there are any deletion or addition operations at the table level in the second table file relative to the table in the third table file, thereby determining the source modification information at the table level. Then, for two tables with the same table identifier in the two table files with the same file identifier, the row headers, column headers, and cell contents can be used to determine whether there are any deletion or addition operations at the row level, deletion or addition operations at the column level, and updates to cell contents in the table in the second table file relative to the table in the third table file.

[0163] refer to Figure 11 The diagram illustrates a source modification information provided in an embodiment of this application. When the first table file includes Excel1, there is no source modification information at the file level. Excel1 includes two sheets, Sheet1. The source modification information at the table level includes deleting Sheet2 so that Excel1 does not contain Sheet2. Sheet1 in the first table file includes three rows, row1-row3, and two columns, col1 and col2. The source modification information at the row level includes deleting row4. There is no source modification information at the column level. The cells corresponding to row3 and col2 in Sheet1 of the first table are updated, and the updated content is 32.

[0164] When Excel1 is used as the third spreadsheet file and Excel2 is used as the first spreadsheet file, the first spreadsheet file does not have source modification information at the file level. Excel2 includes two spreadsheets, Sheet1 and Sheet3, and its source modification information at the table level is the addition of Sheet3. Sheet1 in the second spreadsheet includes four rows, row1-row3 and row5, and two columns, col1 and col2. The source modification information at the row level includes the addition of row5, but there is no source modification information at the column level. The cells corresponding to row3 and col2 in Sheet1 of the first spreadsheet have been updated, and the updated content is 321.

[0165] In this embodiment of the application, for a table file, during the process of merging source modification information and target modification information to obtain merged modification information according to the automatic merging strategy, if the i-th modification information in the source modification information (hereinafter referred to as the i-th modification information) and the j-th modification information in the target modification information (hereinafter referred to as the j-th modification information) are consistent, then the merged modification information of the i-th modification information and the j-th modification information is determined based on the j-th modification information, where i and j are both positive integers, for example, the j-th modification information is used as the merged modification information.

[0166] If the target modification information does not contain any modification information that matches the modification object of the i-th modification information in the source modification information, that is, the modification object only has the i-th modification information modified, then the merged modification information of the i-th modification information is determined based on the i-th modification information, for example, the i-th modification information is used as the merged modification information; if the source modification information does not contain any modification information that matches the modification object of the j-th modification information in the target modification information, that is, the modification object only has the j-th modification information modified, then the merged modification information of the j-th modification information is determined based on the j-th modification information, for example, the j-th modification information is used as the merged modification information.

[0167] If the i-th modification in the source modification information and the j-th modification in the target modification information have the same modification object but are different, it indicates that there is a content conflict between them. Therefore, the merging of the i-th modification information fails, and the branch merging content corresponding to the i-th modification information fails to be determined. That is, the branch merging content cannot be determined according to the automatic merging strategy.

[0168] The i-th modification and the j-th modification are considered identical if the modification object, modification operation, and modification content are all the same. For example, both might delete the same row (in which case the modification object is that row, and the modification content is empty), or both might change the content of a cell to the same value. Conversely, if the i-th modification in the source modification information and the j-th modification in the target modification information have the same modification object but are different (i.e., the modification operation or modification content is inconsistent), then a content conflict is considered, and automatic merging fails.

[0169] refer to Figure 12 The diagram illustrates a conflict determination method provided in this application. If the modification objects of the i-th and j-th modification information are the same (both are add operations) and the added content is the same, then the modification information is determined to be merged based on the j-th modification information. If the added content is different, then there is a content conflict. If the modification objects of the i-th and j-th modification information are the same (both are update operations) and the updated content is the same, then the modification information is determined to be merged based on the j-th modification information. If the updated content is different, then there is a content conflict. If the modification objects of the i-th and j-th modification information are the same, but the modification operations are different (e.g., delete and update operations respectively), then there is a content conflict. If the modification objects of the i-th and j-th modification information are the same and both are delete operations, then the modification information is determined to be merged based on the j-th modification information.

[0170] This facilitates determining the merged version file for the second branch based on the branch content corresponding to the content to be merged. It enables real-time automatic merging from the first branch to the second branch in response to the first commit operation, ensuring that changes on the first branch are promptly reflected in the second branch. Furthermore, since automatic merging is triggered by commit operations, it eliminates the need for manual intervention, thus saving labor costs. Additionally, branch merging triggered by commit operations has a high merging frequency, with fewer contents to be merged in each merging process and fewer unresolved conflicts, which is conducive to achieving efficient automatic merging.

[0171] S103, if the branch merging content corresponding to the target content in the first version file fails to be determined, a notification message corresponding to the target content is sent to the development account corresponding to the target content.

[0172] In this embodiment, the branch merging content is determined according to an automatic merging strategy during the process of determining the branch merging content. This ensures that the branch merging content is determined automatically as much as possible during the real-time automatic merging process, avoiding excessive manual intervention and saving labor costs. If the branch merging content corresponding to the target content in the first version file fails to be determined, it means that the branch merging content corresponding to the target content cannot be determined according to the automatic merging strategy. To avoid errors in determining the branch merging content, manual intervention is often required. A notification message corresponding to the target content can be sent to the development account corresponding to the target content so that the content owner can assist in determining the branch merging content, thereby assisting the automatic merging process and ensuring both the efficiency and accuracy of branch merging.

[0173] refer to Figure 4 As shown, the automatic merging tool may also include a conflict handling module, through which notification messages can be sent.

[0174] Specifically, the notification message can be an instant messaging message. If the branch merging content corresponding to the target content in the first version file fails to be determined, an instant messaging group is created, including a virtual robot and the development account corresponding to the target content. The virtual robot then sends the notification message corresponding to the target content to the instant messaging group. This gives the automatic merging tool automated message notification capabilities. When encountering conflicts that the tool cannot resolve automatically, it automatically identifies the development account and creates a group notification, facilitating the rapid resolution of related issues. Instant messaging allows for quick sending of notification messages to the development account corresponding to the target content, avoiding information delivery delays and improving the efficiency of automatic merging.

[0175] The notification message may include a statement indicating that the merge failed, as well as other useful information such as a link to view the merge status. Triggering the link will display a conflict display page. This notification message can be referenced. Figure 7 The diagram of the lock notification message is not described in detail here.

[0176] refer to Figure 13The diagram shows a conflict display page according to an embodiment of this application. The conflict display page 12 can display source modification information 121 corresponding to the target content. Source modification information 121 includes a location identifier and modification content. The modification content also indicates modification operations. The location identifier can be, for example, a table field identifier. The diagram uses table identifiers "170205", "170206", and "170210" as examples. The conflict display page 12 can also display a selection control 123 corresponding to the source modification information. Selecting the selection control 123 generates a merge instruction to retain the source modification information. Alternatively, not selecting the selection control 123 or selecting the selection control (not shown) corresponding to the target modification information generates a merge instruction to not retain the source modification information. The conflict display page 12 can also display merged modification information 122, essentially a preview of the merge result.

[0177] The conflict display page 12 can also display a conflict resolution control 124, which is labeled "marked as resolved". When the conflict resolution control 124 is triggered, it means that the conflict is being marked as resolved, that is, the conflict resolution is completed and there are no conflicts in the merging process of the first version file. At this time, a merge instruction can be generated according to the selection status of the selection control 123, and then the automatic merge tool can automatically continue the merging process according to the merge instruction.

[0178] S104, determine the branch to be merged based on the merge instructions for the target content from the development account.

[0179] In this embodiment of the application, the merge instruction for the target content in the development account is used to indicate whether the modification corresponding to the target content is retained in the second branch. Therefore, the branch merge content of the target content can be determined according to the merge instruction. If the modification corresponding to the target content is retained in the second branch, the branch merge content of the target content is the target content. If the modification corresponding to the target content is not retained in the second branch, the branch merge content of the target content is the content in the second version file corresponding to the target content.

[0180] refer to Figure 4 As shown, the automatic merging tool can also include a manual processing workflow management module. The determination of the branch merging content of the target content can be achieved through the manual processing workflow management module. The branch merging content obtained by the manual processing workflow management module can be merged into the automatic merging service to continue the automatic merging process.

[0181] S105, based on the branch merge content corresponding to the content to be merged, determine the merge version file corresponding to the first version file to the second branch.

[0182] After determining the branch to be merged, the merged version file corresponding to the first version file can be determined based on the branch to be merged content. The merged version file is then transferred to the second branch, thus merging the first version file into the second branch.

[0183] In the process of determining the merge version file based on the branch merge content corresponding to the content to be merged, if the branch merge content is merge modification information, the merge version file of the first version file can be determined based on the branch merge content and the base file. Specifically, the branch merge content (i.e. merge modification information) can be patched into the base file to obtain the merge version file corresponding to the first version file.

[0184] In this embodiment, the entire branch merging process is triggered by a commit operation and then proceeds automatically, automating the synchronization between branches without manual intervention. The automatic merging strategy can resolve some or all conflicts automatically. For unresolved conflicts, the system automatically identifies the handler and promptly notifies them. The system then continues automated processing based on the merge instructions corresponding to the handler's actions, resulting in high merging efficiency, low latency, and high accuracy. Furthermore, each commit operation requiring merging is automatically merged promptly, significantly improving the immediacy of the merge and reducing the probability of conflicts. In large projects requiring the simultaneous maintenance of multiple branches, this ensures efficient flow of change records between branches, guaranteeing development synchronization. The entire merging process can function as an automated backend service, requiring no running window, reducing manual intervention and maintenance costs.

[0185] Based on the branch merging method provided in the embodiments of this application, the embodiments of this application also provide a branch merging apparatus, see reference. Figure 14 The diagram shown is a structural block diagram of a branch merging device provided in an embodiment of this application. The branch merging device 1300 includes:

[0186] The capture unit 1301 is configured to, in response to a first commit operation to the repository from the first branch, obtain a first version file of the first commit operation and a second branch associated with the first branch;

[0187] Merging unit 1302 is used to determine the branch merging content for the content to be merged in the first version file according to the automatic merging strategy and the second version file of the second branch corresponding to the first version file.

[0188] The first notification unit 1303 is used to send a notification message corresponding to the target content to the development account corresponding to the target content if the branch merging content corresponding to the target content in the first version file fails to be determined.

[0189] Instruction processing unit 1304 is used to determine the branch merging content of the target content according to the merging instruction of the development account for the target content;

[0190] Version file determination unit 1305 is used to determine the merged version file corresponding to the second branch of the first version file based on the branch merge content corresponding to the content to be merged.

[0191] Optionally, the merging unit includes:

[0192] The benchmark file acquisition unit is used to take the common ancestor file of the first version file and the second version file as the benchmark file;

[0193] The modification determination unit is used to determine the source modification information of the first version file relative to the reference file, and the target modification information of the second version file relative to the reference file;

[0194] The merging subunit is used to merge the source modification information and the target modification information according to the automatic merging strategy to obtain merged modification information. The content corresponding to the merged modification information in the first version file is used as the content to be merged, and the merged modification information is used as the branch merging content of the content to be merged.

[0195] The version file determination unit is specifically used for:

[0196] Based on the branch merging content corresponding to the content to be merged and the baseline file, determine the merged version file corresponding to the first version file for the second branch.

[0197] Optionally, the first version file includes a first table file, the second version file includes a second table file corresponding to the first table file, and the base file includes a third table file corresponding to the first table file;

[0198] The modification determination unit is specifically used for:

[0199] The source modification information is determined based on the first comparison results of the first table file and the third table file at multiple levels; the target modification information is determined based on the second comparison results of the second table file and the third table file at multiple levels; the multiple levels include file level, table level, row level, column level and cell level.

[0200] Optionally, the device further includes:

[0201] The first comparison unit is used to determine the first comparison result based on the comparison results of the first table file and the third table file in terms of file identifier, table identifier, row header, column header and cell content, respectively;

[0202] The second comparison unit is used to determine the second comparison result based on the comparison results of the second table file and the third table file in terms of file identifier, table identifier, row header, column header and cell content, respectively.

[0203] Optionally, the merging subunit includes:

[0204] The first subunit is configured to, according to an automatic merging strategy, determine the merged modification information of the i-th modification information and the j-th modification information based on the j-th modification information if the i-th modification information in the source modification information and the j-th modification information are the same; where i and j are positive integers.

[0205] The second subunit is used to determine the merged modification information of the i-th modification information based on the i-th modification information if there is no modification information in the target modification information that is consistent with the modification object of the i-th modification information.

[0206] The third subunit is used to determine the merged modification information of the j-th modification information based on the j-th modification information if there is no modification information in the source modification information that is consistent with the modification object of the j-th modification information.

[0207] The fourth subunit is used to determine that the merging of the i-th modification information fails if the modification objects of the i-th modification information and the j-th modification information are the same, and the i-th modification information and the j-th modification information are different. The branch merging content of the content to be merged corresponding to the i-th modification information is determined to fail.

[0208] Optionally, the capture unit includes:

[0209] The list determination unit is used to determine a list to be merged based on the first commit operation of the first branch to the repository in response to the first commit operation. The list to be merged is used to record the merge operations of the second branch.

[0210] An operation acquisition unit is used to sequentially acquire the operations to be merged from the list to be merged;

[0211] The first information acquisition unit is used to acquire, after acquiring the first commit operation from the list to be merged, the first version file of the first commit operation and the second branch associated with the first branch.

[0212] Optionally, the device further includes:

[0213] The second information acquisition unit is used to acquire the third version file of the second commit operation in response to the second commit operation before acquiring the first version file of the first commit operation and the second branch associated with the first branch in response to the first commit operation to the repository.

[0214] The second notification unit is used to send a lock notification message to the development account corresponding to the lock file if it is determined that the third version file has a lock file locked by the second branch in the fourth version file corresponding to the second branch.

[0215] The list determination unit is specifically used for:

[0216] In response to the first commit operation of the first branch to the repository, the list of branches to be merged is determined based on the first commit operation and the second commit operation.

[0217] Optionally, the device further includes:

[0218] An operation acquisition subunit is used to acquire a second submission operation in the list to be merged before acquiring the first submission operation from the list to be merged.

[0219] The file update unit is used to obtain the merged version file corresponding to the third version file and then use the third version file as the base file and the merged version file corresponding to the third version file as the second version file.

[0220] Optionally, the first notification unit includes:

[0221] A group building unit is used to build an instant messaging group including a virtual robot and the development account corresponding to the target content if the branch merging content corresponding to the target content in the first version file fails to be determined.

[0222] A message sending unit is used to send a notification message corresponding to the target content in the instant messaging group through the virtual robot.

[0223] Optionally, the capture unit is specifically used for:

[0224] In response to the first commit operation to the repository from the first branch, if the first commit operation corresponds to an auto-merge tag, then obtain the first version file of the first commit operation and the second branch associated with the first branch.

[0225] Optionally, the first branch and the second branch belong to the same development stage of the same project. The first branch is a stable branch or a development branch, and the second branch is a development trunk branch. Alternatively, the first branch is a feature branch or a release branch, and the second branch is a development branch.

[0226] Alternatively, the first branch and the second branch belong to different development stages of the same project, the second development stage to which the second branch belongs is after the first development stage to which the first branch belongs, the first branch is a development trunk branch or a stable branch, and the second branch is a development trunk branch.

[0227] As can be seen from the above technical solution, in response to the first commit operation to the repository from the first branch, the first version file of the first commit operation and the second branch associated with the first branch are obtained. According to the automatic merge strategy and the second version file in the second branch corresponding to the first version file, the branch merge content is determined for the content to be merged in the first version file. In this way, based on the branch merge content corresponding to the content to be merged, the merge version file corresponding to the first version file to the second branch is determined, realizing real-time automatic merging from the first branch to the second branch in response to the first commit operation. This ensures that the changes in the first branch can be reflected in the second branch in a timely manner, guaranteeing the synchronization of development. Moreover, since the automatic merge is triggered by the commit operation, no manual triggering and control is required, thus saving labor costs. Furthermore, the branch merge triggered by the commit operation has a high merging frequency, and the content to be merged in each merge process is small, with fewer unresolved conflicts, which is conducive to achieving efficient automatic merging. During the process of determining the branch merge content, if the branch merge content corresponding to the target content in the first version file fails to be determined, a notification message corresponding to the target content is sent to the development account corresponding to the target content. The branch merge content of the target content is determined according to the merge instructions of the development account for the target content. In this way, the branch merge content is determined as automatically as possible during the real-time automatic merge process, avoiding excessive manual intervention and saving labor costs. If the branch merge content cannot be determined according to the automatic merge strategy, the content owner can be notified to assist in determining the branch merge content, thereby assisting the automatic merge process. The entire branch merge process is automated, ensuring both the efficiency and accuracy of branch merge.

[0228] This application also provides a computer device, which is the computer device described above, and may include a terminal device or a server. The aforementioned branch merging device may be configured in this computer device. The computer device will now be described in conjunction with the accompanying drawings.

[0229] If the computer device is a terminal device, please refer to Figure 15 As shown, this application provides a terminal device, taking a mobile phone as an example:

[0230] Figure 15 This diagram illustrates a partial structure of a mobile phone related to the terminal device provided in the embodiments of this application. (Reference) Figure 15 The mobile phone includes components such as a radio frequency (RF) circuit 1410, a memory 1420, an input unit 1430, a display unit 1440, a sensor 1450, an audio circuit 1460, a Wi-Fi module 1470, a processor 1480, and a power supply 1490. Those skilled in the art will understand that... Figure 15 The mobile phone structure shown does not constitute a limitation on the mobile phone and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0231] The following is combined Figure 15 A detailed introduction to each component of a mobile phone:

[0232] The RF circuit 1410 can be used to receive and transmit signals during information transmission or calls. In particular, it receives downlink information from the base station and processes it with the processor 1480; in addition, it transmits uplink data to the base station.

[0233] The memory 1420 can be used to store software programs and modules. The processor 1480 executes various mobile phone functions and data processing by running the software programs and modules stored in the memory 1420. The memory 1420 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, at least one application program required for a function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the mobile phone (such as audio data, phonebook, etc.). In addition, the memory 1420 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0234] The input unit 1430 can be used to receive input numeric or character information, and to generate key signal inputs related to user settings and function control of the mobile phone. Specifically, the input unit 1430 may include a touch panel 1431 and other input devices 1432.

[0235] The display unit 1440 can be used to display information input by the user or information provided to the user, as well as various menus of the mobile phone. The display unit 1440 may include a display panel 1441.

[0236] The mobile phone may also include at least one sensor 1450, such as a light sensor, a motion sensor, and other sensors.

[0237] Audio circuitry 1460, speaker 1461, and microphone 1462 provide an audio interface between the user and the mobile phone.

[0238] WiFi is a short-range wireless transmission technology. Through the WiFi module 1470, mobile phones can help users send and receive emails, browse web pages, and access streaming media, providing users with wireless broadband internet access.

[0239] The processor 1480 is the control center of the mobile phone. It connects to various parts of the mobile phone through various interfaces and lines. It performs various functions of the mobile phone and processes data by running or executing software programs and / or modules stored in the memory 1420 and calling data stored in the memory 1420.

[0240] The mobile phone also includes a power supply 1490 (such as a battery) that powers the various components.

[0241] In this embodiment, the processor 1480 included in the terminal device also has the following functions:

[0242] In response to the first commit operation to the repository from the first branch, obtain the first version file of the first commit operation, and the second branch associated with the first branch;

[0243] Based on the automatic merging strategy and the second version file of the second branch corresponding to the first version file, determine the branch merging content for the content to be merged in the first version file.

[0244] If the branch merging content corresponding to the target content in the first version file fails to be determined, a notification message corresponding to the target content is sent to the development account corresponding to the target content.

[0245] The branch merging content of the target content is determined according to the merging instruction of the development account for the target content;

[0246] Based on the branch merging content corresponding to the content to be merged, determine the merged version file corresponding to the first version file to the second branch.

[0247] If the computer device is a server, this application embodiment also provides a server; please refer to [link to relevant documentation]. Figure 16 As shown, Figure 16This is a structural diagram of a server 1500 provided in an embodiment of this application. The server 1500 can vary significantly due to different configurations or performance. It may include one or more processors 1522, such as a Central Processing Unit (CPU), a memory 1532, and one or more storage media 1530 (e.g., one or more mass storage devices) for storing application programs 1542 or data 1544. The memory 1532 and storage media 1530 can be temporary or persistent storage. The program stored in the storage media 1530 may include one or more modules (not shown in the diagram), each module including a series of instruction operations on the server. Furthermore, the processor 1522 may be configured to communicate with the storage media 1530 and execute the series of instruction operations in the storage media 1530 on the server 1500.

[0248] Server 1500 may also include one or more power supplies 1526, one or more wired or wireless network interfaces 1550, one or more input / output interfaces 1558, and / or one or more operating systems 1541, such as Windows Server. TM Mac OS X TM Unix TM Linux TM FreeBSD TM etc.

[0249] The steps performed by the server in the above embodiments can be based on Figure 16 The server structure shown.

[0250] In addition, this application also provides a computer-readable storage medium for storing a computer program for executing the methods provided in the above embodiments.

[0251] This application also provides a computer program product including a computer program, which, when run on a computer device, causes the computer device to perform the method provided in the above embodiments.

[0252] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to computer programs. The aforementioned computer program can be stored in a computer-readable storage medium. When the computer program is executed, it performs the steps of the above method embodiments. The aforementioned computer-readable storage medium can be at least one of the following media: read-only memory (ROM), RAM, magnetic disk, or optical disk, etc., and other media that can store computer programs.

[0253] It should be noted that the various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for the device and system embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiments. The device and system embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of the solution in this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0254] The above description is merely one specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Moreover, based on the implementation methods provided in the above aspects, this application can be further combined to provide more implementation methods. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A branch merging method, characterized in that, The method includes: In response to the first commit operation to the repository from the first branch, obtain the first version file of the first commit operation, and the second branch associated with the first branch; Based on the automatic merging strategy and the second version file of the second branch corresponding to the first version file, determine the branch merging content for the content to be merged in the first version file. If the branch merging content corresponding to the target content in the first version file fails to be determined, a notification message corresponding to the target content is sent to the development account corresponding to the target content. The branch merging content of the target content is determined according to the merging instruction of the development account for the target content; Based on the branch merging content corresponding to the content to be merged, determine the merged version file corresponding to the first version file to the second branch.

2. The method according to claim 1, characterized in that, The step of determining the branch merge content for the content to be merged in the first version file based on the automatic merge strategy and the second version file corresponding to the first version file in the second branch includes: The common ancestor file of the first version file and the second version file is used as the base file; Determine the source modification information of the first version file relative to the benchmark file, and the target modification information of the second version file relative to the benchmark file; According to the automatic merging strategy, the source modification information and the target modification information are merged to obtain merged modification information. The content corresponding to the merged modification information in the first version file is used as the content to be merged, and the merged modification information is used as the branch merging content of the content to be merged. The step of determining the merged version file corresponding to the second branch based on the branch merge content corresponding to the content to be merged includes: Based on the branch merging content corresponding to the content to be merged and the baseline file, determine the merged version file corresponding to the first version file for the second branch.

3. The method according to claim 2, characterized in that, The first version file includes a first table file, the second version file includes a second table file corresponding to the first table file, and the base file includes a third table file corresponding to the first table file; Determining the source modification information of the first version file relative to the benchmark file, and the target modification information of the second version file relative to the benchmark file, includes: The source modification information is determined based on the first comparison results of the first table file and the third table file at multiple levels; The target modification information is determined based on the second comparison results of the second table file and the third table file at multiple levels; the multiple levels include file level, table level, row level, column level and cell level.

4. The method according to claim 3, characterized in that, The method further includes: The first comparison result is determined based on the comparison results between the first table file and the third table file in terms of file identifier, table identifier, row header, column header, and cell content, respectively. The second comparison result is determined based on the comparison results between the second table file and the third table file in terms of file identifier, table identifier, row header, column header, and cell content.

5. The method according to claim 3, characterized in that, The step of merging the source modification information and the target modification information according to the automatic merging strategy to obtain merged modification information includes: According to the automatic merging strategy, if the i-th modification information in the source modification information is the same as the j-th modification information in the target modification information, then the merged modification information of the i-th modification information and the j-th modification information is determined based on the j-th modification information; where i and j are positive integers. If there is no modification information in the target modification information that is consistent with the modification object of the i-th modification information, then the merged modification information of the i-th modification information is determined based on the i-th modification information; If there is no modification information in the source modification information that is consistent with the modification object of the j-th modification information, then the merged modification information of the j-th modification information is determined based on the j-th modification information; If the modified objects of the i-th modification information and the j-th modification information are the same, and the i-th modification information and the j-th modification information are different, then the merging of the i-th modification information is determined to have failed, and the merging of the branch content of the content to be merged corresponding to the i-th modification information is determined to have failed.

6. The method according to any one of claims 1-5, characterized in that, The step of responding to a first commit operation to the repository from the first branch, obtaining the first version file of the first commit operation, and the second branch associated with the first branch, includes: In response to the first commit operation of the first branch to the repository, a list to be merged is determined based on the first commit operation, and the list to be merged is used to record the merge operations of the second branch; Sequentially retrieve the merge operations from the list of operations to be merged; After retrieving the first commit from the list to be merged, retrieve the first version file of the first commit and the second branch associated with the first branch.

7. The method according to claim 6, characterized in that, Before responding to a first commit operation to the repository from a first branch, obtaining the first version file of the first commit operation, and the second branch associated with the first branch, the method further includes: In response to the second commit operation, retrieve the third version file of the second commit operation; If it is determined that the third version file has a locked file in the fourth version file corresponding to the second branch that is locked by the second branch, then a lock notification message is sent to the development account corresponding to the locked file. The response to the first commit operation of the first branch to the repository, determining the list of branches to be merged based on the first commit operation, includes: In response to the first commit operation of the first branch to the repository, the list of branches to be merged is determined based on the first commit operation and the second commit operation.

8. The method according to claim 7, characterized in that, The method further includes: Before retrieving the first commit operation from the list to be merged, retrieve the second commit operation from the list to be merged; After obtaining the merged version file corresponding to the third version file and pointing to the second branch, the third version file is used as the base file, and the merged version file corresponding to the third version file is used as the second version file.

9. The method according to any one of claims 1-5, characterized in that, If the branch merging content corresponding to the target content in the first version file fails to be determined, a notification message corresponding to the target content is sent to the development account corresponding to the target content, including: If the branch merging content corresponding to the target content in the first version file fails to be determined, an instant messaging group including the virtual robot and the development account corresponding to the target content is constructed. The virtual robot sends a notification message corresponding to the target content in the instant messaging group.

10. The method according to any one of claims 1-5, characterized in that, The step of responding to a first commit operation to the repository from the first branch, obtaining the first version file of the first commit operation, and the second branch associated with the first branch, includes: In response to the first commit operation to the repository from the first branch, if the first commit operation corresponds to an auto-merge tag, then obtain the first version file of the first commit operation and the second branch associated with the first branch.

11. The method according to any one of claims 1-5, characterized in that, The first branch and the second branch belong to the same development stage of the same project. The first branch is a stable branch or a development branch, and the second branch is a development trunk branch. Alternatively, the first branch is a feature branch or a release branch, and the second branch is a development branch. Alternatively, the first branch and the second branch belong to different development stages of the same project, the second development stage to which the second branch belongs is after the first development stage to which the first branch belongs, the first branch is a development trunk branch or a stable branch, and the second branch is a development trunk branch.

12. A branch merging device, characterized in that, The device includes: A capture unit is configured to, in response to a first commit operation to the repository from a first branch, acquire a first version file of the first commit operation and a second branch associated with the first branch; The merging unit is used to determine the branch merging content for the content to be merged in the first version file according to the automatic merging strategy and the second version file of the second branch corresponding to the first version file. The first notification unit is used to send a notification message corresponding to the target content to the development account corresponding to the target content if the branch merging content corresponding to the target content in the first version file fails to be determined. An instruction processing unit is configured to determine the branch merging content of the target content based on the merging instruction from the development account for the target content; The version file determination unit is used to determine the merge version file corresponding to the first version file and the second branch based on the branch merge content corresponding to the content to be merged.

13. A computer device, characterized in that, The computer device includes a processor and memory: The memory is used to store computer programs and to transfer the computer programs to the processor; The processor is configured to execute the branch merging method according to any one of claims 1-11 according to instructions in the computer program.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store a computer program for performing the branch merging method according to any one of claims 1-11.

15. A computer program product comprising a computer program, characterized in that, When it is run on a computer device, it causes the computer device to perform the branch merging method according to any one of claims 1-11.

Images