Code merging status detection method, device, equipment, readable storage medium and program product

Abstract

The present application relates to a method, apparatus, device, readable storage medium and program product for detecting the state of code merging. The method includes: synchronously saving the commit objects existing in the branch code in the remote repository to the local; obtaining a first set of commit objects and a second set of commit objects; the first set of commit objects includes the commit objects that exist in the mainline code of the remote repository and do not exist locally; the second set of commit objects includes the commit objects that exist locally and do not exist in the mainline code of the remote repository; detecting whether the branch code in the local has been merged into the mainline code in the remote repository according to the data relationship between the commit content associated with the first set of commit objects and the commit content associated with the second set of commit objects. By using this method, the abnormal merging problem of the branch code can be detected in time.

Description

Technical Field

[0001] This application relates to the field of computer programming technologies, and in particular, to a method, apparatus, computer device, computer-readable storage medium, and computer program product for detecting the code merging status. Background Art

[0002] In the process of software development, version control systems are important tools for managing code versions and collaborative development. Nowadays, more and more software development teams use distributed version control systems to manage branches, merge, and synchronize the code in code development projects for multi-person collaborative development. However, with the expansion of the scale of code development projects and the increase in developers, the management of branches and the merging of code have become increasingly complex.

[0003] In the actual use of traditional distributed version control systems, the inventors found that the code on different branches often easily has problems such as merge conflicts and unfinished merges, and these problems are often not easy to discover and handle in a timely manner, making it easy to have inconsistent code libraries, which is not conducive to the normal progress of code development projects. Summary of the Invention

[0004] Based on this, it is necessary to provide a method, apparatus, computer device, computer-readable storage medium, and computer program product for detecting the merging anomalies of branch code in a timely manner in view of the above technical problems.

[0005] In a first aspect, this application provides a method for detecting the code merging status, and the method includes:

[0006] Synchronously save the commit objects existing in the branch code in the remote repository to the local.

[0007] Obtain a first set of commit objects and a second set of commit objects; the first set of commit objects includes the commit objects that exist in the mainline code of the remote repository and do not exist locally; the second set of commit objects includes the commit objects that exist locally and do not exist in the mainline code of the remote repository.

[0008] Detect whether the branch code in the local has been merged into the mainline code in the remote repository according to the data relationship between the commit content associated with the first set of commit objects and the commit content associated with the second set of commit objects.

[0009] In one of the embodiments, the detecting whether the branch code in the local has been merged into the mainline code in the remote repository according to the data relationship between the commit content associated with the first set of commit objects and the commit content associated with the second set of commit objects includes:

[0010] Obtain the content identifiers corresponding to each submission object in the first submission object set to obtain a first content identifier set, and obtain the content identifiers corresponding to each submission object in the second submission object set to obtain a second content identifier set; the content identifier is a unique identifier used to represent the submission content associated with the submission object.

[0011] Detect whether the branch code in the local has been merged into the main line code in the remote repository according to the set relationship between the first content identifier set and the second content identifier set.

[0012] In one embodiment, the detecting whether the branch code in the local has been merged into the main line code in the remote repository according to the set relationship between the first content identifier set and the second content identifier set includes:

[0013] If the first content identifier set is a subset of the second content identifier set, it is determined that the branch code in the local has been merged into the main line code in the remote repository;

[0014] If the first content identifier set is not a subset of the second content identifier set, it is determined that the branch code in the local has not been merged into the main line code in the remote repository.

[0015] In one embodiment, the obtaining the content identifiers corresponding to each submission object in the first submission object set to obtain a first identifier content set includes:

[0016] Obtain the submission content corresponding to each submission object in the first submission object set;

[0017] Perform hash processing on the submission content corresponding to each submission object in the first submission object set to generate a unique content code corresponding to each submission object in the first submission object set;

[0018] Use the unique content code corresponding to each submission object in the first submission object set as the content identifier corresponding to each submission object in the first submission object set to obtain the first identifier content set.

[0019] In one embodiment, the obtaining the content identifiers corresponding to each submission object in the second submission object set to obtain a second content identifier set includes:

[0020] Obtain the submission content corresponding to each submission object in the second submission object set;

[0021] Perform hash processing on the submission content corresponding to each submission object in the second submission object set to generate a unique content code for each submission object in the second submission object set;

[0022] Use the unique content code corresponding to each submission object in the second submission object set as the content identifier corresponding to each submission object in the second submission object set to obtain the second content identifier set.

[0023] In one embodiment, the obtaining of the first submission object set and the second submission object set includes:

[0024] Obtain the commit history of the remote repository; the commit history includes the record information of the submission objects existing on the mainline code of the remote repository;

[0025] Determine the first submission object set and the second submission object set according to the commit history.

[0026] In a second aspect, the present application also provides a code merge status detection device, and the device includes:

[0027] A synchronization module for synchronously saving the submission objects existing in the branch code in the remote repository to the local;

[0028] An obtaining module for obtaining a first submission object set and a second submission object set; the first submission object set includes the submission objects that exist on the mainline code of the remote repository and do not exist locally; the second submission object set includes the submission objects that exist locally and do not exist on the mainline code of the remote repository;

[0029] A detection module for detecting whether the branch code in the local has been merged into the mainline code in the remote repository according to the data relationship between the submission content associated with the first submission object set and the submission content associated with the second submission object set.

[0030] In a third aspect, the present application also provides a computer device, including a memory and a processor, where the memory stores a computer program, and the processor implements the steps of the above method when executing the computer program.

[0031] In a fourth aspect, the present application also provides a computer-readable storage medium, on which a computer program is stored, and the computer program implements the steps of the above method when executed by a processor.

[0032] In a fifth aspect, the present application also provides a computer program product, including a computer program, and the computer program implements the steps of the above method when executed by a processor.

[0033] The above code merge status detection method, device, computer device, computer-readable storage medium, and computer program product synchronously save the commit objects existing in the branch code in the remote repository to the local, and obtain a first set of commit objects and a second set of commit objects; the first set of commit objects includes the commit objects that exist in the main line code of the remote repository and do not exist locally; the second set of commit objects includes the commit objects that exist locally and do not exist in the main line code of the remote repository; then, according to the data relationship between the commit content associated with the first set of commit objects and the commit content associated with the second set of commit objects, it is detected whether the branch code in the local has been merged into the main line code in the remote repository; in this way, by comparing the data relationship between the commit content associated with the first set of commit objects and the commit content associated with the second set of commit objects, the code changes in the local and the code changes involved in the commit of the main line merge can be compared in real time or at regular intervals to check whether the local branch code has been merged into the main line code, reducing the cumbersome process of manual inspection, timely and accurately detecting the merge exception problems of the branch code, avoiding the situation where the code library is prone to inconsistency, and improving the development efficiency of the code development project. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0035] Figure 1 It is an application environment diagram of a code merge status detection method in an embodiment;

[0036] Figure 2 It is a flowchart of a code merge status detection method in an embodiment;

[0037] Figure 3 It is a flowchart of a code merge status detection method in another embodiment;

[0038] Figure 4 It is a structural block diagram of a code merge status detection device in an embodiment;

[0039] Figure 5 It is an internal structure diagram of a computer device in an embodiment. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0040] In order to make the objectives, technical solutions, and advantages of the present application more clear and understandable, the present application will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0041] A method for detecting the code merge status provided by an embodiment of the present application can be applied to an application environment as Figure 1 shown. Among them, the electronic device 102 communicates with the server 104 through a network. The data storage system can store the data that the server 104 needs to process. The data storage system can be integrated on the server 104, or can be placed in the cloud or other network servers. In practical applications, the electronic device 102 synchronously saves the commit objects existing in the branch code in the remote repository to the local; the electronic device 102 obtains a first set of commit objects and a second set of commit objects; the first set of commit objects includes the commit objects that exist on the main line code of the remote repository and do not exist locally; the second set of commit objects includes the commit objects that exist locally and do not exist on the main line code of the remote repository; the electronic device 102 detects whether the branch code in the local has been merged into the main line code in the remote repository according to the data relationship between the commit content associated with the first set of commit objects and the commit content associated with the second set of commit objects. Among them, the electronic device 102 can be, but is not limited to, various personal computers, laptop computers, smart phones, and tablet computers. The server 104 can be an independent physical server, or a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.

[0042] In an exemplary embodiment, as Figure 2 shown, a method for detecting the code merge status is provided. Taking the electronic device in Figure 1 as an example, the following steps 202 to 206 are included. Among them:

[0043] Step 202, synchronously save the commit objects existing in the branch code in the remote repository to the local.

[0044] Among them, the remote repository can refer to a remote code repository. Specifically, this method is applied to a distributed version control system, and developers can use this distributed version control system to track and manage code changes. This distributed version control system can allow multiple users to collaborate on the same code repository, and at the same time this distributed version control system can ensure the integrity of the code and the accuracy of the historical records.

[0045] In practical applications, the distributed version control system is configured with a remote code repository. The distributed version control system allows users to synchronize the local repository with the remote repository for collaborative team development. When a user clones a remote repository, by default, the distributed version control system will track certain branches of the remote repository.

[0046] Among them, after creating a new code project in the distributed version control system, the code project is default-configured with a branch, namely the main branch. In practical applications, the main branch generally represents the stable version of the code project, and the main branch contains the code of the stable version. In practical applications, the main branch can be named the main line. The code contained in the main branch that represents the stable version can be named the main line code.

[0047] When new features need to be developed, the user can create a feature branch based on the main branch. The feature branch can be a branch of the main line, and the code contained in the feature branch can also be called branch code.

[0048] A commit object can refer to the core data structure that records a code change in the distributed version control system. Each commit object represents a snapshot or the code state at a certain point in time; in practical applications, each commit object has a corresponding commit identifier (commit ID). In this application, a commit object can also be referred to as a commit.

[0049] In practical applications, the commit ID is calculated and generated based on the following:

[0050] 1) Commit object type: In the distributed version control system, each object has a type;

[0051] 2) Commit information: including the name of the committer's account, email address, commit date and timestamp, and the description information of the commit;

[0052] 3) Parent commit ID: If the current commit has a parent commit, the parent commit ID of the parent commit will also be included (there is no parent commit for the first commit;

[0053] 4) Tree object: Represents a snapshot of the entire file tree of the commit;

[0054] 5) Other metadata: including the encoding of the commit, etc.

[0055] Therefore, even if the modified content of two commits is the same, different parent commit IDs will result in different commit IDs.

[0056] In a specific implementation, the electronic device synchronously saves the commit objects existing in the branch code of the remote repository to the local. Specifically, the electronic device can submit a log viewing command (for example, the git log command) to the distributed version control system. This log viewing command can obtain the relative complement of the local branch and the remote branch, thereby realizing the synchronization between the local repository and the remote repository. The electronic device can synchronously save the commit objects existing in the branch code of the remote repository to the local, and update the commit information of the remote branch code (i.e., the branch code in the remote repository) saved locally.

[0057] Among them, the local branch can refer to the branch code of the local repository, and the remote branch can refer to the branch code of the remote repository.

[0058] Step 204, obtain a first set of commit objects and a second set of commit objects; the first set of commit objects includes the commit objects that exist in the main line code of the remote repository and do not exist locally; the second set of commit objects includes the commit objects that exist locally and do not exist in the main line code of the remote repository.

[0059] In a specific implementation, the electronic device can submit a log viewing command (for example, the git log command) to the distributed version control system, obtain the commit history of the remote code repository through this log viewing command, and determine, according to the commit history of the remote code repository, the commit objects that exist in the main line code of the remote repository and do not exist locally, which is recorded as the first set of commit objects A; similarly, the electronic device determines, according to the commit history of the remote code repository, the commit objects that exist locally and do not exist in the main line code of the remote repository, which is recorded as the second set of commit objects B.

[0060] Step 206, detect whether the branch code in the local has been merged into the main line code in the remote repository according to the data relationship between the commit content associated with the first set of commit objects and the commit content associated with the second set of commit objects.

[0061] In a specific implementation, after the electronic device obtains the first set of commit objects A and the second set of commit objects B, it can compare the commit content associated with the first set of commit objects with the commit content associated with the second set of commit objects. The electronic device can detect whether the branch code in the local has been merged into the main line code in the remote repository according to the data relationship between the commit content associated with the first set of commit objects and the commit content associated with the second set of commit objects.

[0062] Specifically, when the electronic device detects that the commit content associated with the second set of commit objects contains the commit content associated with the first set of commit objects, the electronic device determines that it has detected that the branch code in the local has been merged into the main line code in the remote repository.

[0063] In the above code merge status detection method, the commit objects existing in the branch code in the remote repository are synchronously saved locally, and the first set of commit objects and the second set of commit objects are obtained; the first set of commit objects includes the commit objects that exist in the main line code of the remote repository and do not exist locally; the second set of commit objects includes the commit objects that exist locally and do not exist in the main line code of the remote repository; then, according to the data relationship between the commit content associated with the first set of commit objects and the commit content associated with the second set of commit objects, it is detected whether the branch code in the local has been merged into the main line code in the remote repository; in this way, by comparing the data relationship between the commit content associated with the first set of commit objects and the commit content associated with the second set of commit objects, the code changes in the local and the code changes involved in the commit of the main line merge can be compared in real time or at regular intervals to check whether the branch code in the local has been merged into the main line code, reducing the cumbersome process of manual inspection, timely and accurately detecting the merge exception problems of the branch code, avoiding the situation of inconsistent code libraries that is likely to occur, and improving the development efficiency of the code development project.

[0064] In an exemplary embodiment, according to the data relationship between the commit content associated with the first set of commit objects and the commit content associated with the second set of commit objects, detecting whether the branch code in the local has been merged into the main line code in the remote repository includes: obtaining the content identifiers corresponding to the commit objects in the first set of commit objects to obtain the first set of content identifiers, and obtaining the content identifiers corresponding to the commit objects in the second set of commit objects to obtain the second set of content identifiers; the content identifier is a unique identifier used to represent the commit content associated with the commit object; according to the set relationship between the first set of content identifiers and the second set of content identifiers, it is detected whether the branch code in the local has been merged into the main line code in the remote repository.

[0065] In a specific implementation, when the electronic device detects whether the branch code in the local has been merged into the main line code in the remote repository according to the data relationship between the commit content associated with the first set of commit objects and the commit content associated with the second set of commit objects, the electronic device can obtain the content identifiers corresponding to the commit objects in the first set of commit objects to obtain the first set of content identifiers Pa = {P(a)|a ∈ A}; and obtain the content identifiers corresponding to the commit objects in the second set of commit objects to obtain the second set of content identifiers Pb = {P(b)|b ∈ B}; then, the electronic device can detect whether the branch code in the local has been merged into the main line code in the remote repository according to the set relationship between the first set of content identifiers Pa and the second set of content identifiers Pb.

[0066] Specifically, when the first content identifier set Pa is a subset of the second content identifier set Pb (i.e., Pa ⊂ Pb), the electronic device determines that the branch code in the local has been merged into the main line code in the remote repository; the electronic device can display a first prompt message to prompt the user that the branch code in the local has been merged into the main line code in the remote repository through this first prompt message.

[0067] When the first content identifier set is not a subset of the second content identifier set, the electronic device determines that the branch code in the local has not been merged into the main line code in the remote repository. The electronic device can display a second prompt message to prompt the user that the branch code in the local has not been merged into the main line code in the remote repository through this second prompt message.

[0068] The technical solution of this embodiment obtains the first content identifier set by obtaining the content identifiers corresponding to the commit objects in the first commit object set, and obtains the second content identifier set by obtaining the content identifiers corresponding to the commit objects in the second commit object set; the content identifier is a unique identifier used to represent the commit content associated with the commit object; according to the set relationship between the first content identifier set and the second content identifier set, it is possible to quickly compare the commit content associated with the first commit object set and the commit content associated with the second commit object set by determining whether the first content identifier set is a subset of the second content identifier set, and then efficiently determine whether the branch code in the local has been merged into the main line code in the remote repository based on the comparison result.

[0069] In an exemplary embodiment, obtaining the content identifiers corresponding to the commit objects in the first commit object set to obtain the first identifier content set includes: obtaining the commit content corresponding to the commit objects in the first commit object set; performing a hash process on the commit content corresponding to the commit objects in the first commit object set to generate a unique content code corresponding to the commit objects in the first commit object set; using the unique content code corresponding to the commit objects in the first commit object set as the content identifier corresponding to the commit objects in the first commit object set to obtain the first identifier content set.

[0070] In a specific implementation, when the electronic device obtains the content identifiers corresponding to the respective submission objects in the first submission object set to obtain the first identifier content set, the electronic device may obtain the submission content corresponding to each submission object in the first submission object set. Specifically, the electronic device may obtain the submission content corresponding to each submission object in the first submission object set according to the submission IDs corresponding to the respective submission objects in the first submission object set. Then, the electronic device may perform a hashing process on the submission content corresponding to each submission object in the first submission object set to generate a unique content code corresponding to each submission object in the first submission object set. Specifically, the electronic device may calculate the patch-id (patch ID) for each submission object in the first submission object set. Then, the electronic device adds the patch IDs corresponding to the respective submission objects in the first submission object set to the first identifier content set, and denotes the first identifier content set as the set Pa = {P(a)|a ∈ A}.

[0071] The technical solution of this embodiment obtains the submission content corresponding to each submission object in the first submission object set, and performs a hashing process on the submission content corresponding to each submission object in the first submission object set to generate a unique content code corresponding to each submission object in the first submission object set, so that the submission content corresponding to each submission object can be represented by the unique content code corresponding to each submission object, effectively reducing the data processing amount in the process of comparing the submission content associated with the first submission object set with the submission content associated with the second submission object set, and improving the efficiency of detecting whether the branch code in the local is merged into the main code in the remote repository.

[0072] In an exemplary embodiment, obtaining the content identifiers corresponding to the respective submission objects in the second submission object set to obtain the second content identifier set includes: obtaining the submission content corresponding to each submission object in the second submission object set; performing a hashing process on the submission content corresponding to each submission object in the second submission object set to generate a unique content code corresponding to each submission object in the second submission object set; using the unique content codes corresponding to the respective submission objects in the second submission object set as the content identifiers corresponding to the respective submission objects in the second submission object set to obtain the second content identifier set.

[0073] In a specific implementation, when the electronic device obtains the content identifiers corresponding to the submission objects in the second submission object set to obtain the second identifier content set, the electronic device can obtain the submission content corresponding to each submission object in the second submission object set. Specifically, the electronic device can obtain the submission content corresponding to each submission object in the second submission object set according to the submission ID corresponding to each submission object in the second submission object set. Then, the electronic device can perform a hashing process on the submission content corresponding to each submission object in the second submission object set to generate a unique content code corresponding to each submission object in the second submission object set. Specifically, the electronic device can calculate the patch-id (patch ID) for each submission object in the second submission object set. Then, the electronic device adds the patch ID corresponding to each submission object in the second submission object set to the second identifier content set, and denotes the second identifier content set as the set Pb={P(b)|b∈B}.

[0074] In the technical solution of this embodiment, by obtaining the submission content corresponding to each submission object in the first submission object set and performing a hashing process on the submission content corresponding to each submission object in the first submission object set to generate a unique content code corresponding to each submission object in the first submission object set, it is possible to use the unique content code corresponding to each submission object to represent the submission content corresponding to each submission object, effectively reducing the data processing amount in the process of comparing the submission content associated with the first submission object set and the submission content associated with the second submission object set, and improving the efficiency of detecting whether the branch code in the local area has been merged into the main line code in the remote repository.

[0075] In an exemplary embodiment, obtaining the first submission object set and the second submission object set includes: obtaining the submission history of the remote repository; and determining the first submission object set and the second submission object set according to the submission history.

[0076] Among them, the submission history includes the record information of the submission objects existing on the main line code of the remote repository.

[0077] In a specific implementation, the electronic device can submit a log viewing command (for example, the gitlog command) to the distributed version control system, obtain the submission history of the remote code repository through this log viewing command, and determine, according to this submission history, the submission objects that exist on the main line code of the remote repository and do not exist locally, which are denoted as the first submission object set A. Similarly, the electronic device determines, according to the submission history of the remote code repository, the submission objects that exist locally and do not exist on the main line code of the remote repository, which are denoted as the second submission object set B.

[0078] In the technical solution of this embodiment, by obtaining the commit history of the remote repository, according to the commit history, the first set of commit objects and the second set of commit objects are accurately determined, which facilitates accurately detecting whether the branch code in the local has been merged into the main line code in the remote repository subsequently.

[0079] In another embodiment, as Figure 3 shown, a method for detecting code merge status is provided. Taking the case where this method is applied to Figure 1 the electronic device in as an example for illustration, it includes the following steps:

[0080] Step S302, synchronously save the commit objects existing in the branch code in the remote repository to the local.

[0081] Step S304, obtain the first set of commit objects and the second set of commit objects; the first set of commit objects includes the commit objects that exist in the main line code of the remote repository and do not exist locally; the second set of commit objects includes the commit objects that exist locally and do not exist in the main line code of the remote repository.

[0082] Step S306, obtain the commit content corresponding to each commit object in the first set of commit objects.

[0083] Step S308, perform hash processing on the commit content corresponding to each commit object in the first set of commit objects, generate the unique content encoding corresponding to each commit object in the first set of commit objects, and obtain the first set of identification contents.

[0084] Step S310, obtain the commit content corresponding to each commit object in the second set of commit objects.

[0085] Step S312, perform hash processing on the commit content corresponding to each commit object in the second set of commit objects, generate the unique content encoding corresponding to each commit object in the second set of commit objects, and obtain the second set of content identifications.

[0086] Step S314, in the case where the first set of identification contents is a subset of the second set of content identifications, it is determined that the branch code in the local has been merged into the main line code in the remote repository.

[0087] It should be noted that the specific limitations of the above steps can refer to the specific limitations of a method for detecting code merge status in the above text.

[0088] It should be understood that although the steps in the flowcharts involved in the above-described embodiments are sequentially shown according to the indication of the arrows, these steps are not necessarily executed sequentially in the order indicated by the arrows. Unless there is a clear indication in this article, there is no strict order restriction for the execution of these steps, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above-described embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily executed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be executed alternately or in turn with at least a part of other steps or steps or stages in other steps.

[0089] Based on the same inventive concept, an embodiment of the present application further provides a code merge status detection device for implementing the above-mentioned code merge status detection method. The solution provided by this device to solve the problem is similar to the solution described in the above method. Therefore, the specific limitations in one or more embodiments of the code merge status detection device provided below can refer to the limitations on the code merge status detection method in the above text, and will not be repeated here.

[0090] In an exemplary embodiment, as Figure 4 shown, a code merge status detection device is provided, including:

[0091] A synchronization module 410, configured to synchronously save the commit objects existing in the branch code in the remote repository to the local;

[0092] An acquisition module 420, configured to acquire a first set of commit objects and a second set of commit objects; the first set of commit objects includes the commit objects that exist in the main line code of the remote repository and do not exist locally; the second set of commit objects includes the commit objects that exist locally and do not exist in the main line code of the remote repository;

[0093] A detection module 430, configured to detect whether the branch code in the local has been merged into the main line code in the remote repository according to the data relationship between the commit content associated with the first set of commit objects and the commit content associated with the second set of commit objects.

[0094] In one embodiment, the detection module 430 is configured to obtain the content identifiers corresponding to the submission objects in the first submission object set to obtain a first content identifier set, and obtain the content identifiers corresponding to the submission objects in the second submission object set to obtain a second content identifier set; the content identifier is a unique identifier used to characterize the submission content associated with the submission object; and detect whether the branch code in the local has been merged into the mainline code in the remote repository according to the set relationship between the first content identifier set and the second content identifier set.

[0095] In one embodiment, the detection module 430 is configured to, when the first content identifier set is a subset of the second content identifier set, determine that the branch code in the local has been merged into the mainline code in the remote repository; and when the first content identifier set is not a subset of the second content identifier set, determine that the branch code in the local has not been merged into the mainline code in the remote repository.

[0096] In one embodiment, the detection module 430 is configured to obtain the submission content corresponding to each submission object in the first submission object set; perform a hashing process on the submission content corresponding to each submission object in the first submission object set to generate a unique content code corresponding to each submission object in the first submission object set; and use the unique content code corresponding to each submission object in the first submission object set as the content identifier corresponding to each submission object in the first submission object set to obtain the first identifier content set.

[0097] In one embodiment, the detection module 430 is configured to obtain the submission content corresponding to each submission object in the second submission object set; perform a hashing process on the submission content corresponding to each submission object in the second submission object set to generate a unique content code corresponding to each submission object in the second submission object set; and use the unique content code corresponding to each submission object in the second submission object set as the content identifier corresponding to each submission object in the second submission object set to obtain the second content identifier set.

[0098] In one embodiment, the acquisition module 420 is configured to obtain the submission history of the remote repository; the submission history includes the record information of the submission objects existing on the mainline code of the remote repository; and determine the first submission object set and the second submission object set according to the submission history.

[0099] Each module in the above code merging status detection device can be implemented in whole or in part by software, hardware, or a combination thereof. Each of the above modules can be embedded in the processor in the computer device in hardware form or be independent of the processor, or can be stored in the memory in the computer device in software form, so as to facilitate the processor to call and execute the operations corresponding to each of the above modules.

[0100] In an exemplary embodiment, a computer device is provided. The computer device can be a terminal, and its internal structure diagram can be as Figure 5 shown. The computer device includes a processor, a memory, an input / output interface, a communication interface, a display unit, and an input device. Among them, the processor, the memory, and the input / output interface are connected through a system bus, and the communication interface, the display unit, and the input device are connected to the system bus through the input / output interface. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The input / output interface of the computer device is used for exchanging information between the processor and external devices. The communication interface of the computer device is used for communicating with external terminals in a wired or wireless manner, and the wireless manner can be implemented through WIFI, a mobile cellular network, near field communication (NFC), or other technologies. The computer program, when executed by the processor, implements a code merging status detection method. The display unit of the computer device is used to form a visually visible picture, which can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be a liquid crystal display screen or an electronic ink display screen. The input device of the computer device can be a touch layer covering the display screen, or a button, a trackball, or a touchpad provided on the housing of the computer device, or an external keyboard, touchpad, or mouse, etc.

[0101] Those skilled in the art can understand that Figure 5 the structure shown in

[0102] is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine some components, or have different component arrangements. In an embodiment, a computer device is provided, including a memory and a processor. The memory stores a computer program. When the computer program is executed by the processor, the processor executes the steps of the above code merging status detection method. Here, the steps of the code merging status detection method can be the steps in the code merging status detection method in each of the above embodiments.

[0103] In one embodiment, a computer-readable storage medium is provided, storing a computer program. When the computer program is executed by a processor, the processor is caused to execute the steps of the above-mentioned method for detecting a code merging state. The steps of the method for detecting a code merging state here may be the steps of the method for detecting a code merging state in each of the above embodiments.

[0104] In one embodiment, a computer program product is provided, including a computer program. When the computer program is executed by a processor, the processor is caused to execute the steps of the above-mentioned method for detecting a code merging state. The steps of the method for detecting a code merging state here may be the steps of the method for detecting a code merging state in each of the above embodiments.

[0105] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use, and processing of the relevant data need to comply with the relevant regulations.

[0106] Those of ordinary skill in the art can understand that all or part of the processes in the methods of the above embodiments can be completed by instructing relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above methods. Among them, any reference to a memory, database, or other medium used in the embodiments provided in the present application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetoresistive random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc. The databases involved in the embodiments provided in the present application can include at least one of relational databases and non-relational databases. Non-relational databases can include distributed databases based on blockchain, etc., without limitation. The processors involved in the embodiments provided in the present application can be general-purpose processors, central processors, graphics processors, digital signal processors, programmable logic devices, data processing logics based on quantum computing, artificial intelligence (AI) processors, etc., without limitation.

[0107] The technical features of the above embodiments can be combined arbitrarily. For the sake of concise description, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, it should be considered as the scope recorded in the present application.

[0108] The above-described embodiments merely represent several implementation manners of the present application. The description thereof is relatively specific and detailed, but it should not be construed as a limitation on the scope of the patent of the present application. It should be noted that for those of ordinary skill in the art, without departing from the concept of the present application, several modifications and improvements can still be made, and these all fall within the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the appended claims.

Claims

1. A method for detecting the code merging state, characterized in that, The method includes: Synchronously saving the commit objects existing in the branch code in the remote repository to the local; the commit object is the core data structure that records a code change in a distributed version control system; each of the commit objects has a corresponding commit identifier; Obtaining a first set of commit objects and a second set of commit objects; the first set of commit objects includes the commit objects that exist in the mainline code of the remote repository and do not exist locally; the second set of commit objects includes the commit objects that exist locally and do not exist in the mainline code of the remote repository; including: obtaining the commit history of the remote repository; the commit history includes the record information of the commit objects existing in the mainline code of the remote repository; determining the first set of commit objects and the second set of commit objects according to the commit history; Detecting whether the branch code in the local has been merged into the mainline code in the remote repository according to the data relationship between the commit content associated with the first set of commit objects and the commit content associated with the second set of commit objects; wherein, in the case that the first set of content identifiers is a subset of the second set of content identifiers, it is determined that the branch code in the local has been merged into the mainline code in the remote repository; in the case that the first set of content identifiers is not a subset of the second set of content identifiers, it is determined that the branch code in the local has not been merged into the mainline code in the remote repository; Wherein, the first set of content identifiers includes the content identifiers corresponding to the commit objects in the first set of commit objects; the second set of content identifiers includes the content identifiers corresponding to the commit objects in the second set of commit objects; the content identifier is a unique identifier used to represent the commit content associated with the commit object.

2. The method according to claim 1, wherein The detecting whether the branch code in the local has been merged into the mainline code in the remote repository according to the data relationship between the commit content associated with the first set of commit objects and the commit content associated with the second set of commit objects includes: Obtaining the content identifiers corresponding to the commit objects in the first set of commit objects to obtain the first set of content identifiers, and obtaining the content identifiers corresponding to the commit objects in the second set of commit objects to obtain the second set of content identifiers; Detecting whether the branch code in the local has been merged into the mainline code in the remote repository according to the set relationship between the first set of content identifiers and the second set of content identifiers.

3. The method according to claim 2, wherein The obtaining the content identifiers corresponding to the commit objects in the first set of commit objects to obtain the first set of content identifiers includes: Obtaining the commit content corresponding to the commit objects in the first set of commit objects; Performing a hash process on the commit content corresponding to the commit objects in the first set of commit objects to generate a unique content code corresponding to the commit objects in the first set of commit objects; Uniquely encode the content corresponding to each submission object in the first submission object set as the content identifier corresponding to each submission object in the first submission object set, and obtain the first content identifier set.

4. The method according to claim 2, wherein The obtaining the content identifier corresponding to each submission object in the second submission object set to obtain the second content identifier set includes: Obtain the submission content corresponding to each submission object in the second submission object set; Perform a hashing process on the submission content corresponding to each submission object in the second submission object set to generate a unique content encoding corresponding to each submission object in the second submission object set; Use the unique content encoding corresponding to each submission object in the second submission object set as the content identifier corresponding to each submission object in the second submission object set, and obtain the second content identifier set.

5. A code merging status detection device, characterized in that, The device includes: A synchronization module, configured to synchronously save the submission objects existing in the branch code in the remote repository to the local; the submission object is the core data structure that records a code change in a distributed version control system; each of the submission objects has a corresponding submission identifier; An obtaining module, configured to obtain a first submission object set and a second submission object set; the first submission object set includes submission objects that exist on the mainline code of the remote repository and do not exist locally; the second submission object set includes submission objects that exist locally and do not exist on the mainline code of the remote repository; The obtaining module is specifically configured to obtain the submission history of the remote repository; the submission history includes the record information of the submission objects existing on the mainline code of the remote repository; according to the submission history, determine the first submission object set and the second submission object set; A detection module, configured to detect whether the branch code in the local has been merged into the mainline code in the remote repository according to the data relationship between the submission content associated with the first submission object set and the submission content associated with the second submission object set; Wherein, the detection module is specifically configured to, in the case that the first content identifier set is a subset of the second content identifier set, determine that the branch code in the local has been merged into the mainline code in the remote repository; in the case that the first content identifier set is not a subset of the second content identifier set, determine that the branch code in the local has not been merged into the mainline code in the remote repository; Wherein, the first content identifier set includes the content identifiers corresponding to each submission object in the first submission object set; the second content identifier set includes the content identifiers corresponding to each submission object in the second submission object set; the content identifier is a unique identifier used to characterize the submission content associated with the submission object.

6. The device according to claim 5, characterized in that The detection module is used to obtain the content identifiers corresponding to the submission objects in the first submission object set to obtain the first content identifier set, and obtain the content identifiers corresponding to the submission objects in the second submission object set to obtain the second content identifier set; and detect whether the branch code in the local has been merged into the main line code in the remote repository according to the set relationship between the first content identifier set and the second content identifier set.

7. A computer device, comprising a memory and a processor, the memory storing a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 4.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the method according to any one of claims 1 to 4.

9. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the method according to any one of claims 1 to 4.

Images