Change record merging method, system, device, storage medium and program product

Abstract

The present disclosure relates to the technical field of computers, and provides a change record merging method, system, device, storage medium and program product. The change record merging method comprises the following steps: first, obtaining a set of to-be-merged change records containing submitter identifiers and associated submission information; when a target change record in the set meets a preset proxy submission feature, parsing an actual initiator identifier from the associated submission information of the target change record according to a preset rule; and then, taking the actual initiator identifier as the basis, determining whether the target change record is included in a merging operation, and completing the merging of the target change record included. The present disclosure can accurately identify the actual initiator in the proxy submission scenario, thereby improving the accuracy of change record merging screening.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, specifically to methods, systems, devices, storage media, and program products for merging change records. Background Technology

[0002] In large-scale project development, parallel development by multiple teams is common, often requiring frequent merge operations between different branches to maintain branch synchronization. However, current changelog merging schemes have the following shortcomings: when changelogs are submitted by automated proxy accounts or intermediary accounts, existing merge filtering mechanisms rely solely on the committer identifier on the changelog for scope determination, making it difficult to effectively attribute and filter changelogs generated by automated proxy accounts. This results in a large number of changelogs that do not conform to the target branch merging strategy being incorrectly included in the merge scope. Consequently, the version control server needs to perform additional file difference comparisons, conflict detection, and file synchronization operations for a large number of changelogs that should not participate in the merge, significantly increasing the server's unnecessary computational load and network transmission overhead, and easily leading to subsequent erroneous merge results and retry rollback costs. Therefore, there is an urgent need for a changelog merging method that can improve the accuracy of merge filtering and reduce the server's data processing pressure in proxy commit scenarios. Summary of the Invention

[0003] This disclosure provides a method, system, device, storage medium, and program product for merging change records to solve the problem of low accuracy in filtering change record merging in related technologies.

[0004] Firstly, this disclosure provides a method for merging change records, the method comprising: Obtain the set of change records to be merged. Each change record in the set of change records to be merged must contain at least the submitter identifier and associated submission information. When the target change record in the set of change records to be merged meets the preset proxy submission characteristics, the actual initiator identifier is extracted from the associated submission information of the target change record according to the preset rules. Based on the actual initiator's identifier, determine whether the target change record is involved in the merge operation, and perform the merge on the target change records involved in the merge operation.

[0005] Secondly, this disclosure provides a change record merging system, which includes: The acquisition module is used to acquire a set of change records to be merged. Each change record in the set of change records to be merged must contain at least the submitter's identifier and associated submission information. The extraction module is used to extract the actual initiator identifier from the associated submission information of the target change record according to preset rules when the target change record in the set of change records to be merged meets the preset proxy submission characteristics. The merge execution module is used to determine whether the target change record should participate in the merge operation based on the actual initiator identifier, and to perform the merge on the target change records that participate in the merge operation.

[0006] Thirdly, this disclosure provides an electronic device, including: a memory and a processor, which are communicatively connected to each other. The memory stores computer instructions, and the processor executes the computer instructions to perform the change record merging method of the first aspect or any corresponding embodiment described above.

[0007] Fourthly, this disclosure provides a computer-readable storage medium storing computer instructions for causing a computer to execute the change record merging method of the first aspect or any corresponding embodiment described above.

[0008] Fifthly, this disclosure provides a computer program product, including computer instructions for causing a computer to execute the change record merging method described in the first aspect or any corresponding embodiment thereof.

[0009] The change record merging method provided in this disclosure obtains a set of change records to be merged, including at least the submitter's identifier and associated submission information, providing subsequent judgment steps with basic information for parsing and utilization. When a target change record meets preset proxy submission characteristics, the actual initiator's identifier is extracted from its associated submission information according to preset rules. This allows the method to penetrate the submission actions proxies by intermediaries, shifting the judgment basis from the surface-level submitter's identifier to the underlying actual initiator's identifier. Furthermore, based on the extracted actual initiator's identifier, the method determines whether the target change record participates in the merging operation and performs merging on the target change records participating in the operation, ensuring that the merging screening result corresponds to the actual ownership of the change record. Therefore, in scenarios involving proxy submissions, this method improves the accuracy of change record merging screening and reduces the possibility of incorrect or missed screening caused by relying solely on the surface-level submitter's identifier. Attached Figure Description

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

[0011] Figure 1 This is a schematic diagram illustrating an application scenario according to an embodiment of this disclosure; Figure 2 This is a schematic flowchart of a first method for merging change records according to an embodiment of this disclosure; Figure 3 This is a second flowchart illustrating the change record merging method according to an embodiment of the present disclosure; Figure 4 This is a schematic diagram of the relevant technical integration process according to the embodiments of this disclosure; Figure 5 This is a schematic diagram of a multi-dimensional filtration pipeline according to an embodiment of the present disclosure; Figure 6 This is a schematic diagram of an event-driven pluggable notification architecture according to an embodiment of this disclosure; Figure 7 This is a structural block diagram of a change record merging system according to an embodiment of the present disclosure; Figure 8 This is a schematic diagram of the hardware structure of an electronic device according to an embodiment of this disclosure. Detailed Implementation

[0012] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0013] It should be noted that the information (including but not limited to user input information, such as information entered into input boxes), data (including but not limited to data used for analysis, stored data, and displayed data, such as context code, all code of the current project, service pressure corresponding to operations performed on all code of the current project, and code development status of the current project), and signals involved in this disclosure are all authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data must comply with relevant laws, regulations, and standards. For example, the context code, operations performed on all code of the current project, the corresponding service pressure, and code development status involved in this disclosure were all obtained with full authorization.

[0014] The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In this disclosure, "a plurality of" means two or more, unless otherwise expressly specified.

[0015] Before providing a detailed description of the embodiments of this disclosure, some of the nouns and terms involved in the embodiments of this disclosure will be explained.

[0016] (1) Perforce (P4): A centralized version control system, often used for the unified management of code and game assets in large-scale projects such as game development.

[0017] (2) Helix Swarm: a version control system and its code review product.

[0018] (3) Changelist (CL): The smallest commit unit in P4 used to track file changes. Each CL has a unique number and corresponds to a commit action.

[0019] (4) Stream (P4 stream): P4's branching model is similar to the concept of branches in other version control systems. It can be divided into different types such as mainline, development, and release.

[0020] (5) Workspace: The working area where developers map files in P4 depot locally.

[0021] (6) Partitioned Workspace: A lightweight workspace mode provided by P4 that allows merge operations to be performed without merging the entire branch file.

[0022] (7) Depot: The central storage area in P4 used to store all file versions.

[0023] (8) Clean Architecture: A layered architecture pattern based on the dependency inversion principle, which makes the core business logic independent of the specific framework and external technology implementation.

[0024] (9) Domain-driven design: a software design method that takes business domain as its core.

[0025] (10) Use Case: The core unit of the application layer, used to encapsulate a complete business operation.

[0026] (11) Repository: In Domain-Driven Design, it is used to encapsulate data access objects. In this solution, IP4Repository is the repository abstract interface.

[0027] (12) EventBus: An event distribution mechanism based on the publish-subscribe model.

[0028] (13) P4Python: The Python language API provided by P4, used to call P4 commands in Python programs.

[0029] (14) Typer: A Python framework for building command line interfaces (CLI).

[0030] (15) Rich: A Python library for outputting formatted content such as colored logs, tables, and panels in the terminal.

[0031] (16) CI / CD: Continuous Integration / Continuous Deployment refers to the engineering practice of automatically executing build, test and deployment after code submission through an automated pipeline.

[0032] (17) Jenkins / TeamCity: Two commonly used CI / CD systems.

[0033] (18) Agent: The agent node in the CI / CD system that executes specific build tasks.

[0034] (19) REST API / RESTful API: Application programming interfaces based on the HTTP protocol and using the Uniform Resource Interface style.

[0035] (20) SMTP (Simple Mail Transfer Protocol): A protocol used to send emails.

[0036] (21)IM (Instant Messaging): A communication method used for sending and receiving messages in real time, such as POPO IM and other enterprise instant messaging systems.

[0037] (22) Robomerge: An automatic merging tool for Unreal Engine projects.

[0038] (23) Issue (work order) / Redmine: Issue refers to defect tracking or task tracking work order; Redmine is an open source project management and defect tracking system.

[0039] (24) RestX server: can be used as a backend web server for merging data aggregation points.

[0040] (25) P4 command terms: integrate (integrate, merge changes from one branch into another branch), resolve (resolve conflicts), submit (commit), revert (roll back), interchanges (query unmerged CLs between source and target branches), filelog (query file history change records), opened (query open files), shelve (shelve).

[0041] (26) Pending CL: CLs that have been created but not yet officially submitted.

[0042] (27) __getattr__: An attribute access interception mechanism in Python that executes custom processing logic when accessing object attributes.

[0043] (28) delete-then-readd: A continuous history mode in version control where a file is first deleted and then added to the same path.

[0044] As one optional application scenario of this disclosure embodiment, such as Figure 1 As shown, this change record merging method can be applied to a system consisting of at least one terminal device and at least one server. Figure 1 The system is illustrated in the example, which includes a computer 101, a mobile terminal 102, and a server 103, and the terminal devices such as the computer 101 and the mobile terminal 102 are connected to the server 103 through a network 110.

[0045] Specifically, the terminal device can be a smartphone, tablet, laptop, PDA, desktop computer, game console, smart TV, smart wearable device, in-vehicle terminal, VR (Virtual Reality) device, AR (Augmented Reality) device, etc. Server 103 can be a standalone physical server, a server cluster, a distributed system, or a cloud server providing cloud services. Network 110 can be a wired or wireless network, examples of which include, but are not limited to, the Internet, corporate intranet, local area network, wide area network, mobile communication network, and combinations thereof.

[0046] In this application scenario, the terminal device can be used by the submitter to submit change records to the server 103, and the server 103 can be used to obtain and merge the set of change records to be merged. The change record merging method provided in this embodiment can be executed independently by the server 103, executed by the terminal device, or executed collaboratively by the terminal device and the server 103. This embodiment does not limit the execution of the change records.

[0047] In related technologies, when change records are submitted by automated proxy accounts or transit accounts, existing merge filtering mechanisms only rely on the submitter identifier carried on the surface of the change record to determine the scope. This makes it difficult to effectively attribute and filter change records generated by automated proxy accounts, resulting in a large number of change records that do not conform to the target branch merge strategy being incorrectly included in the merge scope. This disclosure provides a change record merging method to improve the accuracy of change record merging filtering in scenarios where proxy submissions exist.

[0048] According to an embodiment of this disclosure, a change record merging method embodiment is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0049] This embodiment provides a change record merging method, which can be used for the aforementioned servers (such as independent physical servers, server clusters, distributed systems, or cloud servers providing cloud services, etc.), as well as for the aforementioned terminal devices or relay devices located between the terminal devices and the servers. In the following description, the server is used as the execution subject, but this does not constitute a limitation on the protection scope of the embodiments disclosed herein. Figure 2 This is a flowchart of a change record merging method according to an embodiment of this disclosure, such as... Figure 2 As shown, the process includes the following steps: Step S201: Obtain the set of change records to be merged. Each change record in the set of change records to be merged contains at least the submitter's identifier and associated submission information.

[0050] The "change record" involved in this step refers to the smallest record unit used to record a single modification. Each change record corresponds to a commit action.

[0051] "Set of Change Records to be Merged" refers to a set of several change records that are currently awaiting merge processing. The number of change records can be one or more.

[0052] "Submitter ID" is information used to uniquely identify a submitter, such as the submitter's username, user ID, or other unique identifier.

[0053] "Associated submission information" is text information used to describe the content, source, or context of this change. It can be text freely filled in by the developer or structured or semi-structured text generated according to a specific template.

[0054] The "acquisition" action involved in this step refers to the process by which the executing entity obtains the set of change records to be merged. The specific acquisition method can be that the executing entity actively initiates a query request to the data source and receives the returned set, or the data source actively pushes it to the executing entity. This step does not limit the acquisition method, as long as the executing entity ultimately holds the set of change records to be merged that can be processed in subsequent steps.

[0055] For example, after receiving the merge task, the executing entity initiates a query to the storage of change records and obtains a set of change records to be merged, which contains several change records. Each change record carries at least a submitter identifier field (such as user_A) and an associated submission information field (such as a text describing the content of this modification).

[0056] Step S202: When the target change record in the set of change records to be merged meets the preset proxy submission characteristics, the actual initiator identifier is extracted from the associated submission information of the target change record according to the preset rules.

[0057] The “target change record” involved in this step refers to a specific change record that is currently being processed from the set of change records to be merged. When the executing entity processes the set of change records to be merged one by one, the change record targeted by each processing can be used as the target change record.

[0058] "Proxy submission characteristic" refers to a change record that is not submitted directly by the actual initiator, but rather through an intermediary account. In change records that meet the proxy submission characteristic, the account recorded in the submitter identifier is not the actual initiator of the change, but rather an intermediary account acting as a forwarder or proxy.

[0059] "Actual Initiator Identifier" refers to the account identifier that actually initiated this change. This identifier is not directly recorded in the submitter identifier field, but is embedded in the text content of the associated submission information in a specific format.

[0060] "Preset rules" refer to rules that are predetermined to identify and extract the actual initiator's identifier from the associated submission information. These rules can take the form of keyword matching rules, regular expression rules, specific field extraction rules, or parsing rules based on fixed templates.

[0061] The "extraction" action involved in this step refers to the process of parsing the associated submission information according to preset rules, based on the premise that the target change record meets the preset proxy submission characteristics, to obtain the actual initiator's identifier. For example, if the submitter identifier of a change record is an proxy account, and its associated submission information contains the original submitter information recorded in a specific format, then the executing entity will parse out the original submitter's account identifier according to preset rules, and use it as the actual initiator's identifier.

[0062] For example, suppose the pre-configured proxy submission features of the executing entity include the identifier "merge_bot". When the submitter identifier of the target change record is "merge_bot", it is determined that it meets the pre-configured proxy submission features, thereby triggering the extraction action. The executing entity parses the associated submission information (e.g., "user:zhangsan, ...") according to the pre-configured rules (e.g., matching the string following the "user:" field) and extracts "zhangsan" as the actual initiator identifier of the target change record.

[0063] It should be noted that if the submitter identifier of the target change record does not meet the preset proxy submission characteristics, the extraction action in this step will not be triggered, and the target change record will directly enter the subsequent judgment stage.

[0064] Step S203: Based on the actual initiator identifier, determine whether the target change record is involved in the merge operation, and perform the merge on the target change records involved in the merge operation.

[0065] The "merge operation" involved in this step refers to the process of merging the modifications recorded in the change log into the target object. The result is that the target object includes the modifications from the change log after the merge is completed.

[0066] The action of "determining whether the target change record is included in the merge operation and performing the merge on the target change record that is included in the merge operation" involved in this step refers to the process of determining whether the target change record is included in the scope of this merge operation based on the actual initiator's identifier. The determination can be made based on the comparison result of the actual initiator's identifier with a certain preset condition, such as comparing whether the actual initiator's identifier falls within or outside a certain pre-configured range; the action of "performing the merge" refers to implementing the merge operation on the target change record that has been determined to be included in the merge operation.

[0067] For example, regarding the target change record with the actual initiator identifier "zhangsan" extracted in step S202, the executing entity makes a determination based on this actual initiator identifier. If the determination result is that the target change record participates in the merge operation, then the merge operation is performed on the target change record; if the determination result is that the target change record does not participate in the merge operation, then the target change record is skipped and the merge operation is not performed on it. It should be noted that the determination basis mentioned in this step is the actual initiator identifier extracted in step S202, rather than the original submitter identifier (i.e., the proxy account identifier), thereby switching the merge determination basis from the submitter identifier carried on the target change record surface to the actual initiator identifier located behind it.

[0068] In summary, the change record merging method provided in this disclosure obtains a set of change records to be merged, including at least the submitter identifier and associated submission information, providing subsequent judgment steps with basic information for parsing and utilization. When a target change record meets preset proxy submission characteristics, the actual initiator identifier is extracted from its associated submission information according to preset rules. This allows the method to penetrate the submission actions performed by intermediary submitters, shifting the judgment basis from the surface-level submitter identifier to the underlying actual initiator identifier. Furthermore, based on the extracted actual initiator identifier, the method determines whether the target change record participates in the merging operation and performs merging on the target change records participating in the merging operation, ensuring that the merging screening result corresponds to the actual ownership of the change record. Therefore, in scenarios involving proxy submissions, this method improves the accuracy of change record merging screening and reduces the possibility of incorrect or missed screening caused by judging solely based on the surface-level submitter identifier.

[0069] This embodiment provides a change record merging method, which can be used for the aforementioned servers (such as independent physical servers, server clusters, distributed systems, or cloud servers providing cloud services, etc.), as well as for the aforementioned terminal devices or relay devices located between the terminal devices and the servers. In the following description, the server is used as the execution subject, but this does not constitute a limitation on the protection scope of the embodiments disclosed herein. Figure 3 This is a flowchart of a change record merging method according to an embodiment of this disclosure, such as... Figure 3 As shown, the process includes the following steps: Step S301: Obtain the set of change records to be merged. Each change record in the set must contain at least the submitter's identifier and associated submission information. For details, please refer to [link to relevant documentation]. Figure 2 Step S201 of the illustrated embodiment will not be described again here.

[0070] After obtaining the set of change records to be merged, for each change record in the set, it can be further identified whether it has proxy commit characteristics, so as to carry out differentiated processing in the future.

[0071] Regarding the method for determining proxy commit characteristics, in one optional implementation, the following two types of rules can be used to determine whether the target change record meets the preset proxy commit characteristics: First, determine whether the submitter identifier of the target change record belongs to the preset set of proxy submitter identifiers. This set is pre-configured by the administrator and records known proxy account identifiers, such as the account name of the automation script, the account name of the synchronization tool, etc.

[0072] Secondly, it determines whether the submitter's identifier of the target change record conforms to the preset proxy account naming rules. These rules check the format of the account identifier by pattern matching. For example, if the account identifier starts with a specific prefix or suffix, it is identified as a proxy account.

[0073] The two types of rules mentioned above can be used individually or in combination. As long as either one is met, the change record can be determined to have proxy submission characteristics. By combining these two identification methods—a preset set of proxy submitter identifiers and proxy account naming rules—it can adapt to the diverse naming formats of proxy accounts in different projects, thereby improving the identification coverage.

[0074] Step S302: When the target change record in the set of change records to be merged meets the preset proxy submission characteristics, the actual initiator identifier is extracted from the associated submission information of the target change record according to the preset rules.

[0075] As an optional implementation, extracting the actual initiator identifier from the associated submission information of the target change record according to preset rules can include the following two scenarios: when the associated submission information matches a preset string extraction pattern, the actual initiator identifier is extracted from the associated submission information according to the string extraction pattern; or, when the associated submission information matches a preset description pattern, the processor identifier associated with the description pattern is used as the actual initiator identifier.

[0076] Among them, "string extraction mode" refers to a pre-configured mode for identifying and extracting the string corresponding to the actual initiator's identifier from the associated submission information. For example, it can be a matching rule based on keywords and delimiters, or a matching rule based on regular expressions.

[0077] "Description pattern" refers to the feature pattern of the overall submitted information that corresponds to a certain type of business scenario; "processor identifier" refers to the identifier that is pre-designated as the processor for a certain type of business scenario.

[0078] For example, in the first scenario, the preset string extraction pattern can be to match fields that start with a specific keyword and end with a delimiter or a string. In this case, if the associated submission information is "user:zhangsansubmitted via merge_bot", then "zhangsan" can be extracted as the actual initiator identifier. The preset string extraction pattern can also be a matching rule based on other starting keywords (such as keywords that represent fast merging or synchronous operation).

[0079] In the second scenario, the preset description pattern can be an overall description feature corresponding to a certain fixed business scenario, and the processor identifier associated with the description pattern can be a pre-specified identifier of the person responsible for handling such business scenarios. When the associated submission information is matched with a certain description pattern, the processor identifier associated with the description pattern can be directly used as the actual initiator identifier.

[0080] By configuring the two implementation methods mentioned above concurrently, the extraction of the actual initiator identifier can take into account both the precise extraction based on general string features and the associated assignment based on business scenario features, thereby improving the ability of the extraction action to adapt to different forms of associated submission information.

[0081] Considering that not all associated submission information can successfully extract the actual initiator identifier according to the above preset rules, as an optional implementation method, when the actual initiator identifier cannot be extracted from the associated submission information of the target change record according to the preset rules, it can be determined whether the associated submission information matches the preset release mode: when the associated submission information matches the release mode, the target change record is allowed to participate in the merge operation; when the associated submission information does not match the release mode, the target change record is not allowed to participate in the merge operation.

[0082] Among them, "release mode" refers to the feature mode pre-configured to determine whether the target change record can still participate in the merge operation when the actual initiator's identifier cannot be successfully extracted. Its form can be keyword mode, regular expression mode or other form of feature mode.

[0083] For example, suppose the preset release mode is "the associated submission information contains a specific keyword". When the submitter identifier of a target change record belongs to the set of intermediate submitter identifiers, but the executing entity fails to extract the actual initiator identifier from the associated submission information of the target change record, the executing entity further checks whether the associated submission information contains the specific keyword. If it does, the target change record is allowed to participate in the merge operation; if it does not, the target change record is not allowed to participate in the merge operation.

[0084] The above implementation method can provide a fallback decision path based on the release mode for the extraction of target change records that fail, avoiding the situation where all relevant target change records are not merged simply because of extraction failure.

[0085] Step S303: Based on the actual initiator identifier, determine whether the target change record is involved in the merge operation, and perform the merge on the target change records involved in the merge operation.

[0086] As an optional implementation method for determining whether a target change record should participate in the merge operation based on the actual initiator's identifier, the criterion can be whether the actual initiator's identifier meets the proxy submission characteristics. Specifically: when the actual initiator's identifier does not meet the preset proxy submission characteristics, it indicates that the actual initiator is a real operator account rather than a proxy account, and the target change record is determined to participate in the merge operation; when the actual initiator's identifier meets the preset proxy submission characteristics, it indicates that the account extracted from the associated submission information is still a proxy account (e.g., in the case of multi-level proxy forwarding), and the target change record is determined not to participate in the merge operation, thus avoiding the merging of change records with unclear sources.

[0087] For example, following the previous example, if the actual initiator identifier "zhangsan" extracted from "user:zhangsan submitted via merge_bot" does not meet the preset proxy submission characteristics, the target change record is determined to participate in the merge operation; if the extracted actual initiator identifier still meets the preset proxy submission characteristics (e.g., another intermediary account), the target change record is determined not to participate in the merge operation.

[0088] The above implementation method can further identify multi-level transit scenarios from intermediary submitter to intermediary submitter, and avoid misjudging target change records that should not be involved in the merge as being involved in the merge operation in multi-level proxy submission scenarios.

[0089] Furthermore, before performing the merging step on the target change records involved in the merging operation, the target change records can be filtered to exclude them from the merging operation.

[0090] Filtering processes may include at least one of the following: The target change record is filtered based on the preset whitelist range. When the target change record is not in the whitelist range, the target change record is determined to be a match for the filter. The target change record is filtered based on the preset change record blacklist. When the target change record is in the change record blacklist, it is determined that the target change record has been filtered. The target change records are filtered based on a preset user blacklist. When the submitter of the target change record is identified in the user blacklist, the target change record is determined to have met the filtering criteria. The target change record is filtered based on a preset description regular expression pattern. When the associated submission information of the target change record matches the description regular expression pattern, the target change record is determined to have met the filtering process.

[0091] Among them, "change record whitelist range" refers to a pre-configured range or set of change records that are allowed to participate in the merge, such as a range of change record numbers; "change record blacklist" refers to a pre-configured list of change records that are not allowed to participate in the merge; "user blacklist" refers to a pre-configured list of submitter identifiers that are not allowed to participate in the merge for the change records they submit; and "description regular expression pattern" refers to one or more pre-configured regular expression patterns for filtering change records with specific descriptive features.

[0092] For example, when filtering based on a whitelist of change records, assuming the whitelist ranges from 1000 to 2000, a change record with the number 999 will be considered a match for filtering. When filtering based on a blacklist of change records, if the blacklist contains a specific number or range and the target change record's number falls within that range, it will be considered a match for filtering. When filtering based on a user blacklist, if the submitter's identifier for the target change record matches an identifier in the user blacklist, it will be considered a match for filtering. When filtering based on a descriptive regular expression pattern, if the associated submission information of the target change record matches a preset regular expression pattern (e.g., a pattern containing specific keywords), it will be considered a match for filtering.

[0093] It should be noted that the above four filtering dimensions can be used individually or executed sequentially in any combination; when using a multi-dimensional combination, the judgment results of each dimension can be combined in a "any hit is filtered" logical combination manner.

[0094] By introducing the above filtering process, target change records that should not be included in the merge can be screened from multiple dimensions such as the scope of change records, the list of change records, the user list, and the characteristics of associated submission information before the merge is executed, thereby further reducing unnecessary merge processing and improving the targeting of merge processing.

[0095] Step S304: Perform conflict resolution on the conflicting files.

[0096] As an optional implementation of merging target change records involved in the merge operation, the following sub-steps can be performed for each target change record: Create a change record to be committed on the target branch, which is the branch to which the merge operation is directed; Integrate the changes to files on the source branch involved in the target change record into the change record to be committed, and determine whether there are conflicting files in the change record to be committed. The source branch is the branch to which the target change record belongs, and the conflicting files are files that conflict with the modifications on the source branch and the modifications on the target branch. When there are conflicting files in the change log to be submitted, conflict resolution is performed on the conflicting files; Check for unresolved conflicts in the pending change log; if no unresolved conflicts exist, commit the pending change log to the target branch; if unresolved conflicts exist, roll back all changes involved in the pending change log.

[0097] Here, "target branch" and "source branch" are relative concepts. A branch can be understood as a parallel modification path for the same target object. "Change record to be committed" is a container of change records created on the target branch to hold the changes involved in this merge, but which has not yet been formally committed. "Integration" refers to the process of introducing changes from files on the source branch into the change record to be committed. "Conflicting file" refers to a file in which there is a conflict between the modifications to the same file on the source branch and the target branch. "Conflict resolution" refers to the process of determining the content of conflicting files after the merge according to certain rules. "Unresolved conflict" refers to a conflict that has not been eliminated after performing conflict resolution. "Rollback" refers to the process of undoing all changes made in the change record to be committed and restoring the target branch to the state before the start of this merge.

[0098] For example, suppose the target branch is "main" and the source branch is "dev". The target change record involves modifications to several files on the "dev" branch. The execution entity first creates an uncommitted change record on the "main" branch, and then integrates the corresponding modifications on the "dev" branch into this uncommitted change record. If, during the integration process, some files are found to have been modified simultaneously on both branches and the modifications conflict, these files are marked as conflicting files and conflict resolution is performed. After conflict resolution, it further checks whether there are still unresolved conflicts in the uncommitted change record. If not, the uncommitted change record is committed to the "main" branch, making the merge finally effective. If conflicts exist, all changes involved in the uncommitted change record are rolled back, including undoing the modifications already made and deleting the uncommitted change record itself.

[0099] By implementing the above method, it is possible to avoid submitting incomplete or problematic merge results to the target branch when unresolved conflicts occur.

[0100] Furthermore, conflict resolution for conflicting files can be performed in a tiered manner: for files in the conflicting files that belong to the preset file blacklist, the target branch version of the files in the preset file blacklist is retained as the conflict resolution result; for files in the conflicting files that do not belong to the preset file blacklist, the conflict is resolved according to the preset conflict resolution strategy; for files that still have conflicts after being resolved according to the conflict resolution strategy, a secondary conflict resolution based on the file history pattern is performed.

[0101] The "preset file blacklist" refers to a pre-configured list of files that should not be overwritten by the source branch version. Files listed in this list will have their target branch version retained when a merge conflict occurs. The "target branch version" refers to the version of the file on the target branch, while the "source branch version" refers to the version of the file on the source branch. The "conflict resolution strategy" refers to a pre-configured strategy for conflicting files that determines the outcome of the conflict resolution.

[0102] For example, the default file blacklist may contain the paths or extensions of certain critical files that should not be modified or overwritten by the source branch. When a conflicting file falls into the blacklist, the target branch version is directly retained as the result of conflict resolution. When a conflicting file does not fall into the blacklist, it is processed according to the default conflict resolution strategy. If there are still unresolved conflicts after processing according to the strategy, a secondary conflict resolution based on the file history pattern is further executed.

[0103] By adopting the above-mentioned hierarchical processing method, critical documents can be given priority protection when merging conflicts, routine documents can be processed according to a unified strategy, and complex documents can be handled by a secondary resolution mechanism, thereby improving the overall coverage and adaptability of conflict resolution.

[0104] Among them, resolving conflicts according to the preset conflict resolution strategy can take different approaches depending on the type of strategy: If the conflict resolution strategy is type 1, then when the modifications on the source branch and the modifications on the target branch in the conflict file do not overlap, the modifications on the source branch and the modifications on the target branch will be merged into the conflict file.

[0105] If the conflict resolution strategy is type 2, the source branch version of the conflicting file is retained as the conflict resolution result; if the conflict resolution strategy is type 3, the target branch version of the conflicting file is retained as the conflict resolution result.

[0106] The first type of strategy corresponds to the automatic merging process provided that the modification areas of the two branches do not overlap; the second type of strategy corresponds to the process of directly using the source branch version as the final result; the third type of strategy corresponds to the process of directly using the target branch version as the final result; non-overlapping means that there is no intersection between the modification areas on the source branch and the modification areas on the target branch.

[0107] For example, for a file modified simultaneously by two branches: if the strategy used is type 1, and the two branches modified different lines of the file respectively, and the modified areas do not overlap, then the modifications of the two branches are merged into the file; if the strategy used is type 2, then the version on the source branch is directly used as the final content of the file after merging; if the strategy used is type 3, then the version on the target branch is directly used as the final content of the file after merging.

[0108] By providing the above three strategy types, the conflict resolution strategy can have multiple optional processing directions, such as automatic merging under the premise of non-overlapping, focusing on the source branch, and focusing on the target branch, so as to make it easier to flexibly select the appropriate strategy for different business scenarios.

[0109] For files that still have conflicts after being resolved according to the conflict resolution strategy, secondary conflict resolution can be performed based on the file history pattern. Specifically, the process is as follows: obtain the historical change records of the files that still have conflicts; when there is a record in the historical change records where a file that still has conflicts was first deleted and then re-added, retain the source branch version of the file that still has conflicts as the conflict resolution result.

[0110] Among them, "historical change record" refers to a sequence of several change records accumulated in the version control system for the target file; "deleted and then added" refers to a continuous sequence of records in the historical change record where the file was first deleted and then added to the same path.

[0111] For example, for a file that still has conflicts after being processed according to the preset conflict resolution strategy, the executing entity obtains the file's historical change record in the version control system. If there is a sequence of records in the historical change record where the file was first deleted and then re-added, it can be determined that the file belongs to the "deleted and re-added" mode. In this case, the source branch version is directly retained as the conflict resolution result, so that the secondary conflict resolution can cover the conflict scenarios corresponding to this type of historical mode.

[0112] By introducing secondary conflict resolution based on file history patterns, a special type of conflict that is difficult to handle by preset conflict resolution strategies due to the break in file version lineage can be included in the scope of automatic resolution, further improving the coverage of automatic conflict resolution.

[0113] In addition, as an optional implementation method, a mechanism for detecting the risk of missing merges can be introduced during the merge process. Specifically, the number of files actually processed in conflict resolution is compared with the number of source files involved in the target change record. When the number of files actually processed is inconsistent with the number of source files, it is determined that there is a risk of missing merges in the target change record and the level of the risk of missing merges is determined.

[0114] Among them, "actual number of files processed" refers to the total number of files actually processed in the conflict resolution process; "source number of files" refers to the total number of files involved in the target change record on the source branch; "risk of missing merge" refers to the risk that some files involved in the target change record may not be processed correctly, resulting in an incomplete merge.

[0115] For example, suppose a target change record involves the modification of 10 files on the source branch, but the number of files actually processed in the conflict resolution phase is 7. If the two are inconsistent, it is determined that the target change record has the risk of being missed in merging, and the level of this risk is further determined.

[0116] By introducing the above detection mechanism, it is possible to detect discrepancies between the number of files to be processed and the actual number of files processed during the merge process, thus preventing incomplete merge results from going unnoticed.

[0117] Furthermore, the level of the risk of missing merge can be determined by referring to whether the associated submission information contains a specific identifier: when the associated submission information of the target change record contains a preset revocation operation identifier, the level of the risk of missing merge is determined to be Level 1; when the associated submission information of the target change record does not contain a preset revocation operation identifier, the level of the risk of missing merge is determined to be Level 2, and Level 2 is higher than Level 1.

[0118] Among them, "cancellation operation identifier" refers to keywords or strings used to indicate that this change belongs to the cancellation operation; the first level and the second level are two levels divided according to the severity of risk.

[0119] For example, the preset undo operation identifier can be a specific keyword used to characterize the undo operation. When the associated commit information contains the identifier, since the number of files may be inconsistent with the expected number when undoing operations are processed across branches, the risk of missing merge is determined to be at a relatively low first level. Conversely, if the associated commit information does not contain the identifier, it may reflect an unexpected processing situation, and the risk of missing merge is determined to be at a relatively high second level.

[0120] By classifying the risks of missing merges for different reasons, we can provide differentiated treatment and avoid over-alarming for inconsistencies in the expected number of files.

[0121] In addition, as an optional implementation, the change record merging method provided in this embodiment can also introduce an event mechanism to respond to changes in the state of the merging operation. Specifically, when a state change occurs in the merging operation, an event corresponding to the state change is generated; and a preset processing action corresponding to the event is executed. The event may include at least one of the following: merge start event, merge success event, merge conflict event, merge exception event, merge completion event, file count inconsistency event, and file lock event.

[0122] Among them, "state change" refers to the change in state of the merge operation during its execution; "event" is an object used to carry state change information; "preset processing action" refers to the action pre-configured for each type of event and triggered when the event occurs; merge start event corresponds to the state at the beginning of the merge operation; merge success event corresponds to the state when a target change record is successfully merged; merge conflict event corresponds to the state when a conflict is detected during the merge process; merge exception event corresponds to the state when an exception occurs during the merge process; merge completion event corresponds to the state when the merge operation is completed; file number inconsistency event corresponds to the state when the actual number of files processed is inconsistent with the number of source files; file lock event corresponds to the state when a file is found to be locked during the merge process.

[0123] For example, a merge start event is generated when a merge operation begins, and the corresponding preset processing action is executed (such as logging, external notification, etc.); a merge success event is generated when a target change record is successfully merged; a merge conflict event is generated when a conflict is detected; a merge exception event is generated when an exception occurs; a merge complete event is generated when the merge is fully completed; a file count discrepancy event is generated when the actual number of files processed is inconsistent with the number of source files; and a file lock event is generated when a file is found to be locked. Each type of event can be associated with its own preset processing action, such as one or more actions such as logging, external notification, and automatic order creation.

[0124] By introducing the aforementioned event mechanism, key state changes during the merging process can be systematically described in the form of events, and responses to various state changes can be made through preset processing actions, thereby improving the overall observability and processability of the merging operation.

[0125] When executing preset processing actions corresponding to an event, at least one target notify can be determined from multiple pre-configured notifyers based on the event type and the target branch to which the target change record belongs. A notifyer is a component responsible for outputting event information to relevant personnel or external systems in a specific manner. Multiple notifyers can be decoupled from the event generation module through a publish-subscribe mechanism, each independently subscribing to the event types it is interested in. Multiple notifyers can include instant messaging notifyers, server callback notifyers, email notifyers, and ticket notifyers.

[0126] The instant messaging notification system formats event information into readable messages and sends them to relevant personnel via the instant messaging system's interface. The server callback notification system, upon successful or completed merging, reports the merge record to the backend management server via an interface call for persistent storage and status panel display. The email notification system sends email notifications to designated recipients via email protocol when error-level events occur. The work order notification system automatically creates follow-up work orders and assigns them to relevant personnel when conflicts, anomalies, or lockouts require manual intervention. Different target branches can independently configure the activation status and notification scope of each notification system to achieve differentiated notification strategies.

[0127] In addition, for merge conflict events, merge exception events, or file lock events, a one-click retry link pointing to the re-merge interface is generated, and the one-click retry link is embedded in the message content of the corresponding output of the target notifier.

[0128] One-click retry link is a Uniform Resource Identifier that contains the parameters required to trigger a re-merge (such as source branch, target branch, change record number, etc.). After receiving a notification message or work order, relevant personnel can directly click the link to trigger the system to re-merge the specified change record without having to manually enter command parameters, thereby speeding up the recovery efficiency after a merge failure.

[0129] In summary, the change record merging method provided in this embodiment detects proxy submission characteristics in the set of change records to be merged and extracts the actual initiator identifier from the associated submission information according to preset rules. This allows the merging process to overcome the obscuring effect of proxy accounts and restore the true submitting entity behind the change records. Based on this, the method determines whether the target change record should participate in the merging operation based on the actual initiator identifier, ensuring that the merging decision is based on accurate entity information. Furthermore, the combination of string extraction mode and description mode can adapt to the diverse proxy submission description formats in actual engineering projects. Simultaneously, the dual identification methods of preset proxy submitter identifier sets and proxy account naming rules, along with a further comparison of the extracted proxy characteristics, can effectively address complex scenarios involving multi-level proxy forwarding.

[0130] Secondly, a multi-dimensional filtering process is introduced before the merge execution. By combining various filtering conditions such as whitelists, blacklists, user blacklists, and descriptive regular expression patterns, changes that should not participate in the merge can be accurately removed before execution, reducing invalid merge operations. During the merge execution process, a hierarchical conflict resolution mechanism is employed, including mandatory retention of the target branch version on a blacklist, differentiated conflict handling based on strategy type, and secondary automatic resolution based on the file history deletion and re-addition pattern. This allows for the protection of customized content for specific files while automating the handling of mainstream conflict types and identifying and automatically resolving special conflicts arising from version lineage breaks, reducing conflict scenarios requiring manual intervention. Furthermore, by comparing the actual number of processed files with the number of source files and combining undo operation identifiers to differentiate different levels of missed merge risks, potential processing omissions can be detected before commit and relevant personnel can be notified with differentiated alert levels, improving the integrity assurance capability of the merge operation. Finally, through an event-driven multi-notifier architecture, corresponding events are automatically generated at each state node during the merging process, and differentiated notification strategies are configured according to event type and target branch. Combined with the automatic generation and embedding of one-click retry links, the response and recovery time after a merge failure is shortened.

[0131] To better illustrate the change record merging method of this disclosure, a preferred embodiment will be provided below. This embodiment is intended to describe the implementation process of this disclosure in detail, but is not intended to limit the scope of protection of this disclosure.

[0132] This preferred embodiment uses a "multi-branch parallel development scenario based on Perforce (P4) as a version control system in a large-scale game development project (e.g., a large-scale game project based on game engines such as Unreal Engine)" as a preferred example for detailed explanation. This scenario was chosen as the preferred example because it places high demands on the automation level of branch merging, branch parallelism, merging completeness, conflict resolution accuracy, and failure response timeliness, thus fully demonstrating the synergistic effect of the various technical features of this solution. It should be noted that this solution is not limited to game development projects; any scenario involving merging branch changes in a version control system can refer to this implementation method. This solution is given in the form of a method, and the corresponding systems, devices, equipment, and computer-readable storage media used to implement this method all fall within the scope of this solution.

[0133] In large-scale game development projects, parallel development by multiple teams is the norm. Developers typically use centralized version control systems such as P4 to manage massive amounts of game assets and code files. A typical project may have dozens of parallel streams, generating hundreds of CLs every day. Frequent merge and copy operations are required between branches to maintain synchronization.

[0134] Figure 4 This is a schematic diagram of the related technology merging process, such as... Figure 4 As shown, developers primarily merge P4 branches using the following methods: manually invoking P4 Streams' built-in merge mechanism via commands, using the Robomerge automatic merge tool triggered by configuration, integrating with CI / CD systems (such as Jenkins or TeamCity with the Perforce plugin and Helix Swarm), manually writing Python or Shell scripts, and using AI-based automatic merge conflict resolution based on Transformer neural networks. These methods generally suffer from common shortcomings in large-scale projects, including high architectural coupling and difficulty in expansion, a lack of intelligent filtering leading to full merges, a single and inflexible notification mechanism, rudimentary workspace management, a lack of merge integrity verification, a lack of refined conflict resolution strategies, and a disconnect between the triggering mechanism and the merge process. Therefore, this embodiment provides the following preferred implementation scheme.

[0135] The change log merging method provided in this embodiment can be divided into three processes: First, a set of change logs awaiting merging is obtained; then, for those change logs that "do not appear to have been submitted by the actual developer," the true initiator is identified from their submission descriptions; finally, based on the identified true initiator, it is determined whether these change logs should be merged into the target object, and the merging of the parts that should be merged is actually performed. The specific process is as follows: This method is not limited to execution by a specific device; servers, terminal devices, or relay devices in between can all serve as the execution subject. In the specific application example of a large-scale game development project, this method can be packaged into a command-line tool and deployed on the Agent node of a CI / CD system such as Jenkins or TeamCity. The Agent node then executes the tool by calling it. The Agent node interacts with the Perforce (P4) server, which serves as the change record storage, via the network and reports the merged results back to the backend intermediate scheduling service (referred to as the RestX server in this example).

[0136] Specifically, the tool's internal software structure adopts a four-layer separation design based on Clean Architecture. From the outside in, it consists of: a presentation layer based on the Typer framework (providing CLI command interfaces and formatted terminal output based on the Rich library); an application layer (dividing several use case classes according to business operations, distributing domain events through the EventBus event bus, and recording step progress through the OperationTracker operation tracker); a domain layer (containing core business objects such as entities, value objects, and domain services, and defining an abstract IP4Repository interface); and an infrastructure layer (providing concrete implementations of the repository interface, notification modules for connecting to external systems, IssueService, and P4CommandProxy for transparent proxying of P4 commands). This design, where the domain layer only depends on the abstract interface and is implemented in reverse by the infrastructure layer, decouples the core method logic from the specific P4 API implementation, facilitating the extension or replacement of the underlying implementation. It should be noted that the above four-layer architecture, CLI / CI / CD deployment method, and specific framework selection are only one optional form of this implementation method and do not limit the scope of implementation of this method.

[0137] First, obtain the set of change records to be merged.

[0138] The purpose of this step is to retrieve a set of change records to be merged from their storage location to the local machine of the executing entity, so that they can be processed in the subsequent two steps. The "change records" referred to here can be understood as a commit record saved by the version control system after each modification made by the developer; "to be merged" means that these records have not yet been merged into the target object and still need to be processed by the executing entity. Each change record must carry at least two basic pieces of information: a committer identifier to uniquely identify who made the commit, and a commit description to describe the content, source, or context of the commit.

[0139] In a specific example of a game development project, the change records to be merged mentioned here are the changelists to be merged in P4. After receiving the merge task, the executing entity first establishes a connection with the P4 server in the priority order of "command line arguments, environment variables, configuration files, and P4Ticket" (this automatic credential acquisition design allows the same code to be run interactively on the engineer's local machine and unattended in the CI / CD pipeline without modification); then, the executing entity creates a temporary partition workspace as the isolation environment for this merge using the naming rule "username_hostname_branch name" (before creation, old format workspaces with timestamp suffixes under the same name rule will be cleaned up, and this temporary workspace will also be automatically cleaned up after the overall merge is completed to avoid leaving residual garbage resources); then, the executing entity uses the P4 command "interchanges -l -f" to query the set of CLs between the source branch and the target branch that have not yet been merged, where each CL carries a committer field (i.e., P4 username) and a description field (i.e., the log text filled in by the developer). The former is the committer identifier mentioned in this step, and the latter is the commit description mentioned in this step. When the user explicitly specifies a range of CL numbers in the command line, this example will further use the @start,end syntax to limit the query range of exchanges to that range in order to improve query efficiency.

[0140] Next, identify the actual initiator in the transit submission scenario.

[0141] This step addresses a scenario where a change record appears to have been submitted by account A, but the actual modification wasn't made by A. A is merely a "proxy committer," while the real change was made by account B. A simply submitted the change to the version control system on B's behalf. This embodiment refers to this "proxy committer" role as a proxy committer. Correspondingly, the identifiers of several such accounts are grouped together to form a proxy committer identifier set. Each element in the set represents a committer who acts as a proxy for the commit action.

[0142] In practice, the executing entity checks each change record in the set to be merged (in this step, the change record being checked is referred to as the target change record). If the committer identifier of a target change record falls within the range of the intermediate committer identifier set, it means that the commit action of this record is likely to have been proxied. At this time, the executing entity further parses the associated commit information of this record according to the pre-configured rules, attempting to identify and extract the actual committer identifier that initiated this modification. This identifier is the actual initiator identifier mentioned in this step. If the committer identifier of the target change record is not in the intermediate committer identifier set, it means that it was directly committed by the real developer, and the above extraction action is not required.

[0143] Continuing with the specific example of game development projects, in the P4 scenario, the so-called intermediary submitter refers to various automated proxy accounts, unified synchronization accounts, or batch processing accounts. In this embodiment, these accounts are collectively referred to as "robot users". Figure 5 This is a schematic diagram of a multi-dimensional filtration pipeline, such as... Figure 5 In the filtering pipeline shown, the first stage, "bot user identification," corresponds to checking whether the submitting user of each CL to be merged is one of the bot users in the bot user list. If so, its log is parsed according to preset rules to extract the real submitter. For example, although a CL shows the submitter as a bot account named "merge_bot," its log contains the phrase "user:zhangsan ...." The executing entity can then determine that the actual initiator of this CL is "zhangsan," and use "zhangsan" as the basis for subsequent judgments, rather than "merge_bot."

[0144] This embodiment provides two optional methods for extracting the actual initiator identifier. You can choose to use one of them or configure both simultaneously.

[0145] The first method is extraction based on string extraction patterns. A pre-defined string format characteristic is established (e.g., starting with a keyword followed by fields of a certain format). When the associated submission information matches this format characteristic, the corresponding field is extracted as the actual initiator identifier according to that format. In a specific example of a game development project, this method corresponds to a set of pre-written parsing rules for the P4 log format. For example, for a log starting with "user:" (e.g., "user:zhangsan submitted via merge_bot"), the rule following "user:" followed by the username can parse out "zhangsan"; for a quick-merge log starting with "[Quick-Merge]", the corresponding rules can parse out the original submitter of this quick-merge; for a synchronization tool log starting with "[mos_sync]by", the corresponding rules can parse out the initiator of this synchronization operation.

[0146] The second approach is based on descriptive pattern-based assignment. The overall descriptive characteristics corresponding to a certain type of business scenario are pre-registered as a descriptive pattern, and each descriptive pattern is pre-assigned a handler identifier responsible for processing that type of business. When an associated submission is identified as a certain descriptive pattern, the handler identifier associated with that descriptive pattern is directly used as the actual initiator identifier. In a specific example of a game development project, for instance, a person specifically responsible for handling table conflicts can be pre-assigned to a descriptive pattern like "resolving table conflicts." Once a CL's log is identified as this pattern, regardless of who actually submitted the CL, that person is directly regarded as the actual initiator.

[0147] These two approaches differ slightly: the former focuses on directly extracting the literal field of the actual initiator from the description, while the latter focuses on providing a scenario-based assignment method for situations where the initiator field is not explicitly provided in a fixed business scenario. When both approaches are configured simultaneously, the extraction action can be well adapted to different forms of associated submission information.

[0148] In practice, not all related submissions can successfully extract the actual initiator identifier according to the aforementioned preset rules. The log format might be non-standard, or the actual initiator might not be specified at all. To address this, this implementation further provides a fallback decision path: first, check if the related submission matches the pre-configured release mode. If it matches, release it, allowing the target change record to directly participate in the merge operation; if it doesn't match, don't release it, preventing the target change record from participating in the merge operation. The release mode mentioned here can also be a keyword mode or a regular expression mode, mainly used to cover scenarios where "although the specific initiator cannot be extracted, sufficient descriptive features are available for release."

[0149] In a specific game development project, several "pass marker keywords" (referred to as `robot_pass_patterns` in this example) can be pre-configured. For instance, a specific field can be used to indicate that "the content submitted by this bot has been approved and can be directly merged." Once a CL (Log Pass) meets the condition that "the submitter is a bot user, but the real developer cannot be extracted from the log," the execution entity will further check whether the log contains any of the aforementioned pass marker keywords; if it does, the CL is passed; otherwise, it is not. This fallback approach avoids the overly rigid processing that would result from simply excluding all relevant CLs due to extraction failure.

[0150] Subsequently, participation in the merger is determined and executed based on the actual initiator's identifier.

[0151] This step involves two aspects: firstly, determining whether each target change record should participate in the merge operation based on the obtained actual initiator identifier; and secondly, actually executing the merge action on those target change records determined to participate in the merge. The specific process is as follows: Participation determination based on the actual initiator's identifier.

[0152] This embodiment determines whether a target change record should be included in the merge based on the actual initiator's identifier, as follows: The actual initiator's identifier is compared again with the set of intermediate submitter identifiers. If the actual initiator's identifier does not appear in the set of intermediate submitter identifiers (i.e., the extracted true initiator is already a non-intermediary identifier), then this target change record should be included in the merge. Conversely, if the actual initiator's identifier still appears in the set of intermediate submitter identifiers (i.e., the extracted so-called "actual initiator" is still an intermediate account), then this target change record should not be included in the merge.

[0153] In specific game development projects, this approach can handle multi-layered intermediary scenarios where "a bot acts as an agent for another bot." For example, a CL (Clue Request) might be submitted by the bot account "merge_bot," but the so-called "real initiator" extracted from its logs is another bot account, "another_bot." Since the extraction result still falls within the bot user list, in this example, this CL is determined not to participate in the merge. Only when the extracted actual initiator is the real developer's P4 username (not in the bot user list) is the corresponding CL determined to participate in the merge. This avoids misjudgments.

[0154] The multi-dimensional filtering process is performed before the merge execution.

[0155] In addition to determining the identity of the actual initiator, this embodiment can further filter the target change records participating in the merge before the actual merge is executed. If a change record matches the filter criteria, it will no longer be allowed to participate in the merge operation. The dimensions used for filtering can be one of the following, or any combination thereof: The first dimension is based on a whitelist range of change records. A range of change records that are allowed to participate in the merging is pre-configured (e.g., a range of change record numbers). As long as the target change record is not within this range, it will be filtered.

[0156] The second dimension is a blacklist based on change records. A list of change records (including specific numbers or number ranges) that are not allowed to participate in the merging is pre-configured. If the target change record is in this list, it will be filtered.

[0157] The third dimension is based on a user blacklist. A list of committer identifiers is pre-configured that disallows their submitted change records from participating in the merge. As long as the committer identifier of the target change record is in this list, it will be filtered.

[0158] The fourth dimension is based on descriptive regular expression patterns. One or more regular expressions are pre-configured to match specific descriptive features, and the target change record is filtered as long as its commit description matches any of these patterns.

[0159] In specific examples of game development projects, the above four dimensions can still be referenced. Figure 5The filtering pipeline shown corresponds to several levels, including INCLUDE_CL_RANGES (CL whitelist range), EXCLUDE_CLS and EXCLUDE_CL_RANGES (CL blacklist / range), EXCLUDE_USERS (user blacklist), and EXCLUDE_LOG_PATTERNS (description regular expression pattern). This example can be further configured with extended filtering dimensions such as exclusion of non-main branch patterns, runtime whitelist / blacklist keywords, runtime ignored CL lists, and source branch blacklists. It also supports differentiated configuration of filtering rule sets based on the target branch. The final output filter result object (FilterResult) records the list of retained CLs, the list of excluded CLs, and the specific reason for each exclusion, facilitating subsequent traceability and troubleshooting.

[0160] The specific execution sub-processes for merging.

[0161] For target change records that should truly participate in the merging process after judgment and filtering, the following procedure shall be followed: First, for the target change record, create a "Pending Commit Change Record" on the target branch to which the merge is directed as the container for this merge (this container record is currently empty and has not yet been committed). Second, integrate the changes made to various files on the source branch (the original branch to which the target change record belonged) into this Pending Commit Change Record, and identify any conflicting files. Conflicting files refer to those files whose modifications on the source branch contradict those on the target branch and cannot be directly merged. Third, perform conflict resolution on the identified conflicting files in a specific manner. Then, check the Pending Commit Change Record again after conflict resolution to see if any unresolved conflicts remain. Finally, based on the check results, if no unresolved conflicts exist, officially commit this Pending Commit Change Record to the target branch, making the merge finally effective; if unresolved conflicts still exist, roll back all changes involved in this Pending Commit Change Record, restoring the target branch to its state before the merge began.

[0162] In a specific example of a game development project, the above process includes a cyclical sub-process: calling the P4 command to create a Pending CL (i.e., a change record to be committed) on the target branch and generating a commit description according to a pre-configured template; calling the integrate command and using the @CL,CL syntax to integrate the files involved in the source CL into the Pending CL; performing conflict resolution on conflicting files generated by integration; further performing a missed merge check; calling resolve -n (dry-run mode, only checking and not actually executing) to confirm whether there are still unresolved conflicts; if there are no unresolved conflicts, calling submit -c to officially commit the Pending CL and publish a merge success event; otherwise, calling revert to undo the changes and using deletechangelist to clean up the empty Pending CL to complete the rollback, and publishing a merge conflict event. The reason for creating a Pending CL as a container during the merge process is that subsequent multi-step conflict resolution and "overall rollback when unresolved conflicts are found" require a clear and locatable operation object. By precisely limiting these operations to the scope of this Pending CL, other operations in the same workspace will not be affected. Conversely, for simple merge scenarios that do not require conflict resolution and rollback (such as branch copying), the step of pre-creating the Pending CL can be omitted, and the commit can be completed directly through the submit -d command.

[0163] Furthermore, as a supporting mechanism in this example, P4CommandProxy transparent proxy can be used to uniformly intercept all P4 command calls. The principle is to utilize Python's `__getattr__` attribute access interception mechanism to wrap all methods prefixed with "run_" (such as `run_integrate`, `run_resolve`, `run_submit`, etc.). A pre-callback is invoked before the original command is executed (to record information such as "which P4 command to execute next"), and a post-callback is invoked after the command execution is complete (to record information such as execution time). For attribute accesses without the "run_" prefix, they are directly passed to the underlying P4 object without any interception. In this way, the business code can obtain the observability of the entire P4 command execution without modifying a single line.

[0164] The conflict resolution mentioned above specifically involves classifying conflicting files into different levels, as follows: The first level addresses conflicting files pre-listed in the blacklist by pre-retaining the target branch version as the resolution. This means modifications made to these files in the source branch will not be adopted, protecting critical files (such as project-level configuration files and customized resource files) that should not be overwritten by source branch changes. The second level handles conflicting files not on the blacklist according to a pre-defined conflict resolution strategy. The third level, for files still conflicting after the second level, performs a secondary conflict resolution based on file history patterns.

[0165] In a specific example of a game development project, the P4 operation corresponding to the first level adopts the -ay strategy (accept yours, i.e., accept the target branch version) to retain the target branch version. The file blacklist can be matched according to the depot path fragment and supports differentiated configuration according to the target branch.

[0166] The three types of conflict resolution strategies are as follows: The pre-defined conflict resolution strategies mentioned above specifically include: The first type of strategy is to automatically merge without overlap. When changes on the source branch and changes on the target branch in a conflict file affect different locations (i.e., the modified areas do not overlap), the changes from both sides are merged into the conflict file.

[0167] The second type of strategy focuses on the source branch. It directly retains the source branch version of the conflicting files as the final result, and modifications on the target branch are not adopted.

[0168] The third type of strategy focuses on the target branch. It directly retains the target branch version of the conflicted files as the final result, and modifications on the source branch are not adopted.

[0169] In specific game development projects, these three types correspond to P4's -as (safe, automatic merging), -at (accept theirs, use the source branch version), and -ay (accept yours, use the target branch version) strategies, respectively. For example, when using the first strategy and a file has different lines of code modified on two branches, this example will automatically merge the changes from both sides; when using the second strategy, the source branch version is directly used as the merged content; and when using the third strategy, the target branch version is used as the merged content. Users can flexibly choose the three types according to the characteristics of the branches being merged.

[0170] Secondary conflict resolution based on file history patterns is as follows: Secondary conflict resolution specifically involves: first, obtaining the historical change records of the file that still has a conflict in the version control system; then, checking if there is a continuous sequence of records in the history where "the file was first deleted and then re-added to the same path"; if such a sequence exists, the source branch version is retained as the conflict resolution result.

[0171] The reason the source branch version can be used when this historical pattern occurs is that, in this situation, the developer's intention is to completely replace the old version with a completely new one. Since the history in the version control system clearly shows a "delete-re-add" sequence, the current version of the source branch represents the final state desired by the developer. In a specific example of a game development project, this situation corresponds to the delete-then-readd (delete and then re-add) pattern in the P4 scenario: the executing entity queries the history of conflicting files using the P4 command `filelog`. If this pattern is identified, this example uses the `-at` strategy (accept theirs) to retain the source branch version as the conflict resolution result. Simultaneously, this example also supports excluding sensitive files from this automatic strategy by using a list of excluded directories and file extensions; these sensitive files are then handled manually.

[0172] The merge process is not always a case of "commit and it's correct". In case of anomalies within the version control server (such as permission issues, incorrect path mappings, or server malfunctions), a hidden anomaly may occur where "the merge appears to have succeeded, but some files have not actually been processed". If this anomaly is not detected, it will leave the problem of "missed merges".

[0173] To prevent this situation, this embodiment can also add an integrity check in the merge execution stage: compare the number of files actually processed in the conflict resolution stage with the number of source files originally involved in the target change record on the source branch. If the two are consistent, it means that all files that should be processed during the merge process have been processed; if the two are inconsistent, it is determined that the target change record has a risk of being missed in the merge, and the level of the risk is further determined.

[0174] In a specific example from a game development project, suppose a CL (Clear Counting) originally involved modifications to 10 files on the source branch, but after integration and conflict resolution, the executing entity only processed 7 files, resulting in a discrepancy. In this example, this CL is determined to have a risk of missed merging, and a FileCountMismatchEvent (file count inconsistency event) is issued. It's important to note that this detection operates at the file granularity "within a single CL," which is different from the multi-dimensional filtering mentioned earlier that operates at the "CL granularity." They are independent of each other; CLs that have already been filtered out will not enter the merging execution process and therefore will not affect the accuracy of this detection.

[0175] Once a risk of missing merges is identified, the risk can be classified by referring to the content of the associated submission information. Specifically, if the associated submission information contains a pre-configured reversal operation identifier, the risk of missing merges is classified as Level 1 (a lower level); if it does not contain such an identifier, it is classified as Level 2 (a higher level than Level 1).

[0176] This distinction is made because undo operations, when processed across branches, can inherently result in the expected situation where "the number of files actually processed is less than the number of source files," which doesn't necessarily indicate a genuine anomaly. In specific examples from game development projects, the undo operation identifier could be keywords like "undo." In Perforce, the essence of an undo operation is creating a new CL to "reverse" changes made by a previous CL. When the automatic merge system integrates an undo CL, because the state of files on the target branch may not be completely synchronized with the source branch, the P4 server may sometimes not perform any integration action on some files (because for these files, "there is no content to roll back" or "they are already in the correct state"), resulting in the number of files actually processed being less than the number of files involved in the source CL. If the associated commit message contains the keyword "undo," this embodiment considers this discrepancy in file count to be likely a known behavior of undo operations, and therefore sets the risk level to the relatively low first level (only providing an informational warning); conversely, if it does not contain the keyword, it may reflect an unexpected server anomaly, and is set to the relatively high second level to trigger higher-level alerts and tracking.

[0177] In addition to the main process described above, this embodiment can also respond to changes in the state of the merge operation. Specifically, whenever the merge operation enters a new state (e.g., start, success, conflict, exception, completion, etc.), an event object corresponding to that state change is generated, and the pre-configured processing action for that event is executed. Event types may include, but are not limited to, the following: merge start event, merge success event, merge conflict event, merge exception event, merge completion event, file count inconsistency event, and file lock event. Each type of event can be configured with its own processing action, such as logging, sending notifications to specific channels, and automatically generating tracking tickets.

[0178] Figure 6 This is a diagram of an event-driven pluggable notification architecture, such as... Figure 6 As shown, this event-driven pluggable notification architecture is a concrete implementation of this mechanism in a game development project example. In this embodiment, various key state changes during the merging process are modeled as domain events inherited from the DomainEvent base class, such as MergeStartedEvent (merge started), MergeSuccessEvent (single CL merge successful), MergeConflictEvent (merge conflict, with a list of conflicting files and the original committer), MergeErrorEvent (merge exception), MergeCompletedEvent (merge completed, with complete statistics), FileCountMismatchEvent (file count mismatch, corresponding to the missed merge detection result mentioned above), and FileLockedEvent (file locked, with information on the locking user and client), etc., and are distributed to several notifiers through an EventBus event bus based on the publish-subscribe pattern.

[0179] Each notifier interfaces with different external systems, subscribes to different subsets of events, and performs its own processing actions: PopoNotifier subscribes to all events, formats them into human-readable messages, and sends them to the instant messaging system via HTTP POST; RestXNotifier subscribes to success and completion events, reports the merged record to the backend RestX server via REST API, and generates a clickable "one-click retry" link; EmailNotifier only subscribes to error-level events (conflicts, exceptions, operation failures) and sends emails via SMTP; IssueNotifier subscribes to four types of events: conflicts, exceptions, file locking, and file count discrepancies, automatically calls the Redmine API to create a ticket, constructs a corporate email address based on the original submitter's P4 username, queries Redmine for the corresponding account to achieve intelligent assignment (if not found, it is automatically assigned to a pre-configured QA personnel), embeds the aforementioned "one-click retry" link in the ticket, and the developer can trigger a re-merging operation for that CL by clicking it. Each notifier can be independently configured with the event types it focuses on, the notification scope, and an enable / disable switch, and supports differentiated configuration based on the target branch.

[0180] It should be noted that the specific implementation in the above game development project scenario is only an optional implementation of the various methods and steps in this embodiment, and the scope of this implementation is not limited by these specific implementations.

[0181] The change record merging method provided in this embodiment identifies the true initiator in the intermediary submitter proxy scenario and determines whether to participate in the merge, ensuring that the merge screening result corresponds to the actual ownership of the change record. By providing two optional methods for extracting the actual initiator identifier—string-based and description-based—and a fallback mechanism for allowing entry in case of extraction failure, the identification action can better adapt to different forms of submission descriptions. Further filtering is applied from multiple dimensions, including the scope of change records, the list of change records, the list of submitters, and the characteristics of the submission description, before the merge is executed, further narrowing the scope of participants in the merge. The merge execution is broken down into stages such as the creation of the record to be submitted, change integration, conflict identification, conflict resolution, unresolved conflict detection, and submission or overall rollback. The modular approach ensures that the merge process combines phased processing capabilities with overall recoverability in case of anomalies. It employs a tiered approach to conflict files, prioritizing blacklisting, using a unified strategy, and resolving conflicts based on file history patterns. Three conflict resolution strategies are available, balancing the coverage of automatic conflict resolution with the protection of critical files. By comparing the actual number of processed files with the number of source files, it detects the risk of missed merges and differentiates risk levels based on whether the commit description contains undo / revert keywords, enabling the timely detection and differentiated handling of hidden merge incompleteness issues. Furthermore, by systematically representing key state changes during the merge process as events and responding with pre-defined actions, the observability and manageability of the merge status are further enhanced.

[0182] This embodiment also provides a change record merging system, which is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that performs a predetermined function. Although the systems described in the following embodiments are preferably implemented in software, hardware implementations, or a combination of software and hardware, are also possible and contemplated.

[0183] This embodiment provides a change record merging system, such as Figure 7 As shown, it includes: The acquisition module 701 is used to acquire a set of change records to be merged. Each change record in the set of change records to be merged contains at least the submitter identifier and associated submission information. The extraction module 702 is used to extract the actual initiator identifier from the associated submission information of the target change record according to preset rules when the target change record in the set of change records to be merged meets the preset proxy submission characteristics. The merge execution module 703 is used to determine whether the target change record is involved in the merge operation based on the actual initiator identifier, and to perform the merge on the target change records involved in the merge operation.

[0184] In some alternative implementations, the extraction module 702 is used for: When the associated submission information matches the preset string extraction pattern, the actual initiator identifier is extracted from the associated submission information according to the string extraction pattern; Alternatively, when the associated submission information matches a preset description pattern, the processor identifier associated with the description pattern will be used as the actual initiator identifier.

[0185] In some alternative implementations, the extraction module 702 is further configured to: When the actual initiator identifier cannot be extracted from the associated submission information of the target change record according to the preset rules, it is determined whether the associated submission information matches the preset release mode. When the associated submission information matches the release pattern, the target change record is included in the merge operation; When the associated submission information does not match the release mode, the target change record is excluded from the merge operation.

[0186] In some alternative implementations, the merge execution module 703 is used for: When the actual initiator's identifier does not belong to the set of intermediate submitter identifiers, the target change record is determined to participate in the merging operation; When the actual initiator's identifier belongs to the set of intermediate submitter identifiers, the target change record is determined not to participate in the merging operation.

[0187] In some optional implementations, the target change record meets preset proxy submission characteristics, including: the submitter identifier of the target change record belongs to a preset set of proxy submitter identifiers; or, the submitter identifier of the target change record conforms to preset proxy account naming rules.

[0188] In some optional implementations, the merge execution module 703 is further configured to: perform filtering processing on the target change records, and ensure that the target change records selected for filtering do not participate in the merge operation. The filtering processing includes at least one of the following: The target change record is filtered based on the preset whitelist range. When the target change record is not in the whitelist range, the target change record is determined to be a match for the filter. The target change record is filtered based on the preset change record blacklist. When the target change record is in the change record blacklist, it is determined that the target change record has been filtered. The target change records are filtered based on a preset user blacklist. When the submitter of the target change record is identified in the user blacklist, the target change record is determined to have met the filtering criteria. The target change record is filtered based on a preset description regular expression pattern. When the associated submission information of the target change record matches the description regular expression pattern, the target change record is determined to have met the filtering process.

[0189] In some alternative implementations, the merge execution module 703 is used for: For the target change record, create a change record to be committed on the target branch, which is the branch to which the merge operation points; Integrate the changes to files on the source branch involved in the target change record into the change record to be committed, and determine whether there are conflicting files in the change record to be committed; where the source branch is the branch to which the target change record belongs, and conflicting files are files that conflict with the modifications on the source branch and the modifications on the target branch. When there are conflicting files in the change log to be submitted, conflict resolution is performed on the conflicting files; Check for unresolved conflicts in the change log to be submitted; If there are no unresolved conflicts, commit the changes to be committed to the target branch; If unresolved conflicts exist, roll back all changes involved in the pending change log.

[0190] In some alternative implementations, the merge execution module 703 is used for: For files in the conflict file list that are on the default file blacklist, retain the target branch version of the file that is on the default file blacklist as the conflict resolution result; For conflicting files that are not on the default file blacklist, the conflict will be resolved according to the default conflict resolution strategy. For files that still have conflicts after being resolved according to the conflict resolution strategy, a secondary conflict resolution based on the file history pattern is performed.

[0191] In some alternative implementations, the merge execution module 703 is used for: If the conflict resolution strategy is the first type strategy, then when the modifications on the source branch and the modifications on the target branch in the conflict file do not overlap, the modifications on the source branch and the modifications on the target branch will be merged into the conflict file. If the conflict resolution strategy is the second type, then the source branch version of the conflicting file is retained as the conflict resolution result; If the conflict resolution strategy is the third type, then the target branch version of the conflicted file is retained as the conflict resolution result.

[0192] In some alternative implementations, the merge execution module 703 is used for: Retrieve the historical change history of files that still have conflicts; When a conflicting file is deleted and then re-added in the history of changes, the source branch version of the file that still has a conflict is retained as the result of conflict resolution.

[0193] In some alternative implementations, the merge execution module 703 is further configured to: Compare the number of files actually processed in conflict resolution with the number of source files involved in the target change log; When the number of files actually processed is inconsistent with the number of source files, it is determined that there is a risk of missing merges in the target change records, and the level of the missing merge risk is determined.

[0194] In some alternative implementations, the merge execution module 703 is used for: When the associated submission information of the target change record contains a preset revocation operation identifier, the level of the risk of missing merge is determined to be the first level; When the associated submission information of the target change record does not contain the preset revocation operation identifier, the level of the risk of missing merge is determined to be the second level; where the second level is higher than the first level.

[0195] In some alternative implementations, the merge execution module 703 is further configured to: When a state change occurs during a merge operation, an event corresponding to the state change is generated; Execute the preset processing action corresponding to the event; The events include at least one of the following: merge start event, merge success event, merge conflict event, merge exception event, merge complete event, file count inconsistency event, and file lock event.

[0196] In some alternative implementations, the merge execution module 703 is further configured to: Based on the type of the event and the target branch to which the target change record belongs, at least one target notification is determined from a plurality of pre-configured notifications; wherein, the plurality of notifications includes an instant messaging notification, a server callback notification, an email notification, and a ticket notification. For merge conflict events, merge exception events, or file lock events, a one-click retry link pointing to the re-merge interface is generated, and the one-click retry link is embedded in the message content output by the target notifier.

[0197] The change record merging system provided in this disclosure can execute the change record merging method provided in any embodiment of this disclosure, and has the corresponding functional modules and beneficial effects for executing the method. Further functional descriptions of the various modules and units described above are the same as in the corresponding embodiments described above, and will not be repeated here.

[0198] Figure 8This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure.

[0199] The following is a detailed reference. Figure 8 The diagram illustrates a structural schematic suitable for implementing an electronic device according to embodiments of the present disclosure. The electronic device may include a processor (e.g., a central processing unit, graphics processor, etc.) 801, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 802 or a program loaded from memory 808 into random access memory (RAM) 803. The RAM 803 also stores various programs and data required for the operation of the electronic device. The processor 801, ROM 802, and RAM 803 are interconnected via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.

[0200] Typically, the following devices can be connected to I / O interface 805: input devices 806 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 807 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; memory devices 808 including, for example, magnetic tapes, hard disks, etc.; and communication devices 809. Communication device 809 allows electronic devices to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 8 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown, and more or fewer devices may be implemented or have instead.

[0201] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 809, or installed from a memory 808, or installed from a ROM 802. When the computer program is executed by the processor 801, it performs the functions defined in the change record merging method of embodiments of this disclosure.

[0202] Figure 8 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0203] This disclosure also provides a computer-readable storage medium in which the methods described in this disclosure can be implemented in hardware or firmware, or implemented as recordable on a storage medium, or implemented as computer code originally stored on a remote storage medium or a non-transitory machine-readable storage medium and subsequently stored on a local storage medium after being downloaded via a network. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium may also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the change record merging method shown in the above embodiments.

[0204] A portion of this disclosure can be applied to computer program products, such as computer program instructions, which, when executed by a computer, can invoke or provide methods and / or technical solutions according to this disclosure through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, and installation package files. Accordingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions; the computer compiling the instructions and then executing the corresponding compiled program; the computer reading and executing the instructions; or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0205] Although embodiments of the present disclosure have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the present disclosure, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A method for merging change records, characterized in that, The method includes: Obtain a set of change records to be merged, wherein each change record in the set of change records to be merged contains at least the submitter identifier and associated submission information; When a target change record in the set of change records to be merged meets the preset proxy submission characteristics, the actual initiator identifier is extracted from the associated submission information of the target change record according to preset rules. Based on the actual initiator identifier, determine whether the target change record participates in the merge operation, and perform the merge on the target change records that participate in the merge operation.

2. The method according to claim 1, characterized in that, The step of extracting the actual initiator identifier from the associated submission information of the target change record according to preset rules includes: When the associated submission information matches a preset string extraction pattern, the actual initiator identifier is extracted from the associated submission information according to the string extraction pattern. Alternatively, when the associated submission information matches a preset description pattern, the processor identifier associated with the description pattern is used as the actual initiator identifier.

3. The method according to claim 1, characterized in that, The method further includes: If the actual initiator identifier cannot be extracted from the associated submission information of the target change record according to the preset rules, it is determined whether the associated submission information matches the preset release mode. When the associated submission information matches the release pattern, the target change record is included in the merge operation; When the associated submission information does not match the release mode, the target change record is not included in the merging operation.

4. The method according to claim 1, characterized in that, The step of determining whether the target change record participates in the merge operation based on the actual initiator identifier includes: When the actual initiator identifier does not meet the preset proxy submission characteristics, the target change record is determined to participate in the merging operation; When the actual initiator identifier meets the preset proxy submission characteristics, it is determined that the target change record will not participate in the merging operation.

5. The method according to claim 1, characterized in that, The target change record satisfies preset proxy submission characteristics, including: The submitter identifier of the target change record belongs to a preset set of proxy submitter identifiers; or, the submitter identifier of the target change record conforms to a preset proxy account naming rule.

6. The method according to claim 1, characterized in that, Before the step of merging the target change records involved in the merge operation, the method further includes performing a filtering process on the target change records, and excluding the target change records that have been filtered from the merge operation; the filtering process includes at least one of the following: The target change record is filtered according to a preset whitelist range. When the target change record is not in the whitelist range, it is determined that the target change record has been filtered. The target change record is filtered according to a preset change record blacklist. When the target change record is in the change record blacklist, it is determined that the target change record has hit the filtering process. The target change records are filtered according to a preset user blacklist. When the submitter of the target change record is identified in the user blacklist, the target change record is determined to have met the filtering process. The target change record is filtered according to a preset description regular expression pattern. When the associated submission information of the target change record matches the description regular expression pattern, the target change record is determined to have met the filtering process.

7. The method according to claim 1, characterized in that, The process of merging the target change records involved in the merge operation includes: For the target change record, create a change record to be committed on the target branch, where the target branch is the branch to which the merge operation points; The changes to files on the source branch involved in the target change record are integrated into the change record to be committed, and it is determined whether there are conflicting files in the change record to be committed; wherein, the source branch is the branch to which the target change record belongs, and the conflicting files are files that conflict with the modifications on the source branch and the modifications on the target branch; When the conflicting file exists in the change record to be submitted, conflict resolution is performed on the conflicting file; Check if there are any unresolved conflicts in the change record to be submitted; If no unresolved conflicts exist, submit the change record to the target branch. If any unresolved conflicts exist, roll back all changes involved in the pending change record.

8. The method according to claim 7, characterized in that, The conflict resolution process for the conflicting files includes: For files in the conflicting files that belong to the preset file blacklist, retain the target branch version of the file that belongs to the preset file blacklist as the conflict resolution result; For files in the conflicting files that are not in the preset file blacklist, the conflict is resolved according to the preset conflict resolution strategy. For files that still have conflicts after being resolved according to the aforementioned conflict resolution strategy, a secondary conflict resolution based on the file history pattern is performed.

9. The method according to claim 8, characterized in that, The conflict resolution strategy, as described above, includes: If the conflict resolution strategy is a first type strategy, then when the modifications on the source branch and the modifications on the target branch in the conflict file do not overlap, the modifications on the source branch and the modifications on the target branch are merged into the conflict file. If the conflict resolution strategy is the second type strategy, then the source branch version of the conflicting file is retained as the conflict resolution result; If the conflict resolution strategy is a third type strategy, then the target branch version of the conflict file is retained as the conflict resolution result.

10. The method according to claim 8, characterized in that, The secondary conflict resolution based on file history patterns includes: Obtain the historical change records of the files that still have conflicts; When there is a record in the historical change log where a file that still has a conflict was first deleted and then re-added, the source branch version of the file that still has a conflict is retained as the conflict resolution result.

11. The method according to claim 7, characterized in that, The method further includes: The number of files actually processed in the conflict resolution is compared with the number of source files involved in the target change record; When the actual number of files processed is inconsistent with the number of source files, it is determined that there is a risk of missing merges in the target change record and the level of the missing merge risk is determined.

12. The method according to claim 11, characterized in that, Determining the level of the risk of missing data consolidation includes: When the associated submission information of the target change record contains a preset revocation operation identifier, the level of the omission merging risk is determined to be the first level; When the associated submission information of the target change record does not contain the preset revocation operation identifier, the level of the omission merging risk is determined to be the second level; wherein, the second level is higher than the first level.

13. The method according to claim 1, characterized in that, The method further includes: When the state changes during the merging operation, an event corresponding to the state change is generated; Execute the preset processing action corresponding to the event; The events include at least one of the following: merge start event, merge success event, merge conflict event, merge exception event, merge complete event, file count inconsistency event, and file lock event.

14. The method according to claim 13, characterized in that, The step of executing the preset processing action corresponding to the event includes: Based on the type of the event and the target branch to which the target change record belongs, at least one target notifier is determined from a plurality of pre-configured notifiers; wherein, the plurality of notifiers includes an instant messaging notifier, a server callback notifier, an email notifier, and a ticket notifier; For merge conflict events, merge exception events, or file lock events, a one-click retry link pointing to the re-merge interface is generated, and the one-click retry link is embedded in the message content output by the target notifier.

15. A change record merging system, characterized in that, The system includes: The acquisition module is used to acquire a set of change records to be merged, wherein each change record in the set of change records to be merged contains at least a submitter identifier and associated submission information; The extraction module is used to extract the actual initiator identifier from the associated submission information of the target change record according to preset rules when the target change record in the set of change records to be merged meets the preset proxy submission characteristics. The merge execution module is used to determine whether the target change record participates in the merge operation based on the actual initiator identifier, and to perform the merge on the target change records that participate in the merge operation.

16. An electronic device, characterized in that, include: A memory and a processor are communicatively connected, the memory storing computer instructions, and the processor executing the computer instructions to perform the change record merging method according to any one of claims 1 to 14.

17. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing a computer to perform the change record merging method according to any one of claims 1 to 14.

18. A computer program product, characterized in that, Includes computer instructions for causing a computer to perform the change record merging method according to any one of claims 1 to 14.

Images