A code merging method and device, electronic equipment and storage medium

Abstract

The application provides a code merging method and device, electronic equipment and a storage medium. The method comprises the following steps: if a demand number set is not empty, then according to each target demand number in the demand number set, a picking type merging manner is used to merge the code submitted by a source branch corresponding to a source branch identifier in a first warehouse to a target branch corresponding to a target branch identifier in the first warehouse; if the demand number set is empty, then according to the reference identifier of the source branch in the first warehouse, a full-amount merging manner is used to merge the code submitted by the source branch in the first warehouse to the target branch in the first warehouse; after the code merging is completed, the latest code under the target branch in the first warehouse is pushed to a second warehouse, and the code synchronization update of the second warehouse is completed. After the code merging operation is completed in the first warehouse based on the demand number and is updated to the second warehouse for code storage, the merging efficiency and precision are improved.

Description

Technical Field

[0001] This invention relates to the field of software development, and more specifically, to a code merging method, apparatus, electronic device, and storage medium. Background Technology

[0002] In enterprise software development, developers typically commit code to one or more requirements on their respective source branches. These commits eventually need to be merged into a target branch (such as an integration branch or a release branch). Current practices generally rely on manual selection of the merging method (merge, rebase, cherry-pick, etc.) and manual judgment of "which commits belong to a certain requirement", "whether the target branch already contains commits for that requirement", and "which commits have not yet been merged".

[0003] However, manually filtering unmerged commits becomes complex and error-prone when the source branch contains multiple intertwined commits or the target branch already contains some historical commits with the same requirements. Summary of the Invention

[0004] In view of this, the purpose of this application is to provide a code merging method, apparatus, electronic device and storage medium that can complete the code merging operation in the first repository based on the demand number and then update it to the second repository for code storage, thereby improving merging efficiency and accuracy.

[0005] In a first aspect, embodiments of this application provide a code merging method, the method comprising: Obtain the target merged document created by the target user; the target merged document includes a source branch identifier, a target branch identifier, and a set of requirement numbers; Determine whether the set of demand numbers in the target merged document is empty; If the set of requirement numbers is not empty, then based on each target requirement number in the set of requirement numbers, the code submitted by the source branch corresponding to the source branch identifier in the first warehouse is merged into the target branch corresponding to the target branch identifier in the first warehouse using a pick-and-match merge method. If the set of requirement numbers is empty, then based on the reference identifier of the source branch in the first repository, the code submitted by the source branch in the first repository is merged into the target branch in the first repository using a full merge method. After the code merge is complete, the latest code under the target branch in the first repository is pushed to the second repository to complete the code synchronization update of the second repository.

[0006] In one possible implementation, the target merged document is created through the following steps; In response to the merge creation request initiated by the target user, the merge attribute information input by the target user is validated from at least one preset validation dimension to obtain the validation result of at least one preset validation dimension; the merge attribute information includes the source branch identifier, the target branch identifier, the set of requirement numbers, and the project identifier; If all verification results are successful, the target merged document is created based on the merged attribute information.

[0007] In one possible implementation, if the preset verification dimension is branch validity verification, requirement legality verification, or binding relationship verification, then the merged attribute information input by the user is verified from at least one preset verification dimension to obtain the verification result of at least one preset verification dimension, including: Based on the preset branch set corresponding to the project identifier, the branch validity is verified for the source branch corresponding to the source branch identifier and the target branch corresponding to the target branch identifier, and the branch validity verification result is obtained. And / or, under the target project corresponding to the project identifier, perform a legality check on the target requirement corresponding to the target requirement number to obtain a legality check result; And / or, perform a binding relationship verification between the target requirement corresponding to the target requirement number in the set of requirement numbers and the source branch to obtain a binding verification result.

[0008] In one possible implementation, before creating the target merged document based on the merged attribute information, the method further includes: Under the target project corresponding to the project identifier, query the current existence status of other merge documents that are merged based on the source branch corresponding to the source branch identifier and / or the target branch corresponding to the target branch identifier; If at least one other merged document is currently in a conflict or merging state, the creation process of the target merged document is terminated. If all other merged documents are currently in the "completed" state, then continue with the creation process of the target merged document.

[0009] In one possible implementation, the step of merging the code submitted by the source branch corresponding to the source branch identifier in the first repository into the target branch corresponding to the target branch identifier in the first repository using a pick-and-match merge method based on each target requirement number in the requirement number set includes: Based on the target requirement number, retrieve the last commit time of the target branch from the first repository; In the source branch of the first repository, the first commit sequence to be merged is retrieved based on the target requirement number, and the commit time is later than the last commit time. A pick-and-match merge method is used to merge the code in the first sequence of commit files to be merged into the target branch in the first repository.

[0010] In one possible implementation, the method further includes: If the last commit time of the target branch is not found, then the second commit sequence to be merged in the source branch is retrieved based on the target requirement number. Using a pick-and-match merge method, the code in the second commit sequence to be merged is merged into the target branch in the first repository.

[0011] In one possible implementation, the method further includes: If a code conflict is detected during the code merging process, the existence status of the target merge document is updated to conflicting; the first commit information that triggered the code conflict is written to the temporary merge record table to generate a first record; and the first record is marked as conflicting. If the current merge method is a pick-and-match merge, then the second submission information that has not yet started merging will be written into the temporary merge record table in sequence to generate a second record; and the second record will be marked as pending merging. After the code conflict is manually resolved, the merging process continues based on the records stored in the temporary merge record table.

[0012] Secondly, embodiments of this application also provide a code merging apparatus, the apparatus comprising: The acquisition module is used to acquire the target merged document created by the target user; the target merged document includes a source branch identifier, a target branch identifier, and a set of requirement numbers. The judgment module is used to determine whether the set of demand numbers in the target merged document is empty; The merging module is used to merge the code submitted by the source branch corresponding to the source branch identifier in the first warehouse into the target branch corresponding to the target branch identifier in the first warehouse, based on each target requirement number in the requirement number set and using a picking-style merging method, if the requirement number set is not empty. The merging module is further configured to, if the set of requirement numbers is empty, merge the code submitted by the source branch in the first repository into the target branch in the first repository using a full merge method based on the reference identifier of the source branch in the first repository. The push module is used to push the latest code under the target branch in the first repository to the second repository after the code merge is completed, so as to complete the code synchronization update of the second repository.

[0013] Thirdly, embodiments of this application also provide an electronic device, including: a processor, a storage medium, and a bus, wherein the storage medium stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to perform the steps of the code merging method as described in any of the first aspects.

[0014] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the code merging method as described in any of the first aspects.

[0015] This application provides a code merging method, apparatus, electronic device, and storage medium. The method includes: if the set of requirement numbers is not empty, merging the code submitted by the source branch corresponding to the source branch identifier in the first repository into the target branch corresponding to the target branch identifier in the first repository using a pick-and-choose merging method based on each target requirement number in the requirement number set; if the set of requirement numbers is empty, merging the code submitted by the source branch in the first repository into the target branch in the first repository using a full merging method based on the reference identifier of the source branch in the first repository; after the code merging is completed, pushing the latest code under the target branch in the first repository to a second repository to complete the code synchronization update of the second repository. This application completes the code merging operation based on the requirement number in the first repository and then updates the code storage in the second repository, improving merging efficiency and accuracy. Attached Figure Description

[0016] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 A flowchart of a code merging method provided in an embodiment of this application is shown; Figure 2 This illustration shows a schematic diagram of a merged document provided in an embodiment of this application; Figure 3 A schematic diagram of the termination creation process provided in an embodiment of this application is shown; Figure 4This paper shows a schematic diagram of the structure of a code merging device provided in an embodiment of this application; Figure 5 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It should be understood that the accompanying drawings in this application are for illustrative and descriptive purposes only and are not intended to limit the scope of protection of this application. Furthermore, it should be understood that the schematic drawings are not drawn to scale. The flowcharts used in this application illustrate operations implemented according to some embodiments of this application. It should be understood that the operations in the flowcharts may not be implemented in sequence, and steps without logical contextual relationships may be reversed or implemented simultaneously. In addition, those skilled in the art, guided by the content of this application, may add one or more other operations to the flowcharts, or remove one or more operations from the flowcharts.

[0019] Furthermore, the described embodiments are merely some, not all, of the embodiments of this application. The components of the embodiments of this application described and illustrated herein can typically be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely to illustrate selected embodiments of the application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0020] To enable those skilled in the art to utilize the content of this application, and in conjunction with the specific application scenario of "software development," the following implementation methods are provided. For those skilled in the art, the general principles defined herein can be applied to other embodiments and application scenarios without departing from the spirit and scope of this application. Although this application is primarily described within the "software development field," it should be understood that this is merely an exemplary embodiment.

[0021] It should be noted that the term "comprising" will be used in the embodiments of this application to indicate the presence of the features declared thereafter, but does not exclude the addition of other features.

[0022] In enterprise software development, developers typically commit code to one or more requirements on their respective source branches, ultimately merging these commits into a target branch (e.g., integration or release branch). Current practices generally rely on manual selection of the merging method (merge, rebase, cherry-pick, etc.) and manual judgment of "which commits belong to a specific requirement," "whether the target branch already contains commits for that requirement," and "which commits have not yet been merged." When the source branch contains multiple intertwined commits related to different requirements, or when the target branch already contains historical commits for some of the same requirements, manually filtering unmerged commits becomes complex and error-prone.

[0023] Furthermore, when merge conflicts occur, the common practice is for developers to resolve the conflicts locally and continue merging. However, the lack of a systematic "conflict intermediate state record", "continuation merge mechanism for incomplete submissions", and "merging document status control" makes the process untraceable and uncontrollable, affecting delivery efficiency and quality.

[0024] In summary, the existing technology has the following defects: (1) The scope of merging is difficult to be precise: manual screening of relevant submissions based on submission history is prone to omission or misselection, resulting in functional loss or introduction of non-target code. (2) The merging process is untraceable: the lack of status management of "merging documents / records" makes it impossible to clearly present the merging progress, conflict location, and remaining unmerged submission set. (3) Conflict handling lacks a closed loop: after a conflict occurs, the "conflicted submissions" and "subsequent submissions to be merged" cannot be structurally saved, making it difficult to restore the site and continue merging. (4) High risk of concurrent merging: when multiple merging requests are initiated simultaneously for the same project, they are prone to mutual interference, causing process chaos or inconsistent code status.

[0025] In view of this, this application's embodiments are geared towards the business scenario of "code merging by requirement dimension." It introduces a merge document (including source branch, target branch, requirement number set, merge number, etc.) to uniformly manage merge tasks. When a requirement number set is specified, the system automatically identifies unmerged commit sequences based on the last commit record of that requirement in the target branch and subsequent commits related to that requirement in the source branch, and performs a pick-and-match merge on the target branch in sequence. When no requirement number set is specified, a branch-level full merge is performed on the source branch on the target branch, automatically generating a merge commit or determining that it is already in the latest state, thereby achieving automatic merging of the overall changes to the source branch. In the event of a conflict, it simultaneously supports both pick-and-match merge conflicts and full merge conflicts: it provides a list of conflicting files and the ability to retrieve their content, supporting the rewriting and submission of manually confirmed file content. For pick-and-match merge conflicts, the system automatically continues merging the remaining unprocessed commits after submitting a conflict fix. For full merge conflicts, the system completes the process loop after submitting a merge fix, ultimately pushing the target branch and updating the merge document status.

[0026] The following is a detailed description of a code merging method provided in an embodiment of this application.

[0027] Reference Figure 1 The diagram shown is a flowchart of a code merging method provided in an embodiment of this application. The exemplary steps of this embodiment are described below: S101. Obtain the target merge document created by the target user; the target merge document includes a set of source branch identifiers, target branch identifiers, and requirement numbers.

[0028] In this application's implementation, the "target merge document" describes the code merge task. The target merge document includes at least a merge number, a merge topic, a source branch identifier, a target branch identifier, a set of requirement numbers (which can be empty), a project identifier, and a merge description. The merge number can be generated using a time series to ensure uniqueness and traceability. Here, a branch refers to an independent development copy of the code in Git. The code merge task is to merge the code in the source branch corresponding to the source branch identifier into the target branch corresponding to the target branch identifier.

[0029] For example, refer to Figure 2 The image shown is a schematic diagram of the merged documents provided in an embodiment of this application. Figure 2 Each row in the table represents a merged document. The first column represents the merge number of the corresponding merged document (e.g., R20260326154805), the second column represents the merge subject of the corresponding merged document (e.g., panel merge), the third column represents the source branch identifier of the corresponding merged document (e.g., test032402), the fourth column represents the target branch identifier of the corresponding merged document (test0324), and the last column represents the existence status of the corresponding merged document (e.g., conflict, merge completed).

[0030] Specifically, the target merge document is created by following these steps: Step 1: In response to the merge creation request initiated by the target user, validate the merge attribute information input by the target user from at least one preset validation dimension, and obtain the validation results of at least one preset validation dimension; the merge attribute information includes source branch identifier, target branch identifier, requirement number set and project identifier.

[0031] In this embodiment, a multi-dimensional pre-validation mechanism ensures the legality and executability of the code merging task when creating a merge document. The preset validation dimensions can be branch validity validation, requirement legality validation, or binding relationship validation. One or more preset validation dimensions can be selected from these four to validate the merge attribute information input by the target user. The validation logic is as follows: a. Based on the preset branch set corresponding to the project identifier, perform branch validity verification on the source branch corresponding to the source branch identifier and the target branch corresponding to the target branch identifier, and obtain the branch validity verification result.

[0032] In this embodiment, a branch information table is maintained to record the source branches and target branches belonging to each project, and a preset project identifier and a preset branch identifier are stored accordingly. All preset branch identifiers corresponding to the project identifier in the merge attribute information are queried from the branch information table to obtain a preset branch set. If the preset branch set contains the source branch corresponding to the source branch identifier in the merge attribute information and the target branch corresponding to the target branch identifier, the branch validity verification result is that the verification passed; otherwise, the branch validity verification result is that the verification failed.

[0033] b. and / or, under the target project corresponding to the project identifier, perform a legality check on the target requirement corresponding to the target requirement number, and obtain the legality check result.

[0034] In this application implementation, each project corresponds to at least one requirement. If the target requirement exists under the target project corresponding to the project identifier, and the current status of the target requirement is a mergeable status (such as under development status), then the legality verification result is that the verification passes; otherwise, the legality verification result is that the verification fails, so that requirements in an illegitimate state cannot be included in the merging scope.

[0035] c. and / or, perform binding relationship verification on the target requirement corresponding to the target requirement number in the requirement number set and the source branch, and obtain the binding verification result.

[0036] In this embodiment, a relationship table is maintained to store the binding relationships between each requirement and branch. If the relationship table stores a binding relationship between the target requirement and the source branch, the binding verification result is "verified"; otherwise, the binding verification result is "failed," so that unbound requirements are intercepted and the erroneous merging of cross-branch requirements is avoided.

[0037] Branches are used to develop requirements that are tied to them.

[0038] Here, all the above verifications are completed based on the system's business database, without needing to access the underlying code repository; by verifying the existence of branches, the validity and status of requirements, and the binding relationship between requirements and source branches, the legality and compliance of merged documents are ensured.

[0039] In addition, before creating the target merged document based on the merged attribute information, concurrency control needs to be implemented through an engineering-level merged status verification mechanism. The implementation process is as follows: a. Under the target project corresponding to the project identifier, query the current existence status of other merge documents that are merged based on the source branch corresponding to the source branch identifier and / or the target branch corresponding to the target branch identifier.

[0040] In this application's implementation, a project can correspond to one or more merge documents; query the current existence status of other merge documents under the target project that execute code merging tasks using source branches and / or target branches.

[0041] b. If at least one other merged document is currently in a conflict or merging state, the creation process of the target merged document shall be terminated.

[0042] In this embodiment, if the status of other merged documents is "in conflict," it indicates that there are unresolved merge conflicts within the target project, and the creation of a new merged document using the source branch and target branch will be terminated. If the status of other merged documents is "merging," it indicates that there is a merge task currently being executed using the source branch and target branch within the target project, and the creation process will also be terminated. Therefore, if at least one other merged document is currently in a state of conflict or merging, the creation process of the target merged document will be terminated.

[0043] For example, refer to Figure 3 The diagram shown is a schematic representation of the termination creation process provided in an embodiment of this application.

[0044] c. If all other merged documents are currently in the "completed" state, then continue with the creation process of the target merged document.

[0045] In this application implementation, a new merge submission task is only allowed when there are no other merge documents currently in a "conflicting" or "merging" state. This ensures that the merging process under the same project is executed serially, avoids concurrent conflicts, and ensures the consistency and controllability of the merging status.

[0046] Step 2: If all verification results are successful, create the target merge document based on the merge attribute information.

[0047] Furthermore, this application embodiment constructs a local Git repository on the server as the execution carrier for branch merging. The local Git repository path is designed in a three-level hierarchy: repository user, project, and engineering. Repository users are used to isolate the main operation entity, project identifiers are used to isolate business modules, and engineering identifiers are used to isolate the code repository, ensuring that merging operations involving multiple users, projects, and engineerings are independent and do not affect each other. For example, Zhang San's online food delivery platform project has a front-end project for ordering and a back-end project for order processing. The back-end project for ordering includes requirements for adding coupon deduction functionality and optimizing automatic cancellation of orders after timeout. One user corresponds to multiple projects, one project corresponds to one or more engineering processes, one engineering process corresponds to one or more requirements, and one requirement corresponds to one or more branches.

[0048] After the target merge document is created, the local Git repository is located as the first repository based on the three-level path of the target user, target project (i.e., the project described in the target engineering), and target engineering. If the first repository has not yet been initialized, a clone operation is performed from the second repository (such as a remote code repository) using the target user's authentication credentials; if the first repository already exists, the existing directory is reused; then, the latest code under the source branch in the second repository is synchronized to the source branch in the first repository; and the latest code under the target branch in the second repository is synchronized to the target branch in the first repository.

[0049] Here, a full synchronization is performed between the source and target branches: First, the remote branch metadata is fetched, then the corresponding branch is switched to and the latest remote code is synchronized, ensuring that the local branch data remains in sync with the remote. The entire branch merging and conflict detection process is completed in the local repository, effectively reducing the concurrent access pressure and data anomaly risk of the remote repository. Code changes are only pushed to the remote target branch after the merge operation is successfully completed.

[0050] S102. Determine whether the set of requirement numbers in the target merged document is empty.

[0051] In this application implementation, after the developer completes the development of the corresponding requirement in the designated branch, the submission information is prefixed with the requirement number that was completed; when initiating the target merge document and executing the merge operation, two different submission identification strategies are adopted based on whether the set of requirement numbers in the merge document is empty.

[0052] S103. If the set of requirement numbers is not empty, then based on the target requirement numbers in the set of requirement numbers, the code submitted by the source branch corresponding to the source branch identifier in the first warehouse is merged into the target branch corresponding to the target branch identifier in the first warehouse using a pick-and-match merge method.

[0053] In this embodiment of the application, when the set of demand numbers is not empty, the merging task is performed through the following steps: Step 1: Based on the target requirement number, retrieve the last commit time of the target branch from the first repository.

[0054] In this embodiment of the application, within the target branch of the first repository, the last commit record of the target requirement in the target branch is retrieved by using the target requirement number as a prefix, so as to obtain the last commit time / commit information corresponding to each target requirement number.

[0055] Step 2: In the source branch of the first repository, retrieve the first commit sequence to be merged whose commit time is later than the last commit time based on the target requirement number; In the embodiments of this application, for each target requirement code, if the last commit time corresponding to the target requirement code is found, then under the source branch of the first repository, the first set of commits that start with the target requirement number and whose commit time is later than the last commit time is retrieved, and the first commits in the first set of commits are sorted by commit time to form a first sequence of commits to be merged that can be repeatedly executed.

[0056] In Git, a commit sequence refers to a pre-arranged, ordered set of commits; a commit is the smallest snapshot of code changes created by a developer, serving as the fundamental unit for storing code changes. A single commit contains complete information: a unique commit ID, all modified files, added or removed code, the committer, the commit time, and a comment. A commit can modify one or more files; a single development project often produces multiple commits.

[0057] Step 3: Using a pick-and-match merge method, merge the code in the first sequence of commits to be merged into the target branch in the first repository, so that the target branch only introduces commits that are related to the specified requirements and have not yet been merged.

[0058] In this embodiment, the pick-and-match merge method is a code merging strategy that uses a single commit as the smallest merging unit. According to a commit sequence formed by a preset order, it selects individual commits from the source branch one by one and migrates the code changes corresponding to each commit to the target branch in sequence. The merging process is executed serially. If any commit triggers a conflict, the merging process is paused, and the unexecuted subsequent commits are retained for subsequent merging.

[0059] Additionally, if the last commit time of the target branch is not found, the second commit sequence to be merged within the source branch is retrieved based on the target requirement number; the code in the second commit sequence to be merged is merged into the target branch in the first repository using a pick-and-match merge method.

[0060] In this embodiment, for each target requirement code, if the last commit time corresponding to the target requirement code is not found, a second set of commits starting with the target requirement code is selected under the source branch of the first repository. The second commits in the second set are sorted by commit time to form a second sequence of commits to be merged that can be repeatedly executed. The code in the second sequence of commits to be merged is merged into the target branch of the first repository using a pick-and-match merge method, so that the target branch only introduces commits related to the specified requirement that have not yet been merged.

[0061] S104. If the set of requirement numbers is empty, then based on the reference identifier of the source branch in the first repository, the code submitted by the source branch in the first repository will be merged into the target branch in the first repository using the full merge method.

[0062] In this implementation, when the set of requirement numbers is empty, a full merge is performed. The process is as follows: First, switch to the target branch and resolve the reference identifier (source branch HEAD) of the source branch in the first repository. Initiate a branch-level merge operation to merge the entire source branch into the target branch. The merge strategy adopts a recursive merge strategy and automatically generates a merge commit (if the target branch already contains the content of the source branch, it is determined that no merge is needed, and this step ends directly).

[0063] Here, the full merge method is a code merging strategy that uses the entire branch as the merging unit: it obtains the common fork node between the source branch and the target branch, calculates all the code changes accumulated on the source branch after the two branches forked, and performs a unified comparison and merge operation between all changes and the code on the target branch, rather than migrating them one commit at a time; after the comparison, all file conflicts are identified at once, the entire merge process is interrupted, and there is no batch merge commit queue; after all conflicts are manually fixed and a merge commit is generated, the entire set of branch changes are fully merged into the target branch, and the merge process loop ends.

[0064] Furthermore, this application embodiment designs a conflict intermediate state recording and a continue-merging mechanism for conflict scenarios during the merging process: Step 1: If a code conflict is detected during the code merging process, update the existence status of the target merge document to "in conflict"; write the first commit information that triggered the code conflict into the temporary merge record table to generate the first record; and mark the first record as conflicted.

[0065] In this embodiment, when a merge operation detects a conflict or failure, the existence status of the target merge document is first updated to "in conflict" to prevent new merge tasks from being initiated under the same project. Subsequently, a temporary merge record is created, which will trigger the first commit message of the code conflict. The first submission information refers to the submission information where the conflict occurs, including the submission ID, submission time, and user.

[0066] Step 2: If the merging method is a pick-and-match merging, then write the second submission information that has not yet started merging into the temporary merging record table in sequence to generate the second record; and mark the second record as pending merging status.

[0067] Here, the full merge does not involve sequential execution of each commit. There is no commit queue, and each commit is processed without regard to order. Conflict triggering occurs as follows: The source branch is determined to be merged entirely into the target branch, tracing back to the baseline node where the two branches initially separated; all code changes accumulated from all commits since the source branch forked are packaged into a single overall change set; this overall change set is then globally compared with the existing code on the target branch; after the comparison, all code conflict locations are identified at once: conflicts arise from code differences caused by the superposition of multiple commits, and no single commit is locked as a conflict breakpoint; if any conflict is detected, the entire merge process is immediately halted, and no code is merged; all commits are not executed one by one, there are no successfully merged commits, and no commits are queued for execution; all conflicts generated by this merge must be manually corrected, and only after submitting the merge node will all changes from the four commits be merged into the target branch at once, completing the merge.

[0068] However, pick-and-pick merges strictly follow a preset order, executing each commit sequentially without skipping steps. Assuming a pre-arranged commit queue: commit 1—commit 2—commit 3—commit 4, each commit is cherry-picked in that order; commit 1 is executed first: no conflicts, merge successful; commit 2 is executed: a code conflict occurs, and the process immediately terminates; commits 3 and 4 have not yet been merged and therefore will not generate any conflicts. Therefore, if this merge is a pick-and-pick merge, the information of any second commits that have not yet been merged must be written into a temporary merge record table to generate a second record; and this second record must be marked as pending merge.

[0069] Furthermore, after completing the status recording, an exception is thrown and the automatic merging process is stopped. The user is then asked to manually resolve the conflict before the merging operation is resumed from the breakpoint based on the temporary record.

[0070] In addition, this application provides the ability to obtain conflict details; the conflict file list provides the current version content of the target branch (ours), the content of the commit version to which the conflict was introduced (theirs), and the content of the conflict files in the merge workspace (local, including conflict markers), for presentation on the front end and manual selection.

[0071] Step 3: After the code conflict is manually resolved, continue the merging process based on the records stored in the temporary merge record table.

[0072] In this implementation, the system receives a set of "conflicting file paths + resolved file content" submitted by the front end; updates the existence status of the target merged document to "merging"; writes the resolved content back to the merge work area and adds it to the temporary storage area one by one; performs a single commit to complete the database entry of the conflict submission; deletes records marked as conflicting or pending merge status from the temporary merge record table; and continues to perform a pick-and-match merge on the previously saved "submission sequence of pending merge status" until the merge is completed.

[0073] Here, during the merge, the merged content in the merge workspace is first written to the staging area. After the merge is complete, the content in the staging area is written to the target branch.

[0074] Optionally, after the merge is completed, the method further includes: if the target merge document contains a set of requirement numbers, then binding the target requirements that are in the allowed stage and are not bound to the target branch with the target branch to avoid duplicate binding. If the target merge document contains a set of requirement numbers, then all requirements associated with the source branch (that meet the allowed stage status) are synchronously bound to the target branch to achieve consistency maintenance of "code merging and requirement flow".

[0075] S105. After the code merge is complete, push the latest code from the target branch in the first repository to the second repository to complete the code synchronization update in the second repository.

[0076] In this implementation, when the merge process is conflict-free and the commit sequence is completed, the target branch is pushed to the remote code repository. After a successful push, the merge document status is updated to "Merge Completed," forming a complete closed loop from "Create—Merge in Progress—Conflict in Progress / Merge Completed."

[0077] In summary, the combined approach of "unmerged commit identification based on requirement number + selective merging + conflict intermediate state + continue merging mechanism + status closed-loop control" achieves the following main effects: 1. Precise and controllable merging scope: When a requirement number is specified, only commits corresponding to that requirement that have not yet been merged into the target branch are merged, avoiding the introduction of non-target code and significantly reducing the risk of erroneous merging. 2. Traceable and manageable process: Using the merge document as the business carrier, merge numbers, branches, requirement sets, status changes, and results are managed uniformly, improving visualization and auditability. 3. Closed-loop and recoverable conflict handling: When a conflict occurs, the conflicting commits and remaining commits to be merged are structurally saved, supporting automatic continuation of remaining commits after resolving the conflict, avoiding manual repetitive screening of the commit sequence. 4. Reduced risk of concurrent merging: Through project-level merge status constraints, the chaos and data inconsistencies caused by multiple incomplete merge tasks existing simultaneously in the same project are avoided. 5. Enhanced consistency of requirement flow: After the merge is completed, the binding relationship between "requirement and target branch" is updated synchronously, ensuring consistency between code delivery and requirement management, reducing manual maintenance costs.

[0078] Based on the same inventive concept, this application also provides a code merging device corresponding to the code merging method. Since the principle of the device in this application is similar to the code merging method described above, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0079] Reference Figure 4 The diagram shown is a schematic of a code merging apparatus provided in an embodiment of this application. The apparatus includes: The acquisition module 401 is used to acquire the target merged document created by the target user; the target merged document includes a source branch identifier, a target branch identifier, and a set of requirement numbers. The judgment module 402 is used to determine whether the set of demand numbers in the target merged document is empty; The merging module 403 is used to merge the code submitted by the source branch corresponding to the source branch identifier in the first warehouse into the target branch corresponding to the target branch identifier in the first warehouse, based on each target requirement number in the requirement number set according to the requirement number set, using a picking-style merging method if the requirement number set is not empty. The merging module 403 is further configured to, if the set of requirement numbers is empty, merge the code submitted by the source branch in the first repository into the target branch in the first repository using a full merge method based on the reference identifier of the source branch in the first repository. The push module 404 is used to push the latest code under the target branch in the first repository to the second repository after the code merge is completed, so as to complete the code synchronization update of the second repository.

[0080] In one possible implementation, the acquisition module 401 is specifically used to create the target merge document through the following steps: in response to the merge creation request initiated by the target user, the merge attribute information input by the target user is validated from at least one preset validation dimension to obtain the validation result of at least one preset validation dimension; the merge attribute information includes the source branch identifier, the target branch identifier, the set of requirement numbers, and the project identifier; if all validation results are valid, the target merge document is created based on the merge attribute information.

[0081] In one possible implementation, the preset verification dimension is branch validity verification, requirement legality verification, or binding relationship verification. The acquisition module 401 is specifically used to perform branch validity verification on the source branch corresponding to the source branch identifier and the target branch corresponding to the target branch identifier based on the preset branch set corresponding to the project identifier, and obtain a branch validity verification result; and / or, under the target project corresponding to the project identifier, perform legality verification on the target requirement corresponding to the target requirement number, and obtain a legality verification result; and / or, perform binding relationship verification on the target requirement corresponding to the target requirement number in the requirement number set and the source branch, and obtain a binding verification result.

[0082] In one possible implementation, the acquisition module 401 is specifically used to query the current existence status of other merge documents that are merging codes based on the source branch corresponding to the source branch identifier and / or the target branch corresponding to the target branch identifier under the target project corresponding to the project identifier before creating the target merge document based on the merge attribute information; if at least one other merge document is currently in conflict or merging, the creation process of the target merge document is terminated; if all other merge documents are currently in completed status, the creation process of the target merge document continues.

[0083] In one possible implementation, the merging module 403 is specifically used to retrieve the last commit time of the target branch from the first repository based on the target requirement number; in the source branch in the first repository, retrieve the first sequence of commits to be merged whose commit time is later than the last commit time based on the target requirement number; and use a pick-and-match merging method to merge the code in the first sequence of commits to be merged into the target branch in the first repository.

[0084] In one possible implementation, the merge module 403 is further configured to, if the last commit time of the target branch is not found, retrieve the second commit sequence to be merged within the source branch based on the target requirement number; and merge the code in the second commit sequence to be merged into the target branch in the first repository using a pick-and-match merge method.

[0085] In one possible implementation, the apparatus further includes: a conflict handling module 405; the conflict handling module 305 is specifically configured to, if a code conflict is detected during the code merging process, update the existence status of the target merge document to "in conflict"; write the first submission information that triggered the code conflict into a temporary merge record table to generate a first record; and mark the first record as a conflict state; if the current merging method is a pick-and-match merge, write the second submission information that has not yet started merging into the temporary merge record table in sequence to generate a second record; and mark the second record as a pending merge state; after the code conflict is manually resolved, continue the merging process according to the records stored in the temporary merge record table.

[0086] like Figure 5 As shown in the embodiment of this application, an electronic device 500 includes a processor 501, a memory 502, and a bus. The memory 502 stores machine-readable instructions executable by the processor 501. When the electronic device is running, the processor 501 communicates with the memory 502 via the bus, and the processor 501 executes the machine-readable instructions to perform the steps of the code merging method described above.

[0087] Specifically, the memory 502 and processor 501 mentioned above can be general-purpose memory and processor, without any specific limitations. When the processor 501 runs the computer program stored in the memory 502, it can execute the above code merging method.

[0088] Corresponding to the above code merging method, this application embodiment also provides a computer-readable storage medium storing a computer program, which, when run by a processor, executes the steps of the above code merging method.

[0089] In summary, the embodiments of this application provide a code merging device that completes the code merging operation in the first repository based on the requirement number and then updates it to the second repository for code storage, thereby improving merging efficiency and accuracy.

[0090] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems and devices described above can be referred to the corresponding processes in the method embodiments, and will not be repeated here. In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed mutual coupling or direct coupling or communication connection can be through some communication interfaces; the indirect coupling or communication connection of devices or modules can be electrical, mechanical, or other forms.

[0091] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0092] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0093] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the 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 cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0094] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A code merging method, characterized in that, The method includes: Obtain the target merged document created by the target user; the target merged document includes a source branch identifier, a target branch identifier, and a set of requirement numbers; Determine whether the set of demand numbers in the target merged document is empty; If the set of requirement numbers is not empty, then based on each target requirement number in the set of requirement numbers, the code submitted by the source branch corresponding to the source branch identifier in the first warehouse is merged into the target branch corresponding to the target branch identifier in the first warehouse using a pick-and-match merge method. If the set of requirement numbers is empty, then based on the reference identifier of the source branch in the first repository, the code submitted by the source branch in the first repository is merged into the target branch in the first repository using a full merge method. After the code merge is complete, the latest code under the target branch in the first repository is pushed to the second repository to complete the code synchronization update of the second repository.

2. The code merging method according to claim 1, characterized in that, The target merged document is created by following these steps; In response to the merge creation request initiated by the target user, the merge attribute information input by the target user is validated from at least one preset validation dimension to obtain the validation result of at least one preset validation dimension; the merge attribute information includes the source branch identifier, the target branch identifier, the set of requirement numbers, and the project identifier; If all verification results are successful, the target merged document is created based on the merged attribute information.

3. The code merging method according to claim 2, characterized in that, The preset verification dimensions are branch validity verification, requirement legality verification, or binding relationship verification. Therefore, the merged attribute information input by the user is verified from at least one preset verification dimension to obtain the verification result of at least one preset verification dimension, including: Based on the preset branch set corresponding to the project identifier, the branch validity is verified for the source branch corresponding to the source branch identifier and the target branch corresponding to the target branch identifier, and the branch validity verification result is obtained. And / or, under the target project corresponding to the project identifier, perform a legality check on the target requirement corresponding to the target requirement number to obtain a legality check result; And / or, perform a binding relationship verification between the target requirement corresponding to the target requirement number in the set of requirement numbers and the source branch to obtain a binding verification result.

4. The code merging method according to claim 2, characterized in that, Before creating the target merged document based on the merged attribute information, the method further includes: Under the target project corresponding to the project identifier, query the current existence status of other merge documents that are merged based on the source branch corresponding to the source branch identifier and / or the target branch corresponding to the target branch identifier; If at least one other merged document is currently in a conflict or merging state, the creation process of the target merged document is terminated. If all other merged documents are currently in the "completed" state, then continue with the creation process of the target merged document.

5. The code merging method according to any one of claims 1 to 4, characterized in that, The step of merging the code submitted by the source branch corresponding to the source branch identifier in the first repository into the target branch corresponding to the target branch identifier in the first repository, based on each target requirement number in the requirement number set and using a pick-and-match merge method, includes: Based on the target requirement number, retrieve the last commit time of the target branch from the first repository; In the source branch of the first repository, the first commit sequence to be merged is retrieved based on the target requirement number, and the commit time is later than the last commit time. A pick-and-match merge method is used to merge the code in the first commit sequence to be merged into the target branch in the first repository.

6. The code merging method according to claim 5, characterized in that, The method further includes: If the last commit time of the target branch is not found, then the second commit sequence to be merged in the source branch is retrieved based on the target requirement number. Using a pick-and-match merge method, the code in the second commit sequence to be merged is merged into the target branch in the first repository.

7. The code merging method according to claim 1, characterized in that, The method further includes: If a code conflict is detected during the code merging process, the existence status of the target merge document is updated to conflicting; the first commit information that triggered the code conflict is written to the temporary merge record table to generate a first record; and the first record is marked as conflicting. If the current merge method is a pick-and-match merge, then the second submission information that has not yet started merging will be written into the temporary merge record table in sequence to generate a second record; and the second record will be marked as pending merging. After the code conflict is manually resolved, the merging process continues based on the records stored in the temporary merge record table.

8. A code merging device, characterized in that, The device includes: The acquisition module is used to acquire the target merged document created by the target user; the target merged document includes a source branch identifier, a target branch identifier, and a set of requirement numbers. The judgment module is used to determine whether the set of requirement numbers in the target merged document is empty; The merging module is used to merge the code submitted by the source branch corresponding to the source branch identifier in the first warehouse into the target branch corresponding to the target branch identifier in the first warehouse, based on each target requirement number in the requirement number set and using a picking-style merging method, if the requirement number set is not empty. The merging module is further configured to, if the set of requirement numbers is empty, merge the code submitted by the source branch in the first repository into the target branch in the first repository using a full merge method based on the reference identifier of the source branch in the first repository. The push module is used to push the latest code under the target branch in the first repository to the second repository after the code merge is completed, so as to complete the code synchronization update of the second repository.

9. An electronic device, characterized in that, include: The device includes a processor, a storage medium, and a bus, wherein the storage medium stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the storage medium via the bus, and the processor executes the machine-readable instructions to perform the steps of the code merging method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of the code merging method as described in any one of claims 1 to 7.

Images