Branch version merging method, device, system and electronic device

Abstract

The present application provides a method, apparatus, system and electronic device for merging branch versions. The method is applied to a server, and the server is connected to a version management server; receiving a branch merge request from a user; sending the target version number and the target branch number in the request to the version management server, so that the version management server determines a first version file to be merged under a first branch and a second version file to be merged under a second branch; wherein the merge direction is from the first branch to the second branch; receiving an identifier of the second version file to be merged returned by the version management server, and creating a target repository based on the identifier; performing a merge operation on the first version file to be merged and the second version file to be merged in the target repository to obtain a target merged version file; and sending the target merged version file to the version management server. The merge method provided by the present application has low learning cost, simple operation, no missed submissions, and does not block other merge operations when conflicts occur.

Description

Technical Field

[0001] This application relates to the field of software technology, and in particular, to a method, apparatus, system, and electronic device for merging branch versions. Background Art

[0002] In the current project R & D process, in order to retain milestone versions or develop large independent functions, a branching strategy is often adopted. In the branching strategy, the branch merge operation can synchronize the code between different branches and is an essential part. In some large projects, hundreds or thousands of branch merges are generated every day. How to improve the merge efficiency and properly handle the version conflicts generated by the merge is a very valuable research topic.

[0003] In the prior art, there are the following three branch merge solutions (taking the example of merging from branch A to branch B through SVN. SVN is the abbreviation of subversion, which is an open-source version control system, that is, a version management server):

[0004] 1. Use the SVN graphical merge tool: In the directory where branch B needs to be merged, use the SVN merge function, and query the version number of the content to be merged in branch A. After the merge is successful, check the merged files in the directory and submit them to the remote repository of branch B.

[0005] 2. Operate directly at the file system level, delete all files in the directory where branch B needs to be merged, and copy the files in branch A to the directory. After completion, submit them to the remote repository of branch B.

[0006] 3. Pull the complete repository of branch B on a certain tool server, and use the SVN command-line tool to merge from branch A according to the version number. After the merge operation is completed on branch B, submit it.

[0007] For Solution 1: The operation steps are complex, prone to misoperations, and the learning cost for non-technical staff is high. When querying the version number, tracing back all commits in the repository takes a long time, and after the merge is successful, the modified files cannot be automatically located, and it is easy to miss commits during the commit stage.

[0008] For Solution 2: In essence, it is a "double-end submission" strategy. After using it, the versions of the branches will not be aligned, and the version number's built-in merge function cannot be used, making it difficult to trace back when problems occur. Further, due to the existence of the "delete" operation, if the process is not standardized, files are easily overwritten by mistake, and for repositories with a large amount of resources, the entire process takes a long time to execute and has low efficiency.

[0009] For Solution 3: When determining the version number of the complete warehouse location, it takes a long time. Moreover, once a version conflict occurs, it will cause other merge operations to be unable to proceed normally, resulting in process blockage.

[0010] In summary, the existing branch merging methods have technical problems such as high learning cost, cumbersome operations, long time consumption, easy omission of commits, and blocking of other merge operations when conflicts occur. Summary of the Invention

[0011] The purpose of this application is to provide a branch version merging method, device, system and electronic device to solve the above technical problems.

[0012] In a first aspect, an embodiment of this application provides a branch version merging method. This method is applied to a server, and the server is connected to a version management server; the version management server includes multiple branches; each branch includes at least one version file; the method includes: receiving a branch merge request from a user; the branch merge request carries a target version number and a target branch number; sending the target version number and the target branch number to the version management server, so that the version management server determines a first version file to be merged under the first branch and a second version file to be merged under the second branch according to the target version number and the target branch number; wherein, the merge direction is from the first branch to the second branch; receiving the identifier of the second version file to be merged returned by the version management server, and creating a target warehouse based on the identifier of the second version file to be merged; performing a merge operation on the first version file to be merged and the second version file to be merged in the target warehouse to obtain a target merged version file; sending the target merged version file to the version management server.

[0013] Further, the step of sending the target version number and the target branch number to the version management server, so that the version management server determines a first version file to be merged under the first branch and a second version file to be merged under the second branch according to the target version number and the target branch number includes: sending the target version number and the target branch number to the version management server, so that the version management server searches for corresponding version commit information according to the target version number; the version commit information includes: a specified branch number, a first version file and a second version file; the second version file is a new version file obtained by modifying the first version file; determining the second version file corresponding to the specified branch number as the first version file to be merged under the first branch; determining the branch corresponding to the target branch number as the second branch; searching for a file identical to the first version file in the version files corresponding to the second branch, and using the found file as the second version file to be merged under the second branch.

[0014] Further, the step of creating a target repository based on the identifier of the second version file to be merged includes: pulling the second version file to be merged from the version management server according to the identifier of the second version file to be merged; generating a target repository containing the second version file to be merged.

[0015] Further, the step of performing a merge operation on the first version file to be merged and the second version file to be merged in the target repository to obtain a target merged version file includes: receiving the modification information corresponding to the first version file to be merged returned by the version management server according to the version submission information; performing a merge operation on the second version file to be merged in the target repository based on the modification information to obtain a target merged version file.

[0016] Further, after the step of sending the target merged version file to the version management server, the method further includes: deleting the target repository.

[0017] Further, the server is further connected to a terminal device; the terminal device is installed with an intelligent chat tool; the step of receiving a branch merge request from a user includes: receiving a branch merge request sent by the terminal device; the branch merge request is a branch merge instruction based on a target version number input by the user on the interface of the terminal device.

[0018] Further, after the step of performing a merge operation on the first version file to be merged and the second version file to be merged in the target repository to obtain a target merged version file, the method further includes: sending a first prompt message indicating successful branch merge to the terminal device, so that the terminal device displays the first prompt message to the user.

[0019] Further, the method further includes: if the identifier of the version file to be merged returned by the version management server is not received, or when a conflict occurs during the merge operation of the first version file to be merged and the second version file to be merged in the target repository, sending a second prompt message indicating failed branch merge to the terminal device, so that the terminal device displays the second prompt message to the user.

[0020] Further, the second prompt message further includes at least one of the following: reason for failed branch merge, prompt message for manual processing, information of the person in charge, and conflict files.

[0021] Second aspect, the embodiments of the present application further provide a method for merging branch versions. The method is applied to a version management server, and the version management server is connected to the server side; the version management server includes multiple branches; each branch includes at least one version file; the method includes: receiving a target version number and a target branch number sent by the server side; determining a first version file to be merged under the first branch and a second version file to be merged under the second branch according to the target version number and the target branch number; wherein, the merging direction is from the first branch to the second branch; sending an identifier of the second version file to be merged to the server side, so that the server side creates a target repository based on the identifier of the second version file to be merged; performing a merging operation on the first version file to be merged and the second version file to be merged in the target repository to obtain a target merged version file; receiving the target merged version file sent by the server side.

[0022] Further, the step of determining the version file to be merged according to the target version number and the target branch number includes: searching for corresponding version submission information according to the target version number; the version submission information includes: a specified branch number, a first version file, and a second version file; the second version file is a new version file obtained by modifying the first version file; determining the second version file corresponding to the specified branch number as the first version file to be merged under the first branch; determining the branch corresponding to the target branch number as the second branch; searching for a file identical to the first version file in the version files corresponding to the second branch, and taking the found file as the second version file to be merged under the second branch.

[0023] Further, each branch corresponds to a directory structure; the step of searching for a file identical to the first version file in the version files corresponding to the second branch includes: determining a first storage path of the first version file in a first directory structure under the first branch; searching for a second storage path identical to the first storage path in a second directory structure under the second branch; determining the version file corresponding to the second storage path as the file identical to the first version file.

[0024] In a third aspect, an embodiment of the present application further provides a branch version merging device. The device is applied to a server, and the server is connected to a version management server. The version management server includes multiple branches, and each branch includes at least one version file. The device includes: a request receiving module, configured to receive a branch merging request from a user. The branch merging request carries a target version number and a target branch number. A request sending module, configured to send the target version number and the target branch number to the version management server, so that the version management server determines a first version file to be merged under a first branch and a second version file to be merged under a second branch. Wherein, the merging direction is from the first branch to the second branch. A repository creating module, configured to receive an identifier of the second version file to be merged returned by the version management server, and create a target repository based on the identifier of the second version file to be merged. A branch merging module, configured to perform a merging operation on the first version file to be merged and the second version file to be merged in the target repository to obtain a target merged version file. A version file sending module, configured to send the target merged version file to the version management server.

[0025] In a fourth aspect, an embodiment of the present application further provides a branch version merging device. The device is applied to a version management server, and the version management server is connected to a server. The version management server includes multiple branches, and each branch includes at least one version file. The device includes: an information receiving module, configured to receive the target version number and the target branch number sent by the server. A file determining module, configured to determine a first version file to be merged under a first branch and a second version file to be merged under a second branch according to the target version number and the target branch number. Wherein, the merging direction is from the first branch to the second branch. An information sending module, configured to send an identifier of the second version file to be merged to the server, so that the server creates a target repository based on the identifier of the second version file to be merged. Perform a merging operation on the first version file to be merged and the second version file to be merged in the target repository to obtain a target merged version file. A file receiving module, configured to receive the target merged version file sent by the server.

[0026] In a fifth aspect, an embodiment of the present application further provides a branch version merging system, including: a version management server, a terminal device, and a server. The terminal device is installed with an intelligent chat tool. The server is respectively connected to the terminal device and the version management server. The server is configured to execute the method described in the first aspect. The version management server is configured to execute the method described in the second aspect.

[0027] In a sixth aspect, an embodiment of the present application further provides an electronic device, including a processor and a memory. The memory stores computer executable instructions that can be executed by the processor, and the processor executes the computer executable instructions to implement the method described in the first aspect or the second aspect above.

[0028] In a seventh aspect, an embodiment of the present application further provides a computer-readable storage medium storing computer-executable instructions that, when called and executed by a processor, cause the processor to implement the method described in the first aspect or the second aspect above.

[0029] In the method, apparatus, system, and electronic device for merging branch versions provided by the embodiments of the present application, the method is applied to a server that is connected to a version management server; the version management server includes multiple branches; each branch includes at least one version file; the method includes: receiving a branch merge request from a user; the branch merge request carries a target version number and a target branch number; sending the target version number and the target branch number to the version management server so that the version management server determines a first version file to be merged under a first branch and a second version file to be merged under a second branch according to the target version number and the target branch number; wherein the merge direction is from the first branch to the second branch; receiving an identifier of the second version file to be merged returned by the version management server, and creating a target repository based on the identifier of the second version file to be merged; performing a merge operation on the first version file to be merged and the second version file to be merged in the target repository to obtain a target merged version file; and sending the target merged version file to the version management server. In the embodiments of the present application, the user only needs to initiate one request, and the server will automatically locate the two version files to be merged according to the information in the request through the version management server, and then create a target repository for the second version file to be merged. Since the target repository only contains the second version file to be merged and the number of files is relatively small, it can be called a sparse repository. Through this target repository, other requests can be isolated, that is, whether this merge is successful or not will not affect the merge operations of other requests. Therefore, the above merge method has a low learning cost and is simple to operate for the user, and all the files in the sparse repository can be submitted to the version management server without omission. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] In order to more clearly illustrate the specific embodiments of the present application or the technical solutions in the prior art, the following will briefly introduce the drawings required for the description of the specific embodiments or the prior art. Obviously, the drawings in the following description are some embodiments of the present application. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0031] Figure 1 It is a flowchart of a method for merging branch versions provided by an embodiment of the present application;

[0032] Figure 2 It is a flowchart of another method for merging branch versions provided by an embodiment of the present application;

[0033] Figure 3 A schematic diagram of request initiation provided by an embodiment of the present application;

[0034] Figure 4 A schematic diagram of a "sparse repository" provided by an embodiment of the present application;

[0035] Figure 5 Another schematic diagram of the branch version merging process provided by an embodiment of the present application;

[0036] Figure 6 A schematic diagram of a first prompt message provided by an embodiment of the present application;

[0037] Figure 7 A schematic diagram of a second prompt message provided by an embodiment of the present application;

[0038] Figure 8 A flowchart of another method for merging branch versions provided by an embodiment of the present application;

[0039] Figure 9 A structural block diagram of a branch version merging device provided by an embodiment of the present application;

[0040] Figure 10 A structural block diagram of another branch version merging device provided by an embodiment of the present application;

[0041] Figure 11 A structural block diagram of a branch version merging system provided by an embodiment of the present application;

[0042] Figure 12 A structural schematic diagram of an electronic device provided by an embodiment of the present application. Detailed implementation manners

[0043] Next, the technical solutions of the present application will be clearly and completely described in conjunction with the embodiments. Obviously, the described embodiments are some, but not all, of the embodiments of the present application. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present application without creative efforts shall fall within the protection scope of the present application.

[0044] In the project development scenario, developers usually pull a certain version of a file from a branch of the version control server as the initial file, and then modify and submit it based on this initial file. After a successful submission, they will receive the version number Revision issued by the version control server. For different branches within the same repository, a common version number system is used, that is, the version number can locate a specific commit in all branches. Therefore, through the above-mentioned issued version number, the version submission information corresponding to this commit can be obtained, including which branch it was submitted to, which was the initial file, and which are the modified files.

[0045] After submitting the version file as described above, in order to enable other relevant personnel to also view or apply this version file, it is often necessary to synchronize this version file to other branches, that is, a branch merge operation needs to be performed. In the prior art, there are usually the following three merge methods, taking the example of merging from branch A to branch B through SVN for illustration:

[0046] 1. Use the SVN graphical merge tool: In the directory where branch B needs to be merged, use the SVN merge function and query the version number of the content to be merged in branch A. After a successful merge, check the merged files in the directory and submit them to the remote repository of branch B. This method has complex operation steps, is prone to misoperations, and has a high learning cost for non-technical staff. When querying the version number, it traces back all commits in the repository, which takes a long time, and after a successful merge, it is impossible to automatically locate the modified files, and it is easy to miss submissions during the commit stage.

[0047] 2. Directly operate at the file system level, delete all files in the directory where branch B needs to be merged, and copy the files in branch A to the directory. After completion, submit them to the remote repository of branch B. This solution is essentially a "dual-end submission" strategy. After using it, the versions of the branches will not be aligned, and the version number's built-in merge function will not be available, making it difficult to trace back when problems occur. Further, due to the existence of the "delete" operation, if the process is not standardized, files are easily overwritten incorrectly, and for repositories with a large amount of resources, the entire process takes a relatively long time and has low efficiency.

[0048] 3. Pull the complete repository of branch B on a certain version control server, and use the SVN command-line tool to perform a merge from branch A according to the version number. After completing the merge operation on branch B, submit it. In this method, it takes a long time to locate the version number through the complete repository, and once a version conflict occurs, it will cause other merge operations to also be unable to proceed normally, resulting in a process block.

[0049] In summary, the existing branch merging methods have technical problems such as high learning costs, cumbersome operations, long time consumption, easy omission of commits, and blocking of other merge operations when conflicts occur.

[0050] Based on this, the embodiments of the present application provide a branch version merging method, device, system, and electronic device to solve the above technical problems.

[0051] For ease of understanding of this embodiment, a branch version merging method disclosed in the embodiments of the present application will be introduced in detail first. In the embodiments of the present application, in view of the technical problems in the existing branch merging methods, such as high learning costs, cumbersome operations, long time consumption, easy omission of commits, and blocking of other merge operations when conflicts occur, a branch version merging method with low learning costs, simple operations, and high branch version merging efficiency is provided, which can avoid version conflict problems and will not cause omission of commits. This method is applied to the server side, and the server side is connected to the version management server; the version management server is also a version management tool, which is a software tool for managing file versions in multi-person collaboration during software development, including but not limited to SVN and Git. The version management server includes multiple branches; each branch includes at least one version file. Figure 1 The flowchart of a branch version merging method provided by the embodiments of the present application is shown. The method specifically includes the following steps:

[0052] Step S102, receive a branch merge request from the user; the branch merge request carries a target version number and a target branch number.

[0053] The above branch merge request can be initiated in various ways. For example, enter a branch merge instruction in the IM robot interface, such as including a target version number, a target branch number, and a merge instruction, or on a terminal device installed with a specific intelligent chat tool, enter a merge instruction including a target version number, a target branch number, or a branch merge request can also be sent to the server side.

[0054] In a version management server, a set of version numbers is shared, that is, in the same repository, the version numbers corresponding to the version files in different branches are uniquely determined. Therefore, the version management server can accurately locate a version commit information according to the above target version number. Through the above target branch number, it can be determined which branch this version commit wants to merge into.

[0055] Step S104, send the target version number and the target branch number to the version management server, so that the version management server determines a first version file to be merged under the first branch and a second version file to be merged under the second branch; wherein, the merge direction is from the first branch to the second branch.

[0056] In the specific implementation process, after receiving the request, the server will send the target version number and the target branch number to the version management server. The version management server can first determine the corresponding version submission information according to the target version number. As mentioned above, this information may include the specified branch number to which the submission is made, the first version file, and the second version file. Among them, the first version file is the aforementioned initial file, and the second version file is the file modified on the basis of the initial file. Further, it can be determined that the second version file under the specified branch number is the first version file to be merged under the first branch. Then, according to the above version submission information and the target branch number, the second version file to be merged under the second branch can also be determined. The second branch is the branch corresponding to the target branch number, that is, the target branch that the user wants to merge. The determined second version file to be merged corresponds exactly to the first version file to be merged. For example, if there are three files in the first version file to be merged, the determined second version file to be merged also contains three files. That is to say, a single submission may include multiple files, and these multiple files are collectively referred to as the first version file to be merged in the embodiments of the present application.

[0057] Step S106: Receive the identifier of the second version file to be merged returned by the version management server, and create a target repository based on the identifier of the second version file to be merged.

[0058] Generally speaking, the number of files corresponding to a single merge operation is relatively small, such as within 1 - 10. Therefore, the second version file to be merged is pulled based on the identifier of the second version file to be merged, and the number of files in the created target repository is also relatively small. In the embodiments of the present application, the target repository can be referred to as a "sparse repository", indicating that the number of files in this repository is small. Creating the target repository can be achieved by pulling files through the corresponding commands in the server, which will not be elaborated here.

[0059] Step S108: Perform a merge operation on the first version file to be merged and the second version file to be merged in the target repository to obtain a target merged version file.

[0060] Performing a merge operation on the first version file to be merged and the second version file to be merged in the above - created "sparse repository" can obtain a target merged version file. This target merged version file is the result of synchronizing the first version file to be merged to the second branch.

[0061] Step S110: Send the target merged version file to the version management server. That is, submit the target merged version file to the remote repository to complete the process of merging the version files this time.

[0062] In the branch version merging method provided by the embodiments of the present application, the user only needs to initiate a request, and the server will automatically locate the two version files to be merged according to the information in the request through the version management server. Then, a target repository is created for the second version file to be merged. Since only the second version file to be merged is included in this target repository and the number of files is relatively small, it can be called a "sparse repository". Through this repository, other requests can be isolated, that is, whether this merge is successful or not will not affect the merge operations of other requests. Therefore, for the user, the above merging method has a low learning cost, is easy to operate, and all the files in the sparse repository can be submitted to the version management server without missing submissions.

[0063] The embodiments of the present application also provide another branch version merging method, which is implemented on the basis of the above embodiments; this embodiment focuses on describing the request initiation process, the determination process of the version files to be merged, and the generation process of the "sparse repository".

[0064] See Figure 2 As shown in the flowchart of a branch version merging method, the terminal device in this method is described by taking an IM robot as an example. This method includes the following steps:

[0065] Step S202, receiving a branch merge request sent by the terminal device; the branch merge request is a branch merge instruction based on the target version number input by the user on the interface of the terminal device.

[0066] The above terminal device is connected to the server; an intelligent chat tool is installed on the terminal device, and through this tool, a request can be sent to the server. In actual application, a socket process for monitoring message sending is installed in this tool. In other words, there is a robot account in the chat group, and this account can monitor chat information. If a specific keyword is locked, the robot can send an instruction to the server to execute an operation.

[0067] In the embodiments of the present application, the target branch to be merged usually defaults to the latest version branch by default. Therefore, the user only needs to input a branch merge instruction containing the target version number on the interface of the terminal device. As Figure 3 shown, the branch merge instruction is "branch merge 126496", where 126496 is the target version number. In this way, the target version number input by the user and the default branch number will be automatically carried in the initiated request. If the user does not want to merge with the default branch, the branch number can also be specified when inputting the instruction. For example, the complete instruction form is: branch merge to20210810at 126496, where 20210810 refers to the branch to be merged.

[0068] In the embodiment of the present application, the operation of initiating a branch merge request through the above-mentioned robot is simple, which can greatly reduce the learning cost of users.

[0069] Step S204: Send the target version number and the target branch number to the version management server, so that the version management server can find the corresponding version submission information according to the target version number. The version submission information includes: a specified branch number, a first version file, and a second version file. The second version file is a new version file obtained by modifying the first version file. Determine the second version file corresponding to the specified branch number as the first version file to be merged under the first branch. Determine the branch corresponding to the target branch number as the second branch. Search for a file identical to the first version file in the version file corresponding to the second branch, and use the found file as the second version file to be merged under the second branch.

[0070] Through the above-mentioned target version number, the corresponding version submission information can be located, that is, through this target version number, the branch, the initial file, and the modified file corresponding to this submission can be obtained, namely the above-mentioned specified branch number, the first version file, and the second version file.

[0071] In practical applications, each of the above branches corresponds to a directory structure. The process of searching for a file identical to the first version file in the version file corresponding to the second branch can be implemented in the following way: First, determine the first storage path of the first version file in the first directory structure under the first branch. Then, search for a second storage path identical to the first storage path in the second directory structure under the second branch. Finally, determine the version file corresponding to the second storage path as the file identical to the first version file.

[0072] Step S206: Pull the second version file to be merged from the version management server according to the identifier of the second version file to be merged, and generate a target repository containing the second version file to be merged. In this step, a repository can be created in real time according to the found second version file to be merged. The specific method is to directly use the svn co method to pull the file from the version management server after querying the corresponding second version file to be merged from the version management server, so as to form a "sparse repository" containing the second version file to be merged.

[0073] For each branch merge request, an independent "sparse repository" can be generated. That is, there will be multiple "sparse repositories" on the server side, and each repository only contains the second version file to be merged required this time. As shown in Figure 4 Each temp_target_(timestamp) folder is a generated "sparse repository". Since the "sparse repositories" are independent of each other, conflict testing, that is, merge operations, can be performed in the repository without affecting other merge processes.

[0074] Step S208: Receive the modification information corresponding to the first version file to be merged returned by the version management server according to the version submission information. The version submission information includes the branch corresponding to this submission, the initial file, and the modified file, that is, the specified branch number, the first version file, and the second version file. Therefore, the version management server can determine the modification information of the second version file relative to the first version file, that is, the modification information corresponding to the first version file to be merged.

[0075] Step S210: Based on the modification information, perform a merge operation on the second version file to be merged in the first repository to obtain the target merged version file.

[0076] The actual process of merging is a function provided by the server. Through the merge command, the above modification information can be used to complete the merge operation on the second version file to be merged in the above-mentioned "sparse repository" to obtain the target merged version file.

[0077] A branch version merging method provided by an embodiment of the present application is a merge solution centered on a "sparse repository". Using a "sparse repository" for merge operations, different from the original large repository, a "sparse repository" has the following characteristics: no need for prior deployment, automatically locate the version files to be merged according to the revision submitted by the user and form a repository; the number of files in a single repository is small (generally less than 10), and real-time creation can be supported; one merge generates one "sparse repository", and the environments between different "sparse repositories" are isolated and will not affect other merge processes.

[0078] Another branch version merging method is also provided in an embodiment of the present application, which is implemented on the basis of the above embodiment; this embodiment focuses on describing the display process of the merge result.

[0079] The following takes the merge from branch A to branch B based on a "sparse repository" and SVN as an example for detailed description:

[0080] See Figure 5 The schematic diagram of the merge process shown: The tool server is the aforementioned server; the remote repository is the aforementioned version management server; the information collection robot is the aforementioned terminal device installed with an intelligent chat tool.

[0081] ① Initiation of the Merge request: To reduce the learning cost for users, in the embodiment of the present application, the user automatically initiates a merge request by entering the version number in the robot interface. The user only needs to enter the revision to be merged to start the merge process. The specific process can refer to the aforementioned step S202.

[0082] ② Locate the merge file. Based on the revision in the previous step, the version file that branch A needs to merge in this commit can be accurately located through the command-line tool svn log. At the same time, through relative path conversion, the version file to be merged in branch B can be obtained. The specific process can refer to the aforementioned steps S204 - S208 and will not be elaborated here.

[0083] ③ Create a "sparse repository", which can refer to the content of the aforementioned step S210.

[0084] ④ Conflict test, that is, the process of performing a merge operation in the "sparse repository". If no conflict occurs, after the merge is successfully completed in the repository, the sparse repository is fully committed (since there are only version files associated with this merge in the "sparse repository", a full commit can be made without miscommitting or omitting), and the "sparse repository" is deleted after completion.

[0085] That is, after the step of performing the merge operation of the first version file to be merged and the second version file to be merged in the target repository to obtain the target merged version file, the server will also send the target merged version file to the version management server and delete the target repository, that is, the "sparse repository". In this way, after the branch merge is successful, all files in the target repository can be fully committed to the version management server without file omission or miscommit.

[0086] If a conflict occurs, the conflict scene is retained in the "sparse repository" for backtracking and the commit is blocked. At the same time, regardless of whether there is a conflict or not, the merge information will be returned to the user through the robot so that the user can handle the problem in a timely manner, that is, the Merge situation will be synchronized to the user through the information collection robot. The specific implementation steps are as follows:

[0087] In order to enable the user to timely understand the branch merge situation, the method of the operation in the embodiment of the present application, after the step of performing the merge operation of the first version file to be merged and the second version file to be merged in the target repository to obtain the target merged version file, may further include the following steps: sending a first prompt message indicating successful branch merge to the terminal device so that the terminal device displays the first prompt message to the user. As Figure 6 shown, after the user sends a branch merge request, if the target branch to be merged is currently in the process of performing a merge operation, the user will receive a message from the feedback robot that this instruction will be queued. If the branch merge of this user is successful, the user will receive a message from the feedback robot indicating successful merge.

[0088] On the other hand, if the second version file to be merged under the second branch cannot be determined according to the target version number and the target branch number, or a conflict occurs during the merge operation of the first version file to be merged and the second version file to be merged in the target repository, a second prompt message indicating that the branch merge fails is sent to the terminal device, so that the terminal device displays the second prompt message to the user. In a preferred manner, the second prompt message further includes at least one of the following: the reason for the branch merge failure, the prompt message for manual processing, the information of the person in charge, and the conflict file.

[0089] As Figure 7 shown, when a conflict occurs during the merge operation in the "sparse repository", the conflict scene is reserved for backtracking and the commit is blocked. At the same time, the branch merge situation information, such as the prompt message for manual processing in case of conflict, as well as the conflict file and the information of the person in charge, etc., is fed back to the user through the robot, so that the user can handle the problem in the first time.

[0090] Compared with the original large repository solution, the branch version merge solution provided by the embodiments of the present application has the following advantages for the "sparse repository":

[0091] 1) The "sparse repository" is generated in real time, and the user does not need to pull the repository in advance, so the tool deployment cost and deployment time are greatly shortened;

[0092] 2) All merge requests are processed in isolation, and a single merge conflict will not hinder other merge processes;

[0093] 3) The "sparse repository" can be used for merge testing. Once a conflict occurs, the scene can be reserved and the corresponding operator can be located for processing. If successful, it can be directly committed and the local "sparse repository" can be deleted without consuming additional hard disk space;

[0094] 4) In the svn version control framework, merge can backtrack all commit and merge records, and is compatible with the graphical tool operation solution. When a conflict occurs, it can be directly transferred to manual processing;

[0095] 5) Since only the files corresponding to the current merge are retained in the "sparse repository", after the merge is completed, the corresponding "sparse repository" can be fully committed, preventing the occurrence of missed commits or incorrect commits.

[0096] The embodiments of the present application also provide another branch version merge method, which is implemented at the version management server end. Refer to Figure 8 shown, and specifically includes the following steps:

[0097] Step S802, receiving the target version number and the target branch number sent by the server;

[0098] Step S804: Determine the first version file to be merged under the first branch and the second version file to be merged under the second branch according to the target version number and the target branch number; wherein, the merging direction is from the first branch to the second branch.

[0099] Specifically, it can be implemented through the following steps:

[0100] (1) According to the target version number, search for the corresponding version submission information; the version submission information includes: the specified branch number, the first version file, and the second version file; the second version file is the new version file modified based on the first version file.

[0101] (2) Determine the second version file corresponding to the specified branch number as the first version file to be merged under the first branch.

[0102] (3) Determine the branch corresponding to the target branch number as the second branch.

[0103] (4) Search for the file identical to the first version file in the version files corresponding to the second branch, and use the found file as the second version file to be merged under the second branch.

[0104] Furthermore, each branch corresponds to a directory structure; the step of searching for the file identical to the first version file in the version files corresponding to the second branch includes: determining the first storage path of the first version file in the first directory structure under the first branch; searching for the second storage path identical to the first storage path in the second directory structure under the second branch; and determining the version file corresponding to the second storage path as the file identical to the first version file.

[0105] Step S806: Send the identifier of the second version file to be merged to the server, so that the server creates a target repository based on the identifier of the second version file to be merged; perform a merging operation on the first version file to be merged and the second version file to be merged in the target repository to obtain a target merged version file.

[0106] Step S808: Receive the target merged version file sent by the server.

[0107] The method provided in the embodiments of the present application is similar to the aforementioned server method. For the content not mentioned, reference can be made to the foregoing embodiment part, which will not be elaborated here.

[0108] Based on the above method embodiments, the embodiments of the present application further provide a branch version merging device. The device is applied to the server, and the server is connected to the version management server; the version management server includes multiple branches; each branch includes at least one version file; as shown in Figure 9 shown, the device includes:

[0109] A request receiving module 902, configured to receive a branch merge request from a user; the branch merge request carries a target version number and a target branch number; a request sending module 904, configured to send the target version number and the target branch number to a version management server, so that the version management server determines a first version file to be merged under a first branch and a second version file to be merged under a second branch; wherein, the merge direction is from the first branch to the second branch; a repository creation module 906, configured to receive an identifier of the second version file to be merged returned by the version management server, and create a target repository based on the identifier of the second version file to be merged; a branch merge module 908, configured to perform a merge operation on the first version file to be merged and the second version file to be merged in the target repository to obtain a target merged version file; a version file sending module 910, configured to send the target merged version file to the version management server.

[0110] The above-mentioned request sending module 904 is further configured to send the target version number and the target branch number to the version management server, so that the version management server searches for corresponding version submission information according to the target version number; the version submission information includes: a specified branch number, a first version file, and a second version file; the second version file is a new version file obtained by modifying the first version file; determine the second version file corresponding to the specified branch number as the first version file to be merged under the first branch; determine the branch corresponding to the target branch number as the second branch; search for a file identical to the first version file in the version file corresponding to the second branch, and use the found file as the second version file to be merged under the second branch.

[0111] The above-mentioned repository creation module 906 is further configured to pull the second version file to be merged from the version management server according to the identifier of the second version file to be merged, and generate a target repository containing the second version file to be merged.

[0112] The above-mentioned branch merge module 908 is configured to further receive modification information corresponding to the first version file to be merged returned by the version management server according to the version submission information; perform a merge operation on the second version file to be merged in the target repository based on the modification information to obtain a target merged version file.

[0113] The above-mentioned apparatus further includes: a repository deletion module, configured to delete the target repository after the step of sending the target merged version file to the version management server.

[0114] The above-mentioned server is further connected to a terminal device; an intelligent chat tool is installed on the terminal device; the above-mentioned request receiving module 902 is configured to receive a branch merge request sent by the terminal device; the branch merge request is a branch merge instruction based on a target version number input by the user on the interface of the terminal device.

[0115] The above-mentioned device further includes: an information sending module, configured to, after performing a merging operation on a first version file to be merged and a second version file to be merged in a target repository to obtain a target merged version file, send a first prompt message indicating successful branch merging to a terminal device, so that the terminal device displays the first prompt message to the user.

[0116] The above-mentioned information sending module is further configured to, if the identifier of the version file to be merged returned by the version management server is not received according to the target version number and the target branch number, or if a conflict occurs during the merging operation of the first version file to be merged and the second version file to be merged in the target repository, send a second prompt message indicating failed branch merging to the terminal device, so that the terminal device displays the second prompt message to the user.

[0117] The above-mentioned second prompt message further includes at least one of the following: reason for failed branch merging, prompt message for manual processing, information of the person in charge, and conflict files.

[0118] The branch version merging device provided by an embodiment of the present application has the same implementation principle and technical effects as those of the foregoing method embodiment. For a brief description, for parts not mentioned in the device embodiment, reference may be made to the corresponding content in the foregoing branch version merging method embodiment.

[0119] Based on the foregoing method embodiment, an embodiment of the present application further provides a branch version merging device. The device is applied to a version management server, and the version management server is connected to a server; the version management server includes multiple branches; each branch includes at least one version file; see Figure 10 As shown, the device includes:

[0120] An information receiving module 102, configured to receive a target version number and a target branch number sent by the server; a file determining module 104, configured to determine a first version file to be merged under a first branch and a second version file to be merged under a second branch according to the target version number and the target branch number; wherein, the merging direction is from the first branch to the second branch; an information sending module 106, configured to send the identifier of the second version file to be merged to the server, so that the server creates a target repository based on the identifier of the second version file to be merged; perform a merging operation on the first version file to be merged and the second version file to be merged in the target repository to obtain a target merged version file; a file receiving module 108, configured to receive the target merged version file sent by the server.

[0121] The above-mentioned file determination module 104 is used to find the corresponding version submission information according to the target version number; the version submission information includes: a specified branch number, a first version file, and a second version file; the second version file is a new version file obtained by modifying the first version file; determine the second version file corresponding to the specified branch number as the first version file to be merged under the first branch; determine the branch corresponding to the target branch number as the second branch; find a file identical to the first version file in the version file corresponding to the second branch, and use the found file as the second version file to be merged under the second branch.

[0122] Further, each of the above branches corresponds to a directory structure; the file determination module 104 is used to determine the first storage path of the first version file in the first directory structure under the first branch; find a second storage path identical to the first storage path in the second directory structure under the second branch; determine the version file corresponding to the second storage path as the file identical to the first version file.

[0123] The branch version merging device provided by the embodiments of the present application has the same implementation principle and technical effects as those of the foregoing method embodiments. For the sake of brief description, for the parts not mentioned in the embodiments of the device, reference may be made to the corresponding content in the foregoing method embodiments of branch version merging.

[0124] Based on the foregoing method embodiments, the embodiments of the present application further provide a branch version merging system. Refer to Figure 11 As shown, the system includes: a version management server 112, a terminal device 114, and a server 116; the terminal device 114 is installed with an intelligent chat tool; the server 116 is respectively connected to the terminal device 114 and the version management server 112; the server 116 is used to execute the method described in the foregoing method embodiments on the server side; the version management server 112 is used to execute the method described in the foregoing method embodiments on the version management server side.

[0125] The branch version merging system provided by the embodiments of the present application has the same implementation principle and technical effects as those of the foregoing method embodiments. For the sake of brief description, for the parts not mentioned in the embodiments of the system, reference may be made to the corresponding content in the foregoing method embodiments of branch version merging.

[0126] The embodiments of the present application further provide an electronic device. As Figure 12 shown, it is a schematic structural diagram of the electronic device. Among them, the electronic device includes a processor 121 and a memory 120. The memory 120 stores computer-executable instructions that can be executed by the processor 121, and the processor 121 executes the computer-executable instructions to implement the above method.

[0127] In Figure 12In the illustrated embodiment, the electronic device further includes a bus 122 and a communication interface 123, wherein the processor 121, the communication interface 123, and the memory 120 are connected through the bus 122.

[0128] Among them, the memory 120 may include a high-speed random access memory (RAM), and may also include a non-volatile memory, such as at least one disk memory. The communication connection between the system network element and at least one other network element is realized through at least one communication interface 123 (which can be wired or wireless), and the Internet, wide area network, local area network, metropolitan area network, etc. can be used. The bus 122 may be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. The bus 122 can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 12 only a single bidirectional arrow is used in the figure, but it does not mean that there is only one bus or one type of bus.

[0129] The processor 121 may be an integrated circuit chip with the ability to process signals. In the implementation process, each step of the above method can be completed by the integrated logic circuit in the hardware of the processor 121 or instructions in the form of software. The above-mentioned processor 121 may be a general-purpose processor, including a central processing unit (CPU for short), a network processor (NP for short), etc.; it may also be a digital signal processor (DSP for short), an application specific integrated circuit (ASIC for short), a field-programmable gate array (FPGA for short), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc. The steps of the method disclosed in the embodiments of the present application can be directly implemented by the hardware decoding processor, or implemented by a combination of the hardware and software modules in the decoding processor. The software module may be located in a mature storage medium in the art such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, or an electrically erasable programmable memory, a register, etc. This storage medium is located in the memory, and the processor 121 reads the information in the memory and combines its hardware to complete the steps of the method in the foregoing embodiments.

[0130] The embodiments of the present application also provide a computer-readable storage medium storing computer-executable instructions, which, when called and executed by a processor, cause the processor to implement the above method. For specific implementation, reference may be made to the foregoing method embodiments and will not be elaborated herein.

[0131] The computer program product of the method, device, and electronic device provided by the embodiments of the present application includes a computer-readable storage medium storing program code, and the instructions included in the program code can be used to execute the method described in the foregoing method embodiments. For specific implementation, reference may be made to the method embodiments and will not be elaborated herein.

[0132] Unless otherwise specifically stated, the relative steps, numerical expressions, and values of the components and steps set forth in these embodiments do not limit the scope of the present application.

[0133] When the above-mentioned functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a non-volatile computer-readable storage medium executable by a processor. Based on such an understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in various embodiments of this application. The aforementioned storage medium includes: various media such as USB flash drives, mobile hard disks, read-only memories (ROM, Read-Only Memory), random access memories (RAM, Random Access Memory), magnetic disks, or optical discs that can store program codes.

[0134] In the description of this application, it should be noted that the orientation or positional relationship indicated by the terms "center", "upper", "lower", "left", "right", "vertical", "horizontal", "inner", "outer", etc. is based on the orientation or positional relationship shown in the drawings. It is only for the convenience of describing this application and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation. Therefore, it should not be construed as a limitation to this application. In addition, the terms "first", "second", "third" are only used for descriptive purposes and cannot be construed as indicating or implying relative importance.

[0135] Finally, it should be noted that: the above-mentioned embodiments are only specific implementation manners of this application, used to illustrate the technical solutions of this application, rather than limiting it. The protection scope of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those of ordinary skill in the art should understand that: any person skilled in the art within the technical scope disclosed by this application can still modify the technical solutions recorded in the foregoing embodiments, or can easily think of changes, or perform equivalent replacements on some of the technical features; and these modifications, changes, or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be covered within the protection scope of this application. Therefore, the protection scope of this application should be subject to the protection scope of the claims.

Claims

1. A method for merging branch versions, characterized in that, the method is applied to a server, and the server is connected to a version management server; the version management server includes multiple branches; each branch includes at least one version file; the method includes: Receiving a branch merge request from a user; the branch merge request carries a target version number and a target branch number; Sending the target version number and the target branch number to the version management server, so that the version management server determines a first version file to be merged under the first branch and a second version file to be merged under the second branch according to the target version number and the target branch number; wherein, the merge direction is from the first branch to the second branch; Receiving the identifier of the second version file to be merged returned by the version management server, and creating a target repository based on the identifier of the second version file to be merged; Performing a merge operation on the first version file to be merged and the second version file to be merged in the target repository to obtain a target merged version file; Sending the target merged version file to the version management server.

2. The method according to claim 1, characterized in that, the step of sending the target version number and the target branch number to the version management server, so that the version management server determines a first version file to be merged under the first branch and a second version file to be merged under the second branch according to the target version number and the target branch number, includes: Sending the target version number and the target branch number to the version management server, so that the version management server searches for corresponding version submission information according to the target version number; the version submission information includes: a specified branch number, a first version file, and a second version file; the second version file is a new version file obtained by modifying the first version file; determining the second version file corresponding to the specified branch number as the first version file to be merged under the first branch; determining the branch corresponding to the target branch number as the second branch; searching for a file identical to the first version file in the version file corresponding to the second branch, and using the found file as the second version file to be merged under the second branch.

3. The method according to claim 1, characterized in that, the step of creating a target repository based on the identifier of the second version file to be merged includes: Pulling the second version file to be merged from the version management server according to the identifier of the second version file to be merged; Generating a target repository containing the second version file to be merged.

4. The method according to claim 2, characterized in that, the step of performing a merge operation on the first version file to be merged and the second version file to be merged in the target repository to obtain a target merged version file includes: Receiving the modification information corresponding to the first version file to be merged returned by the version management server according to the version submission information; Performing a merge operation on the second version file to be merged in the target repository based on the modification information to obtain a target merged version file.

5. The method according to claim 1, wherein, after the step of sending the target merged version file to the version management server, the method further includes: deleting the target repository.

6. The method according to claim 1, wherein, the server is further connected to a terminal device; the terminal device is installed with an intelligent chat tool; the step of receiving a branch merge request from a user includes: receiving a branch merge request sent by the terminal device; the branch merge request is a branch merge instruction based on the target version number input by the user on the interface of the terminal device.

7. The method according to claim 6, wherein, after the step of performing a merge operation on the first version file to be merged and the second version file to be merged in the target repository to obtain a target merged version file, the method further includes: sending a first prompt message indicating successful branch merge to the terminal device, so that the terminal device displays the first prompt message to the user.

8. The method according to claim 6, wherein, the method further includes: if the identifier of the second version file to be merged returned by the version management server is not received, or when a conflict occurs during the merge operation of the first version file to be merged and the second version file to be merged in the target repository, sending a second prompt message indicating failed branch merge to the terminal device, so that the terminal device displays the second prompt message to the user.

9. The method according to claim 8, wherein, the second prompt message further includes at least one of the following: reason for failed branch merge, prompt message for manual processing, information of the person to handle, and conflict files.

10. A branch version merge method, wherein, the method is applied to a version management server, and the version management server is connected to a server; the version management server includes multiple branches; each branch includes at least one version file; the method includes: receiving a target version number and a target branch number sent by the server; determining a first version file to be merged under a first branch and a second version file to be merged under a second branch according to the target version number and the target branch number; wherein, the merge direction is from the first branch to the second branch; sending the identifier of the second version file to be merged to the server, so that the server creates a target repository based on the identifier of the second version file to be merged; performing a merge operation on the first version file to be merged and the second version file to be merged in the target repository to obtain a target merged version file; receiving the target merged version file sent by the server.

11. The method according to claim 10, wherein, the step of determining a first version file to be merged under a first branch and a second version file to be merged under a second branch according to the target version number and the target branch number includes: Find the corresponding version submission information according to the target version number; the version submission information includes: a specified branch number, a first version file, and a second version file; the second version file is a new version file obtained by modifying the first version file. Determine the second version file corresponding to the specified branch number as the first version file to be merged under the first branch. Determine the branch corresponding to the target branch number as the second branch. Find a file in the version file corresponding to the second branch that is the same as the first version file, and use the found file as the second version file to be merged under the second branch.

12. The method according to claim 11, wherein, Each branch corresponds to a directory structure; The step of finding a file in the version file corresponding to the second branch that is the same as the first version file includes: Determine the first storage path of the first version file in the first directory structure under the first branch; Find a second storage path in the second directory structure under the second branch that is the same as the first storage path; Determine the version file corresponding to the second storage path as the file that is the same as the first version file.

13. A branch version merging device, wherein, The device is applied to a server, and the server is connected to a version management server; the version management server includes multiple branches; each branch includes at least one version file; the device includes: A request receiving module, configured to receive a branch merging request from a user; the branch merging request carries a target version number and a target branch number; A request sending module, configured to send the target version number and the target branch number to the version management server, so that the version management server determines a first version file to be merged under the first branch and a second version file to be merged under the second branch according to the target version number and the target branch number; wherein, the merging direction is from the first branch to the second branch; A repository creating module, configured to receive an identifier of the second version file to be merged returned by the version management server, and create a target repository based on the identifier of the second version file to be merged; A branch merging module, configured to perform a merging operation on the first version file to be merged and the second version file to be merged in the target repository to obtain a target merged version file; A version file sending module, configured to send the target merged version file to the version management server.

14. A branch version merging device, wherein, The device is applied to a version management server, and the version management server is connected to a server; The version management server includes multiple branches; each branch includes at least one version file; the device includes: An information receiving module, configured to receive the target version number and the target branch number sent by the server; A file determining module, configured to determine a first version file to be merged under the first branch and a second version file to be merged under the second branch according to the target version number and the target branch number; wherein, the merging direction is from the first branch to the second branch; An information sending module, configured to send an identifier of the second version file to be merged to the server, so that the server creates a target repository based on the identifier of the second version file to be merged; perform a merging operation on the first version file to be merged and the second version file to be merged in the target repository to obtain a target merged version file; A file receiving module, configured to receive the target merged version file sent by the server.

15. A branch version merging system Characterized in that The system includes: a version management server, a terminal device, and a server; the terminal device is installed with an intelligent chat tool; The server is respectively connected to the terminal device and the version management server; The server is configured to execute the method according to any one of claims 1-9; The version management server is configured to execute the method according to any one of claims 10-12.

16. An electronic device Characterized in that It includes a processor and a memory, the memory stores computer executable instructions that can be executed by the processor, and the processor executes the computer executable instructions to implement the method according to any one of claims 1 to 9 or 10-12.

17. A computer-readable storage medium Characterized in that The computer-readable storage medium stores computer executable instructions, and when the computer executable instructions are called and executed by a processor, the computer executable instructions cause the processor to implement the method according to any one of claims 1 to 9 or 10-12.

Images