Method and apparatus for processing resource multi-branch combination, electronic device, and storage medium

Abstract

This application discloses a method, apparatus, electronic device, and storage medium for merging multiple resource branches, belonging to the field of resource multi-branch merging technology. The method includes: merging a first resource file to be merged from a source branch into a local directory of a target integration branch; classifying the merged modified resource files in the local directory using preset file type classification rules; performing a restoration operation on the first target file belonging to a first file type (indicating an automatically generated configuration file) among the modified resource files; for each second target file other than the first target file among the modified resource files, performing a restoration operation if its content is consistent with the corresponding first resource file; if the second target file's content is inconsistent with the corresponding first resource file, performing version processing on the second target file based on preset version adjudication rules and the preset file type to which the second target file belongs. This application can effectively improve the efficiency of merging multiple resource branches.

Description

Technical Field

[0001] This application relates to the field of resource multi-branch merging technology, specifically to processing methods, apparatus, electronic devices, and storage media for resource multi-branch merging. Background Technology

[0002] Complex software projects such as massively multiplayer online games (MMOs) commonly employ a multi-branch parallel development model to support multiple functional teams in simultaneously iterating on features. For example, a game client's resource directory contains tens of thousands of files, covering various types such as UI (user interface) configurations, model files, graph collections, shaders, and export artifacts automatically generated from Excel configuration tables. Multiple functional branches (also known as source branches, such as SDC branches and new feature branches) will make numerous concurrent modifications to these resources during their independent evolution.

[0003] When merging resource changes from a source branch into a target integration branch (such as the April branch), the large number of files involved and their highly heterogeneous types (a mix of binary and text) often lead to inefficient merging processes. This often relies on manual file-by-file checks or static whitelist maintenance to handle merge conflicts. Summary of the Invention

[0004] This application provides a method, apparatus, electronic device, and storage medium for merging multiple branches of resources, aiming to solve the problem of low merging efficiency caused by relying on manual file-by-file checks or static whitelist maintenance to handle merging conflicts when merging multiple branches of resources.

[0005] Firstly, a method for merging multiple branches of resources is provided, including: Merge each of the first resource files to be merged in the source branch into the local directory of the target integration branch; For each changed resource file generated by merging in the local directory, the changed resource files are classified according to the preset file type classification rules; wherein, the file type classification rules correspond to multiple preset file types, including a first file type, which is used to indicate the automatically generated configuration file; Perform a restore operation on each first target file that belongs to the first file type in each changed resource file; For each second target file other than the first target file in each changed resource file, if the content of the second target file is consistent with the corresponding first resource file, then the second target file is restored. If the content of the second target file is inconsistent with that of the corresponding first resource file, the second target file will be processed according to the preset version adjudication rules and the preset file type to which the second target file belongs.

[0006] Secondly, a processing apparatus for merging multiple branches of resources is also provided, comprising: The merge unit is configured to merge each of the first resource files to be merged in the source branch into the local directory of the target integration branch; The classification unit is configured to classify each changed resource file generated by merging in the local directory using a preset file type classification rule; wherein the file type classification rule corresponds to multiple preset file types, including a first file type, which is used to indicate the automatically generated configuration file; The first processing unit is configured to perform a restore operation on each first target file belonging to the first file type in each changed resource file; The second processing unit is configured to perform a restore operation on each second target file other than the first target file in each changed resource file if the content of the second target file is consistent with the content of the corresponding first resource file; if the content of the second target file is inconsistent with the content of the corresponding first resource file, the second target file is version processed based on the preset version adjudication rules and the preset file type to which the second target file belongs.

[0007] Thirdly, an electronic device is also provided, including a memory and a processor. The memory stores a computer program, which, when executed by the processor, implements the processing method as described in the first aspect.

[0008] Fourthly, a computer-readable storage medium is also provided, on which a computer program is stored, the computer program being loaded by a processor to perform the steps of the processing method as described in the first aspect.

[0009] The solution provided in this application effectively improves the efficiency and accuracy of merging multiple resource branches through automated classification and differentiated processing mechanisms. Specifically, by merging source branch files into the local directory of the target integration branch and classifying the changed resource files generated by the merger according to preset types, it can quickly identify automatically generated configuration files (the first file type) and directly perform restoration operations, avoiding redundant conflict detection and adjudication for such files that do not require manual intervention. For other files, content consistency is judged (restoration if consistent), reducing unnecessary version processing overhead. For files with inconsistent content, targeted processing is performed based on preset version adjudication rules and their file types, avoiding the loss of effective modifications or inefficiency caused by traditional global strategies (such as blind overwriting or full manual verification). Overall, this solution achieves automation and refinement of the merging process through pre-classification, content filtering, and rule-based adjudication, significantly reducing the cost of manual intervention while ensuring the reliability of the merging results. Attached Figure Description

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

[0011] Figure 1 This is a flowchart illustrating the resource multi-branch merging processing method provided in the embodiments of this application; Figure 2 This is a schematic diagram of the structure of the resource multi-branch merging processing device provided in the embodiments of this application; Figure 3 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

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

[0013] In the description of this application, it should be understood that the terms "center," "longitudinal," "lateral," "length," "width," "thickness," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicating orientation or positional relationships based on the orientation or positional relationships shown in the accompanying drawings, are used only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of this application. Furthermore, 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 indicated technical features. Thus, features defined with "first" and "second" may explicitly or implicitly include one or more of the stated features. In the description of this application, "a plurality of" means two or more, unless otherwise explicitly specified.

[0014] "A and / or B" includes the following three combinations: A only, B only, and a combination of A and B.

[0015] The use of "applies to" or "configured to" in this application implies open and inclusive language, which does not exclude the applicability to or configuration to devices performing additional tasks or steps. Additionally, the use of "based on" implies openness and inclusivity, because processes, steps, calculations, or other actions "based on" one or more conditions or values ​​may in practice be based on additional conditions or values ​​beyond those stated.

[0016] In this application, the term "exemplary" is used to mean "used as an example, illustration, or description." Any embodiment described as "exemplary" in this application is not necessarily to be construed as being more preferred or advantageous than other embodiments. The following description is provided to enable any person skilled in the art to make and use this application. Details are set forth in the following description for purposes of explanation. It should be understood that those skilled in the art will recognize that this application can be made without using these specific details. In other instances, well-known structures and processes are not described in detail to avoid obscuring the description of this application with unnecessary detail. Therefore, this application is not intended to be limited to the embodiments shown, but is consistent with the broadest scope of the principles and features disclosed in this application.

[0017] Below, we will first describe the definitions of abbreviations and key terms used in this application: SVN: Subversion, a centralized version control system used to manage the multi-branch parallel development of game project source code and resource files; Working copy (WC): In SVN, the branch directory checked out by the developer on their local disk contains version-controlled resource files; Merge: The operation of integrating changes from one SVN branch into a working copy of another branch; Cherry-pick: A method of merging only specified revisions (commit version numbers) instead of merging the entire document; Revision: A globally incrementing version number generated by each commit in SVN, uniquely identifying a code / resource change; Mergeinfo: A hidden attribute (svn:mergeinfo) that SVN automatically writes to directories, recording the scope of merged revisions, which sometimes causes "mergeinfo pollution" problems; Exported output: The JSON configuration file generated by batch exporting the planning configuration table (Excel) is an automatically generated file and should not be included in manual merging; Hub configuration file: A key JSON configuration file that needs to be manually maintained, modified independently by multiple branches, and is not part of the export table output; M status file: A file whose first column in the SVN status output is "M" indicates that the local content has been modified relative to the BASE version (the version before merging); Four-way diff: Simultaneously compares the differences of the same file across four data sources (such as the SDC branch, April branch, art resource directory, and UI project branch); MD5 pre-judgment: A fast judgment strategy that confirms two files are completely identical at the byte level by calculating and comparing their hash values; Version decision-making: For documents that have been modified by both parties, a decision-making process is used to select the final version based on semantic rules such as timeline and source authority. April branch: The target integration branch, a merge target of multiple feature branches (including the SDC branch); SDC branch: One of the source branches, containing resource changes for SDC-specific features; UI Project Branch: A dedicated project for UI editors, the sole authoritative source for UI configuration; Art Resources Directory: The original directory of .nif / .dds / .png files produced by artists.

[0018] As described in the background section, when merging resource changes from a source branch into a target integration branch (such as the April branch), the large number of files involved and their highly heterogeneous types (a mix of binary and text) often lead to low merging efficiency.

[0019] One related technology uses a combination of full SVN (Subversion) merging and manual file-by-file processing. Specifically, it uses SVN merge.<SDC_URL> <target>After the full merge, each M-state and conflicting file is manually checked for commit messages to confirm which version to use, and each imported table artifact needs to be reverted. Since large projects often have hundreds of M-state files, manual file-by-file checking is extremely inefficient and prone to errors due to fatigue, potentially resulting in the reverting of valid changes or the incorrect retention of imported table artifacts.

[0020] Another related technique relies on the global `accepttheirs` strategy. Using `svn merge --accepttheirs-conflict` forces all conflicts to be resolved based on the source branch, resulting in a fast merge without file-level categorization. However, the global `accepttheirs` strategy blindly overwrites correct changes already present in the target integration branch. For example, updated versions of files exported from a user interface (UI) project might be overwritten by older versions from the source branch, leading to feature rollback.

[0021] Another related technology uses a static whitelist for maintenance. A "whitelist of imported artifacts" file is manually maintained beforehand, and reverts are performed in batches according to the whitelist after merging. However, static whitelists require continuous manual maintenance, and as the number of configuration tables increases, the whitelist frequently becomes incomplete or redundant. When a new configuration table is added, if the developer forgets to update the whitelist, the new imported artifacts will be incorrectly retained in the version commit.

[0022] In view of this, embodiments of this application provide a method, apparatus, electronic device, and storage medium for merging multiple branches of resources. Through automated classification and differentiated processing mechanisms, the efficiency and accuracy of merging multiple branches of resources are effectively improved, thereby solving at least one of the above-mentioned technical problems.

[0023] In some embodiments, the resources in this application include, but are not limited to, game resources.

[0024] In some embodiments, the execution entity of the resource multi-branch merging processing method provided in this application can be a resource merge adjudication system (a set of toolchain scripts) running on the developer's local work machine or CI (continuous integration) merge machine. It uses the SVN client as its underlying capability and runs the resource multi-branch merging processing flow on the local working copy, without relying on a separate server.

[0025] Specifically, this embodiment will be described from the perspective of a resource multi-branch merging processing device. This processing device can be integrated into an electronic device, that is, the resource multi-branch merging processing method provided in this application embodiment can be executed by an electronic device. Optionally, the electronic device may include a terminal device. The terminal device may be a mobile phone, tablet computer, smart Bluetooth device, laptop computer, game console, or personal computer (PC), etc.

[0026] The resource multi-branch merging processing method provided in this application embodiment can be applied to systems such as resource merging adjudication systems. This resource merging adjudication system may include a terminal device and a server. The terminal device may be a device that includes both receiving and transmitting hardware, i.e., a device with receiving and transmitting hardware capable of performing bidirectional communication over a bidirectional communication link. The terminal device and the server can communicate bidirectionally via a network.

[0027] Optionally, the server can be a standalone server, or a server network or server cluster, including but not limited to computers, network hosts, single network servers, multiple network server sets, or cloud servers composed of multiple servers. Cloud servers consist of a large number of computers or network servers based on cloud computing.

[0028] The following detailed description is provided in conjunction with the accompanying drawings. In this embodiment, the execution subject is a terminal device as an example. It should be noted that the order of description in the following embodiments is not intended to limit the preferred order of the embodiments. Although a logical order is shown in the flowcharts, in some cases, the steps shown or described may be performed in a different order than that shown in the accompanying drawings.

[0029] Figure 1 This is a flowchart illustrating the resource multi-branch merging processing method provided in an embodiment of this application. For example... Figure 1 As shown, the processing method includes steps 101 to 105 as shown below.

[0030] Step 101: Merge each of the first resource files to be merged in the source branch into the local directory of the target integration branch.

[0031] The local directory can be referred to as the local working copy. In some embodiments, change data for each first resource file can be obtained and merged into the local directory of the target integration branch.

[0032] Step 102: For each changed resource file generated after merging in the local directory of the target integration branch, classify each changed resource file using the preset file type classification rules; wherein, the file type classification rules correspond to multiple preset file types, including a first file type, which is used to indicate the automatically generated configuration file.

[0033] Among them, the change resource file can be referred to as the M status file as described above, and the first file type can be referred to as the export table product as described above.

[0034] For example, the file type classification rules include a first condition corresponding to the first file type. The first condition indicates that the file path includes a first preset path (such as confs / sdc / ) and satisfies any of the following sub-conditions: the file name is included in preset grouping field information, which describes the correspondence between the file name and the grouping field; the file submission description includes preset keywords related to automatic generation (such as AUTO, automatic generation, re-export, etc.). In one example, the grouping field information is a grouping field dictionary, which can be called the SHEET_GROUP_FIELD dictionary. This grouping field dictionary includes known export table file names and their corresponding main grouping fields.

[0035] In some embodiments, the aforementioned plurality of preset file types further includes at least one of a second file type, a third file type, and a fourth file type. The second file type indicates a configuration file requiring manual maintenance, the third file type indicates a user interface configuration, and the fourth file type indicates a binary resource. For example, the second file type may be referred to as a hub configuration file, the third file type as a UI configuration, and the fourth file type as a binary resource.

[0036] In cases where the aforementioned preset file types also include a second file type, the file type classification rules further include a second condition corresponding to the second file type. The second condition is that the file path includes the root directory of the first preset path but does not belong to the first file type. For example, if the first preset path is "confs / sdc / ", the root directory is "confs / ".

[0037] If the above-mentioned preset file types also include a third file type, the file type classification rule also includes a third condition corresponding to the third file type. The third condition is that the file path includes a second preset path and the file extension includes a preset first extension. The second preset path can be "uiconf / " or "uiconf_csb / ", and the first extension can be ".json" or ".csb".

[0038] If the aforementioned preset file types also include a fourth file type, the file type classification rule further includes a fourth condition corresponding to the fourth file type. The fourth condition is that the file extension is included in a preset second set of extensions. This second set of extensions may include ".nif", ".dds", ".png", and ".glsl", etc.

[0039] Taking the aforementioned preset file types, including a first file type, a second file type, a third file type, and a fourth file type, as an example, for each modified resource file, if the modified resource file meets the first condition, it is determined that the modified resource file belongs to the first file type. If the modified resource file meets the second condition, it is determined that the modified resource file belongs to the second file type. If the modified resource file meets the third condition, it is determined that the modified resource file belongs to the third file type. If the modified resource file meets the fourth condition, it is determined that the modified resource file belongs to the fourth file type. This enables automatic classification of file types.

[0040] Optionally, if the file path of the changed resource file includes a first preset path but the filename is not included in the preset grouping field information, a second flag can be set for the changed resource file. This second flag indicates that manual review is required; for example, it can be CHECK. It is understood that this second flag serves to remind the developer that the grouping field information may have omitted the filename of the changed resource file, and that the filename may need to be added to the grouping field information.

[0041] Step 103: Perform a restore operation on each first target file belonging to the first file type in each changed resource file.

[0042] Specifically, the first target file is restored to its corresponding second resource file (which can be called the BASE version) in the target integration branch before merging.

[0043] As one implementation method, each first target file can be restored in batches to significantly improve processing efficiency and reduce system overhead.

[0044] Step 104: For each second target file other than the first target file in each changed resource file, if the content of the second target file is consistent with the corresponding first resource file, then perform a restore operation on the second target file.

[0045] Specifically, the second target file is restored to its original, pre-merge second resource file within the target integration branch. It should be noted that this implementation is particularly effective for binary resource files. Since many M-state resource files are falsely reported as "modified" solely due to SVNmergeinfo attribute contamination, even though their actual file content is identical at the byte level, pre-judgment based on file content consistency can eliminate these false alarms in one go, avoiding unnecessary manual intervention.

[0046] In some embodiments, for each second target file, if the content of the second target file is identical to that of the corresponding first resource file, a third flag is set for the second target file. The third flag indicates skipping; for example, the third flag can be SKIP. Batch restoration can be performed on each second target file with the third flag set. For example, each second target file with the third flag set can be added to a batch restoration list, and restoration commands can be generated in batches for this batch restoration list.

[0047] Step 105: If the content of the second target file is inconsistent with the corresponding first resource file, then the second target file is processed based on the preset version adjudication rules and the preset file type to which the second target file belongs.

[0048] In some embodiments, the file size of each second target file can be obtained. Additionally, a version control command can be executed to retrieve the corresponding first resource file from the remote endpoint based on the URL (uniform resource locator) of the source branch and the relative path of the second target file within the source branch. In the event of a version control command failure: if the return code is 0 (URL exists), it indicates that the file exists but content access is restricted (permission issue). A fourth flag (e.g., PERMISSION_ERR) can be set for the second target file to indicate a permission issue, and the second target file is added to the manual verification list without automatic processing. If the return code is non-zero and the error diagnosis information indicates that the file cannot be found, it can be confirmed that the source branch does not have a corresponding first resource file. A fifth flag (e.g., APRIL_ONLY) can be set for the second target file to indicate that the target integration branch has added a new file, and the second target file is retained. If the return code is non-zero and the error diagnosis information indicates a network error, a sixth flag (e.g., NET_FAIL) can be set for the second target file to indicate a network error, and the second target file is added to the manual verification list.

[0049] It should be noted that directly equating the failure of the above version control command with APRIL_ONLY will result in misjudgment when the network is unstable, causing the valid files of the target integration branch (APRIL branch) to be incorrectly restored.

[0050] The methods for determining whether the content of the second target file is consistent with the corresponding first resource file include: Determine the absolute value of the difference between the file size of the second target file and the corresponding first resource file; If the ratio of this absolute value to the file size of the second target file is greater than a preset threshold (e.g., 0.5), then it is determined that the content of the second target file is inconsistent with the content of the corresponding first resource file. If the ratio is less than or equal to a preset threshold, then the preset first hash algorithm is used to perform a hash operation on the second target file to obtain a first hash value, and to perform a hash operation on the first resource file corresponding to the second target file to obtain a second hash value. Based on the comparison results of the first hash value and the second hash value, it is determined whether the content of the second target file is consistent with the corresponding first resource file.

[0051] Let local_size represent the file size of the second target file and remote_size represent the file size of the first resource file corresponding to the second target file. Taking a preset threshold of 0.5 as an example, if |local_size-remote_size| / local_size>0.5, it is determined that the file size difference is significant, thus determining that the content of the second target file and the corresponding first resource file are inconsistent.

[0052] In some embodiments, determining the content consistency between the second target file and the corresponding first resource file based on the comparison result of the first hash value and the second hash value includes: if the first hash value and the second hash value are different, then determining that the content of the second target file and the corresponding first resource file are inconsistent; if the first hash value and the second hash value are the same, then determining that the content of the second target file and the corresponding first resource file are consistent. In one example, the first hash algorithm may include the MD5 algorithm, thereby enabling MD5 pre-judgment and achieving fast file-level byte consistency filtering.

[0053] It should be noted that the document uniqueness verification in this application is not limited to the MD5 algorithm, but adopts a configurable hash algorithm strategy. The system maintains a unified hash calculation interface and supports replacing specific algorithms according to the scenario. This application can be configured with MD5, SHA-1, SHA-256, xxHash and CRC32 algorithms as shown in Table 1.

[0054] Table 1: Introduction to Hash Algorithms

[0055] In some embodiments, determining the consistency between the content of the second target file and the corresponding first resource file based on the comparison result of the first hash value and the second hash value includes: if the first hash value and the second hash value are different, then the content of the second target file and the corresponding first resource file are determined to be inconsistent; if the first hash value and the second hash value are the same, then a third hash value is obtained by hashing the second target file using a preset second hash algorithm, and a fourth hash value is obtained by hashing the first resource file corresponding to the second target file; wherein, the calculation speed of the first hash algorithm is higher than that of the second hash algorithm; if the third hash value and the fourth hash value are different, then the content of the second target file and the corresponding first resource file are determined to be inconsistent; if the third hash value and the fourth hash value are the same, then the content of the second target file and the corresponding first resource file are determined to be consistent. The first hash algorithm includes the CRC32 algorithm, and the second hash algorithm includes SHA-256. Therefore, for important hub configuration files (such as camera.json and sail_colorsuit.json), the following three-level joint verification can be enabled: File size comparison → If they are different, they are directly determined to be different (zero hash calculation overhead). CRC32 fast comparison → if they are different, they are determined to be different (fastest speed, used for pruning). SHA-256 strong verification → if they are the same, the uniqueness is finally confirmed (extremely low collision probability).

[0056] The three-level joint verification balances speed and reliability. Large batches of files are quickly eliminated by the first two levels, and only files that are "suspected to be the same" are subjected to high-overhead SHA-256 verification. The overall computational load is close to that of using CRC32 alone.

[0057] It should be noted that by performing a pre-assessment of the content consistency between the second target file and its corresponding first resource file, it can be determined whether the merge operation has actually resulted in content changes. If the second target file and its corresponding first resource file are completely identical at the byte level, it means that the second target file is only showing an "M" state due to mergeinfo attribute pollution, and the actual content has not changed, so it can be safely restored; if the second target file and its corresponding first resource file are not completely identical at the byte level, it means that there are substantial content differences, and it needs to proceed to subsequent version rulings.

[0058] Taking a scenario involving the merging of approximately 300 M-state resource files as an example, about 60% of the files are displayed as M-state only due to mergeinfo attribute pollution, with no actual changes in content. These files can be automatically excluded through content consistency pre-judgment, and only about 40% of the files need to enter the subsequent adjudication process, significantly reducing manual workload.

[0059] In some embodiments, the preset version adjudication rules may include a first adjudication rule, which may include, for example, performing a set operation on the set of keys of the file in multiple data sources for resource files that need to be merged (each party has made independent changes), and performing version processing based on the operation result, such as identifying a unique key of a party and safely appending it.

[0060] If the preset version ruling rules include the first ruling rule, the second target file is version-processed based on the preset version ruling rules and the preset file type to which the second target file belongs. This includes: in response to the second target file belonging to the second file type and having bidirectional modifications in both the source branch and the target integration branch, performing set operations on the key sets of the pre-merge resource files corresponding to the second target file in multiple data sources to obtain the operation results; wherein, the multiple data sources include the source branch, the target integration branch, and the art resource directory; based on the operation results, updating the pre-merge second resource files corresponding to the second target file in the target integration branch, and replacing the second target file with the updated second resource files. Optionally, the multiple data sources may also include user interface engineering branches.

[0061] For example, when the above multiple data sources include the source branch, the target integration branch, the art resource catalog, and the user interface project branch, a four-party diff analysis tool (such as compare_sail.py / compare_camera.py) can be called to perform set operations on the key set of the second target file in the four data sources, identify "keys unique to a certain party", and safely append them.

[0062] Furthermore, the above calculation results may include a first key unique to the source branch and a second key common to all data sources; based on the calculation results, the second resource file of the second target file before merging in the target integration branch is updated, including: Write the content corresponding to the first key in the first resource file corresponding to the second target file into the second resource file; If the content corresponding to the second key is not exactly the same in each data source, then generate and output the content confirmation information for the second key; In response to receiving feedback information confirming the content, the target resource file is determined from each of the resource files before the merger based on the feedback information. If the target resource file and the second resource file are not the same file, the content corresponding to the second key in the target resource file is written into the second resource file.

[0063] In some embodiments, the above calculation result may also include a third key unique to the target integration branch, and the content corresponding to the third key is retained in the second resource file.

[0064] Let 'ak' represent the key set of the second resource file, 'sk' represent the key set of the first resource file, and 'rk' represent the key set of the resource file corresponding to the second target file in the art resource directory before merging. For example, the first key unique to the source branch is 'only_sdc=sk-ak-rk'. The second key, 'all_have', shared by the target integration branch, the source branch, and the art resource directory, is the intersection of 'ak', 'sk', and 'rk', for example, 'all_have=ak&sk&rk'. The third key unique to the target integration branch is 'only_april=ak-sk-rk'.

[0065] Taking April as the target integration branch, SDC as the source branch, and art as the art asset directory as an example, let's assume that these three parties share a key=skin_01. The content corresponding to this key includes "color" and "name" fields, where the value of the "color" field is always "#FF0000", while the values ​​of the "name" field are not exactly the same, as shown below: April: {"color": "#FF0000", "name": "Red Skin"}; SDC: {"color": "#FF0000", "name": "SDC Exclusive Red Skin"}; Art: {"color": "#FF0000", "name": "Red Skin"}.

[0066] In this scenario, assuming the SDC submission time is the latest, a suggestion to use the SDC version can be attached to the content confirmation information for that key, serving as a reference for manual review. For example, the content confirmation information for that key could include: DIFF key=skin_01: April: {"color": "#FF0000", "name": "Red Skin"}; SDC: {"color": "#FF0000", "name": "SDC Exclusive Red Skin"}; Artwork: {"color": "#FF0000", "name": "Red Skin"}; ->The SDC submission time is the latest, so it is recommended to use the SDC version.

[0067] In some embodiments, preset version adjudication rules can be used for differentiated automatic adjudication based on multi-dimensional adjudication information. This multi-dimensional adjudication information includes at least one of semantic dimension information, authority dimension information, and timeline dimension information. By comprehensively considering this multi-dimensional adjudication information, a better version processing strategy can be dynamically selected for different file types and conflict scenarios, avoiding misjudgments caused by single-dimensional judgments and significantly improving the security and reliability of automated merging results.

[0068] For example, the preset version ruling rules may include a second ruling rule, which is used to perform differentiated automatic rulings from multiple dimensions (such as timeline, semantic, and authority dimensions). Specifically, the timeline-level version ruling determines which party made the update based on the last commit time. The semantic-level version ruling determines the nature of the change (such as automatically generated or manually modified) based on preset keywords in the commit message. The authority-level version ruling determines which branch is authoritative for a particular file type based on the file type and the source branch. It should be noted that during the version ruling process, the commit records of the source branch and the target integration branch can be obtained, and information such as the last commit time, committer, and commit message can be extracted from these records. Optionally, the preset version ruling rules include the first and second ruling rules as described above.

[0069] The second ruling rule includes multiple sub-rules, such as the first, second, third, fourth, and fifth sub-rules.

[0070] The first sub-rule (semantic dimension - export table artifact identification) is used to identify automatically generated configuration files based on the semantic recognition of file commit descriptions. If the commit description of the first resource file corresponding to the second target file contains preset keywords related to automatic generation, the second target file is determined to be an export table artifact (first file type), and a restoration operation is performed on the second target file to retain the original configuration table version in the target integration branch.

[0071] The second sub-rule (Authority Dimension - UI Project Priority) is used to determine the authority level of user interface configurations based on the file source. If the second target file belongs to the user interface configuration (third file type), and a third resource file corresponding to that file exists in the user interface project branch, then the user interface project branch is determined to be the authoritative source of that type of file, and the second target file is replaced with the third resource file to ensure that the UI interface is consistent with the version exported from the project.

[0072] The third sub-rule (Authority Dimension - Art Resources Priority) is used to adjudicate binary resources based on the authority level of the file source. If the second target file is a binary resource (fourth file type), and a fourth resource file corresponding to that file exists in the art resource directory, then the art resource directory is determined to be the authoritative source of that type of file, and the second target file is replaced with the fourth resource file to ensure that the art resources loaded at game runtime are the latest version.

[0073] The fourth sub-rule (Timeline Dimension - Significant Updates Take Newest) is used to determine which configuration files require manual maintenance based on the timeline difference of the last commit time. If the second target file is a configuration file requiring manual maintenance (second file type), then the commit time Tsrc of the source branch and the commit time Ttgt of the target integration branch are obtained. If Tsrc > Ttgt + Δt (Δt is a preset time difference threshold), then the changes in the source branch are determined to be significant updates, and the second target file is replaced with the first resource file; if Ttgt > Tsrc + Δt, then the changes in the target integration branch are determined to be validly retained, and the second target file is replaced with the second resource file before the target integration branch was merged.

[0074] The fifth sub-rule (fallback - manual confirmation) is used as a fallback for conflicts that cannot be automatically resolved by the aforementioned sub-rules. If the commit time difference between the source branch and the target integration branch is |Tsrc If Ttgt∣≤Δt, and although the file content differs, it cannot be clearly attributed based on semantics or authority. In this case, it is determined that automatic adjudication is not possible, a first flag is set for the second target file, and the information is summarized in a report containing information about both files (such as submitter, submission time, and differences) for human intervention in decision-making. The first flag is used to indicate human confirmation; for example, the first flag is MANUAL.

[0075] In some embodiments, where the second adjudication rule includes a first sub-rule, a second sub-rule, a third sub-rule, a fourth sub-rule, and a fifth sub-rule, the first sub-rule has a higher priority than the second sub-rule, the second sub-rule has a higher priority than the third sub-rule, the third sub-rule has a higher priority than the fourth sub-rule, and the fourth sub-rule has a higher priority than the fifth sub-rule. The sub-rules can be executed in descending order of priority, stopping upon the first hit.

[0076] In some embodiments, the aforementioned plurality of preset file types further includes a second file type; based on preset version ruling rules and the preset file type to which the second target file belongs, version processing is performed on the second target file, including: if the second target file belongs to the second file type, comparing the commit time of the source branch with the commit time of the target integration branch; if the commit time of the source branch is greater than the sum of the commit time of the target integration branch and a time difference threshold, then the second target file is replaced with the corresponding first resource file; if the commit time of the target integration branch is greater than the sum of the commit time of the source branch and a time difference threshold, then the second target file is replaced with the second resource file corresponding to the second target file before merging in the target integration branch. It can be understood that this implementation is executed when the fourth sub-rule is met.

[0077] In the weekly merging scenario, the time difference threshold can range from 3 to 7 days, specifically 3, 4, 5, 6, or 7 days. In the monthly merging scenario, the time difference threshold can range from 7 to 30 days, specifically 7, 10, 15, 20, 25, or 30 days.

[0078] It should be noted that by setting a configurable time difference threshold, misjudgments caused by time overlap can be reduced, significantly improving the security and reliability of automated merging results.

[0079] In some embodiments, if the second target file belongs to the second file type and does not match the first adjudication rule, the second target file is version-processed based on the fourth sub-rule as described above.

[0080] In some embodiments, if the time difference between the commit times of the source branch and the target integration branch is less than or equal to a time difference threshold, a first flag is set for the second target file. Based on the file information of the resource files corresponding to each second target file with the first flag set before the merge in the source branch and the target integration branch, a report indicating that automatic version ruling cannot be performed is generated and output. This report may include the file path and filename of the resource file before the merge, as well as the latest commit information for that resource file from both the target integration branch and the source branch, such as commit time, committer, and update content. It is understood that this implementation is executed when the fifth sub-rule is met.

[0081] It should be noted that by uniformly setting the first marker and centrally summarizing all files that cannot be automatically adjudicated into the same structured report, there is no need to pause the automated merging workflow at each file and wait for manual confirmation, thus avoiding a precipitous drop in processing efficiency caused by interruptions to each file; at the same time, the report fully records the file paths, submitters, submission times and differences between the two branches, providing a traceable basis for decision-making for subsequent manual batch review and merging audit.

[0082] In some embodiments, based on preset version ruling rules and the preset file type to which the second target file belongs, version processing of the second target file is performed, including: if the submission description of the first resource file corresponding to the second target file includes preset keywords related to automatic generation, then the second target file is determined to belong to the first file type, and a restoration operation is performed on the second target file. It can be understood that this implementation is executed when the first sub-rule is met.

[0083] In some embodiments, the aforementioned plurality of preset file types further includes a third file type; based on preset version ruling rules and the preset file type to which the second target file belongs, version processing is performed on the second target file, including: if the second target file belongs to a third file type, and the user interface project branch has a third resource file corresponding to the second target file, then the second target file is replaced with the third resource file. It can be understood that this implementation is executed when the second sub-rule is met.

[0084] In some embodiments, the aforementioned plurality of preset file types further includes a fourth file type. Based on preset version ruling rules and the preset file type to which the second target file belongs, version processing is performed on the second target file, including: if the second target file belongs to the fourth file type and there is a fourth resource file corresponding to the second target file in the art resource directory, then the second target file is replaced with the fourth resource file. It can be understood that this implementation is executed when the third sub-rule is met.

[0085] Figure 1 The corresponding implementation provides a solution that effectively improves the efficiency and accuracy of merging multiple resource branches through automated classification and differentiated processing mechanisms. Specifically, by merging source branch files into the local directory of the target integration branch and classifying the changed resource files generated by the merge according to preset types, it can quickly identify automatically generated configuration files (the first file type) and directly perform restoration operations, avoiding redundant conflict detection and adjudication for such files that do not require manual intervention. For other files, content consistency is judged (restoration if consistent), reducing unnecessary version processing overhead. For files with inconsistent content, targeted processing is performed based on preset version adjudication rules and their file types, avoiding the loss of effective modifications or inefficiency caused by traditional global strategies (such as blind overwriting or full manual verification). Overall, this solution automates and refines the merging process through pre-classification, content filtering, and rule-based adjudication, significantly reducing the cost of manual intervention while ensuring the reliability of the merging results.

[0086] In some embodiments, before performing the restore operation on each first target file of the first file type in each changed resource file, the first target file corresponding to the first resource file of the first file type in the source branch, and the second resource file before merging corresponding to the first target file in the target integration branch can be obtained. Based on the differences between the first target file and the second resource file, a difference report can be generated. Further, row-level differences can be aggregated according to the grouping field information as described above to generate a difference report, so that planners can confirm whether it is necessary to re-export the configuration table in the target integration branch.

[0087] For example, the first target file and the second resource file can be parsed into a key-value pair data structure stored in JSON format. An index can be built using the primary key of each data entry (such as the Id field value) as the key. Differences can be identified through set operations, such as identifying newly added, deleted, and modified rows. For modified rows, each field value is recursively compared to pinpoint the specific changed field name and its value before and after the change. Additionally, if the first target file and the second resource file contain grouping fields in their grouping field information, row-level differences are aggregated according to the values ​​of these grouping fields, generating a paginated difference report. Using the level.json file as an example, a sample difference report could be: "─level.json [Modify]" The line numbers that have been modified are: 1001, 1002, and 2003. Page Break Figure 1 」: ≠ Modify line 1001: cLevelName: 'Elementary Scene' → 'Elementary Scene V2', iDifficulty: 1 → 2 Added a new row 1002: cLevelName='Newbie Guide Level', iDifficulty=1 Page Break Figure 2 」: - Delete line 2003: cLevelName='Abandoned Level', iDifficulty=3” Optionally, the above difference report can be simplified to generate a simplified planning report file, which can be sent to the planners to confirm whether the corresponding configuration table needs to be re-exported in the target integration branch.

[0088] It should be noted that after merging large game resource directories, the number of files to be submitted can reach several thousand. Submitting all at once results in long processing times and a high probability of timeouts on the SVN server; furthermore, if submission fails, it's impossible to determine which files were successfully submitted. This application proposes a batch submission strategy.

[0089] In some embodiments, the batching strategy includes: grouping the list of files to be submitted by a first-level parent directory to obtain multiple directory groups; and dividing each directory group into one or more sub-batches according to a preset maximum number of files per batch. In one example, the maximum number of files per batch can be 40, 45, 50, 55, or 60, etc., and can be set according to actual needs, without specific limitations here. Specifically, for any directory group, when the number of files in the directory group is less than or equal to the maximum number of files per batch, the directory group is treated as a sub-batch. When the number of files in the directory group exceeds the maximum number of files per batch, the directory group is divided into multiple sub-batches according to the lexicographical order of the filenames.

[0090] In some embodiments, the commit operation is performed sequentially on each sub-batch. For sub-batches that are successfully committed, the identifier of the sub-batch is written to the commit progress file. For sub-batches that fail to commit, the identifier of the sub-batch is written to the failed batch record, the sub-batch is skipped, and the commit operation of subsequent sub-batches continues until all sub-batches are completed, thus avoiding the interruption of the entire commit process due to the failure of a single sub-batch.

[0091] In some embodiments, after all sub-batches have been executed, a retry operation is performed on the failed sub-batches in the failed batch record, with the number of retries not exceeding a preset maximum number of retries. In one example, this maximum number of retries can be 2 or 3, etc., and can be set according to actual needs; no specific limitation is made here.

[0092] In some embodiments, if the commit process is interrupted due to external reasons (such as network interruption or process termination), when the commit operation is executed again, the commit progress file is read, the successfully committed sub-batches recorded therein are skipped, and the commit operation is only performed on the uncommitted sub-batches, thereby realizing breakpoint recovery.

[0093] The aforementioned batching strategy can reduce the risk of large-scale submission failures to the single-batch granularity. Combined with failure batch records and breakpoint recovery, it ensures the reliability of merging and submitting large amounts of resources.

[0094] The method proposed in this application has the following beneficial effects: 1. Reduce manual judgment workload: Through MD5 pre-judgment, about 60% of M-status files can be automatically excluded in a single merge without manual intervention; file type classification automatically distinguishes between export table artifacts and manual configurations, avoiding the burden of maintaining static whitelists.

[0095] 2. Prevent the loss of valid changes: The timeline adjudication rules have clear priorities to avoid global accept theirs, which would cause valid changes in the April branch to be overwritten by the old version of SDC.

[0096] 3. Traceable Decisions: All automated decision results and MANUAL tags are output as structured reports, which can be merged to audit the final source and cause of each document.

[0097] 4. Design a user-friendly export table review: Export table difference reports aggregated by grouping fields, using in-game business language (such as "location"). Figure 1 ","land Figure 2 With changes to the pagination description, the design team can confirm whether the table needs to be re-imported without having to view the original JSON.

[0098] 5. High scalability: Both the SHEET_GROUP_FIELD dictionary and file type classification rules are configuration items. When adding a new configuration table, you only need to add a mapping line to the dictionary without modifying the core logic.

[0099] Figure 2 This is a schematic diagram of the structure of the resource multi-branch merging processing device provided in an embodiment of this application. For example... Figure 2 As shown, the processing apparatus includes: Merging unit 201 is configured to merge each of the first resource files to be merged in the source branch into the local directory of the target integration branch; The classification unit 202 is configured to classify each changed resource file generated by merging in the local directory using a preset file type classification rule; wherein the file type classification rule corresponds to multiple preset file types, including a first file type, which is used to indicate the automatically generated configuration file; The first processing unit 203 is configured to perform a restore operation on each first target file belonging to the first file type in each changed resource file; The second processing unit 204 is configured to perform a restore operation on each second target file other than the first target file in each changed resource file if the content of the second target file is consistent with the content of the corresponding first resource file; if the content of the second target file is inconsistent with the content of the corresponding first resource file, then perform version processing on the second target file based on the preset version adjudication rules and the preset file type to which the second target file belongs.

[0100] For details regarding the specific implementation of the above-mentioned processing device and its various units, as well as their beneficial effects, please refer to the relevant descriptions of the method embodiments above, which will not be repeated here.

[0101] Accordingly, this application also provides an electronic device, which can be a terminal, such as a smartphone, tablet computer, laptop computer, touch screen, game console, personal computer (PC), personal digital assistant (PDA), or other terminal device. Alternatively, the electronic device can be a server.

[0102] like Figure 3 As shown, Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device 300 includes a processor 301 with one or more processing cores, a memory 302 with one or more computer-readable storage media, and a computer program stored in the memory 302 and executable on the processor. The processor 301 and the memory 302 are electrically connected. Those skilled in the art will understand that the electronic device structure shown in the figure does not constitute a limitation on the electronic device, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0103] The processor 301 is the control center of the electronic device 300. It connects various parts of the electronic device 300 via various interfaces and lines. By running or loading software programs and / or units stored in the memory 302, and by calling data stored in the memory 302, it executes various functions and processes data of the electronic device 300, thereby providing overall monitoring of the electronic device 300. The processor 301 can be a central processing unit (CPU), a graphics processing unit (GPU), a network processor (NP), etc., and can implement or execute the methods, steps, and logic diagrams disclosed in the embodiments of this application.

[0104] In this embodiment, the processor 301 in the electronic device 300 loads the instructions corresponding to the processes of one or more applications into the memory 302 according to the following steps, and the processor 301 runs the applications stored in the memory 302 to realize various functions, such as: Merge each of the first resource files to be merged in the source branch into the local directory of the target integration branch; For each changed resource file generated by merging in the local directory, the changed resource files are classified according to the preset file type classification rules; wherein, the file type classification rules correspond to multiple preset file types, including a first file type, which is used to indicate the automatically generated configuration file; Perform a restore operation on each first target file that belongs to the first file type in each changed resource file; For each second target file other than the first target file in each changed resource file, if the content of the second target file is consistent with the corresponding first resource file, then the second target file is restored. If the content of the second target file is inconsistent with that of the corresponding first resource file, the second target file will be processed according to the preset version adjudication rules and the preset file type to which the second target file belongs.

[0105] By employing automated classification and differentiated processing mechanisms, the efficiency and accuracy of merging multiple branches of resources are effectively improved.

[0106] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0107] Optional, such as Figure 3 As shown, the electronic device 300 also includes: a touch display screen 303, a radio frequency circuit 304, an audio circuit 305, an input unit 306, and a power supply 307. The processor 301 is electrically connected to the touch display screen 303, the radio frequency circuit 304, the audio circuit 305, the input unit 306, and the power supply 307. Those skilled in the art will understand that... Figure 3 The electronic device structure shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0108] The touch display screen 303 can be used to display a graphical user interface (GUI) and receive operation commands generated by the user interacting with the GUI. The touch display screen 303 may include a display panel and a touch panel. The display panel can be used to display information input by the user or information provided to the user, as well as various graphical user interfaces of the electronic device. These graphical user interfaces can be composed of graphics, text, icons, video, and any combination thereof. Optionally, the display panel can be configured using a liquid crystal display (LCD), organic light-emitting diode (OLED), or other similar technologies. The touch panel can be used to collect touch operations performed by the user on or near it (such as operations performed by the user using a finger, stylus, or any suitable object or accessory on or near the touch panel), generate corresponding operation commands, and execute the corresponding program according to the operation commands. Optionally, the touch panel may include two parts: a touch detection device and a touch controller. The touch detection device detects the user's touch location and the signal generated by the touch operation, transmitting the signal to the touch controller. The touch controller receives touch information from the touch detection device, converts it into touch point coordinates, and sends it to the processor 301. It can also receive and execute commands from the processor 301. The touch panel can cover the display panel. When the touch panel detects a touch operation on or near it, it transmits the information to the processor 301 to determine the type of touch event. Subsequently, the processor 301 provides corresponding visual output on the display panel based on the type of touch event. In this embodiment, the touch panel and the display panel can be integrated into the touch display screen 303 to achieve input and output functions. However, in some embodiments, the touch panel and the touch display screen 303 can be implemented as two independent components to achieve input and output functions. That is, the touch display screen 303 can also be used as part of the input unit 306 to achieve input functions.

[0109] The radio frequency circuit 304 can be used to transmit and receive radio frequency signals to establish wireless communication with network devices or other electronic devices, and to transmit and receive signals with network devices or other electronic devices.

[0110] Audio circuitry 305 can be used to provide an audio interface between a user and an electronic device via a speaker and a microphone. Audio circuitry 305 converts received audio data into electrical signals, transmits them to the speaker, and the speaker converts them into sound signals for output. Conversely, the microphone converts collected sound signals into electrical signals, which are then received by audio circuitry 305, converted back into audio data, and then processed by processor 301 before being transmitted via radio frequency circuitry 304 to, for example, another electronic device, or output to memory 302 for further processing. Audio circuitry 305 may also include an earphone jack to facilitate communication between peripheral headphones and electronic devices.

[0111] The input unit 306 can be used to receive input numbers, characters, or user characteristic information (such as fingerprints, iris, facial information, etc.), and to generate keyboard, mouse, joystick, optical, or trackball signal inputs related to user settings and function control.

[0112] Power supply 307 is used to supply power to various components of electronic device 300. Optionally, power supply 307 can be logically connected to processor 301 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. Power supply 307 may also include one or more DC or AC power supplies, recharging systems, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0113] although Figure 3 As not shown in the diagram, the electronic device 300 may also include a camera, sensor, wireless fidelity module, Bluetooth module, etc., which will not be described in detail here.

[0114] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0115] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0116] Therefore, embodiments of this application provide a computer-readable storage medium storing multiple computer programs that can be loaded by a processor to execute the resource multi-branch merging processing method provided in embodiments of this application. The computer program can execute the following steps of the resource multi-branch merging processing method: Merge each of the first resource files to be merged in the source branch into the local directory of the target integration branch; For each changed resource file generated by merging in the local directory, the changed resource files are classified according to the preset file type classification rules; wherein, the file type classification rules correspond to multiple preset file types, including a first file type, which is used to indicate the automatically generated configuration file; Perform a restore operation on each first target file that belongs to the first file type in each changed resource file; For each second target file other than the first target file in each changed resource file, if the content of the second target file is consistent with the corresponding first resource file, then the second target file is restored. If the content of the second target file is inconsistent with that of the corresponding first resource file, the second target file will be processed according to the preset version adjudication rules and the preset file type to which the second target file belongs.

[0117] By employing automated classification and differentiated processing mechanisms, the efficiency and accuracy of merging multiple branches of resources are effectively improved.

[0118] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0119] The computer-readable storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0120] Since the computer program stored in the computer-readable storage medium can execute any of the resource multi-branch merging processing methods provided in the embodiments of this application, it can achieve the beneficial effects that any of the resource multi-branch merging processing methods provided in the embodiments of this application can achieve, as detailed in the preceding embodiments, and will not be repeated here.

[0121] According to one aspect of this application, a computer program product or computer program is also provided, comprising computer instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the electronic device to perform the methods provided in the various optional implementations of the above embodiments.

[0122] In the above embodiments of the resource multi-branch merging processing method, resource multi-branch merging processing apparatus, resource merging adjudication system, computer-readable storage medium, electronic device, and computer program product, the descriptions of each embodiment have different focuses. Parts not described in detail in a certain embodiment can be referred to the relevant descriptions of other embodiments. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes and beneficial effects of the resource multi-branch merging processing method, resource multi-branch merging processing apparatus, resource merging adjudication system, computer-readable storage medium, computer program product, electronic device, and their corresponding units described above can be referred to the descriptions of the relevant methods in the above embodiments, and will not be repeated here.

[0123] The above provides a detailed description of the resource multi-branch merging processing method, apparatus, electronic device, and storage medium provided in the embodiments of this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.< / target>

Claims

1. A method for merging multiple branches of resources, characterized in that, include: Merge each of the first resource files to be merged in the source branch into the local directory of the target integration branch; For each changed resource file generated by merging in the local directory, each changed resource file is classified using a preset file type classification rule; wherein, the file type classification rule corresponds to multiple preset file types, and the multiple preset file types include a first file type, which is used to indicate the automatically generated configuration file; For each first target file belonging to the first file type in each of the aforementioned changed resource files, perform a restore operation; For each second target file other than the first target file in each of the modified resource files, if the content of the second target file is consistent with the content of the corresponding first resource file, then a restore operation is performed on the second target file; If the content of the second target file is inconsistent with that of the corresponding first resource file, then the second target file is processed for version control based on the preset version adjudication rules and the preset file type to which the second target file belongs.

2. The processing method according to claim 1, characterized in that, The version adjudication rules are used to make differentiated automatic adjudications based on multi-dimensional adjudication information; wherein, the multi-dimensional adjudication information includes at least one of semantic dimension information, authority dimension information, and timeline dimension information.

3. The processing method according to claim 1, characterized in that, The methods for determining whether the content of the second target file is consistent with the corresponding first resource file include: Determine the absolute value of the difference between the file size of the second target file and the corresponding first resource file; If the ratio of the absolute value to the file size of the second target file is greater than a preset threshold, then it is determined that the content of the second target file is inconsistent with the content of the corresponding first resource file; If the ratio is less than or equal to the preset threshold, then the second target file is hashed using a preset first hash algorithm to obtain a first hash value, and the first resource file corresponding to the second target file is hashed to obtain a second hash value. Based on the comparison result between the first hash value and the second hash value, it is determined whether the content of the second target file is consistent with the corresponding first resource file.

4. The processing method according to claim 3, characterized in that, Based on the comparison result between the first hash value and the second hash value, the consistency between the content of the second target file and the corresponding first resource file is determined, including: If the first hash value is different from the second hash value, then it is determined that the content of the second target file is inconsistent with the content of the corresponding first resource file; If the first hash value is the same as the second hash value, then it is determined that the content of the second target file is consistent with the content of the corresponding first resource file.

5. The processing method according to claim 3, characterized in that, Based on the comparison result between the first hash value and the second hash value, the consistency between the content of the second target file and the corresponding first resource file is determined, including: If the first hash value is different from the second hash value, then it is determined that the content of the second target file is inconsistent with the content of the corresponding first resource file; If the first hash value is the same as the second hash value, then the second target file is hashed using a preset second hash algorithm to obtain a third hash value, and the first resource file corresponding to the second target file is hashed to obtain a fourth hash value; wherein, the calculation speed of the first hash algorithm is higher than that of the second hash algorithm; If the third hash value is different from the fourth hash value, then it is determined that the content of the second target file is inconsistent with the content of the corresponding first resource file; If the third hash value is the same as the fourth hash value, then it is determined that the content of the second target file is consistent with the content of the corresponding first resource file.

6. The processing method according to claim 1, characterized in that, The plurality of preset file types also includes a second file type, which is used to indicate configuration files that require manual maintenance; The version processing of the second target file based on the preset version adjudication rules and the preset file type to which the second target file belongs includes: In response to the fact that the second target file belongs to the second file type and there is bidirectional modification between the source branch and the target integration branch, a set operation is performed on the key set of the resource files before merging corresponding to the second target file in multiple data sources to obtain the operation result; wherein, the multiple data sources include the source branch, the target integration branch and the art resource directory; Based on the calculation results, the second target file is updated to the second resource file before merging in the target integration branch, and the updated second resource file is used to replace the second target file.

7. The processing method according to claim 6, characterized in that, The calculation result includes a first key unique to the source branch and a second key common to all the data sources; Based on the calculation results, the second resource file of the second target file before merging in the target integration branch is updated, including: Write the content corresponding to the first key in the first resource file corresponding to the second target file into the second resource file; If the content corresponding to the second key in each of the data sources is not completely the same, then generate and output content confirmation information for the second key; In response to receiving feedback information regarding the content confirmation information, a target resource file is determined from each of the resource files before merging based on the feedback information, and if the target resource file and the second resource file are not the same file, the content corresponding to the second key in the target resource file is written into the second resource file.

8. The processing method according to claim 1, characterized in that, The plurality of preset file types also includes a second file type, which is used to indicate configuration files that require manual maintenance; The version processing of the second target file based on the preset version adjudication rules and the preset file type to which the second target file belongs includes: If the second target file belongs to the second file type, compare the commit time of the source branch with the commit time of the target integration branch; If the commit time of the source branch is greater than the sum of the commit time of the target integration branch and the time difference threshold, then the second target file is replaced with the corresponding first resource file; If the commit time of the target integration branch is greater than the sum of the commit time of the source branch and the time difference threshold, then the second target file is replaced with the second resource file before the merge corresponding to the target integration branch.

9. The processing method according to claim 8, characterized in that, Also includes: If the time difference between the commit times of the source branch and the target integration branch is less than or equal to the time difference threshold, then a first flag is set for the second target file; Based on the file information of the resource files of each of the second target files with the first mark set before merging in the source branch and the target integration branch respectively, a report is generated and output to indicate that automatic version ruling cannot be performed.

10. The processing method according to claim 1, characterized in that, The version processing of the second target file based on the preset version adjudication rules and the preset file type to which the second target file belongs includes: If the submission description of the first resource file corresponding to the second target file includes preset keywords related to automatic generation, then the second target file is determined to belong to the first file type, and a restoration operation is performed on the second target file.

11. The processing method according to claim 1, characterized in that, The plurality of preset file types also includes a third file type, which is used to indicate user interface configuration; The version processing of the second target file based on the preset version adjudication rules and the preset file type to which the second target file belongs includes: If the second target file belongs to the third file type, and the user interface project branch has a third resource file corresponding to the second target file, then the second target file is replaced with the third resource file.

12. The processing method according to claim 1, characterized in that, The plurality of preset file types also includes a fourth file type, which is used to indicate binary resources; The version processing of the second target file based on the preset version adjudication rules and the preset file type to which the second target file belongs includes: If the second target file belongs to the fourth file type, and the art resource directory contains a fourth resource file corresponding to the second target file, then the fourth resource file is used to replace the second target file.

13. The processing method according to claim 1, characterized in that, Before performing the restore operation on each first target file belonging to the first file type in each of the aforementioned changed resource files, the method further includes: For the first resource file belonging to the first file type in the source branch, obtain the first target file corresponding to the first resource file, and the second resource file of the first target file before merging in the target integration branch; A difference report is generated based on the differences between the first target file and the second resource file.

14. The processing method according to claim 1, characterized in that, The file type classification rule includes a first condition corresponding to the first file type. The first condition indicates that the file path includes a first preset path and satisfies any of the following sub-conditions: the file name is included in preset grouping field information, which describes the correspondence between the file name and the grouping field; the file submission description includes preset keywords related to automatic generation.

15. The processing method according to claim 14, characterized in that, The plurality of preset file types also include a second file type, and the file type classification rule also includes a second condition corresponding to the second file type. The second file type is used to indicate configuration files that need to be manually maintained, and the second condition is that the file path includes the root directory of the first preset path but does not belong to the first file type. And / or, The plurality of preset file types also includes a third file type. The file type classification rules also include a third condition corresponding to the third file type. The third file type is used to indicate user interface configuration. The third condition is that the file path includes a second preset path and the file extension includes a preset first extension; and / or, The plurality of preset file types also include a fourth file type, and the file type classification rule also includes a fourth condition corresponding to the fourth file type. The fourth file type is used to indicate binary resources, and the fourth condition is that the file extension is included in a preset second extension set.

16. A processing apparatus for merging multiple branches of resources, characterized in that, include: The merge unit is configured to merge each of the first resource files to be merged in the source branch into the local directory of the target integration branch; The classification unit is configured to classify each of the merged modified resource files in the local directory using a preset file type classification rule; wherein the file type classification rule corresponds to multiple preset file types, and the multiple preset file types include a first file type, which is used to indicate an automatically generated configuration file; The first processing unit is configured to perform a restore operation on each first target file belonging to the first file type in each of the changed resource files; The second processing unit is configured to, for each second target file other than the first target file in each of the modified resource files, perform a restore operation on the second target file if the content of the second target file is consistent with the content of the corresponding first resource file; and perform version processing on the second target file based on the preset version adjudication rules and the preset file type to which the second target file belongs.

17. An electronic device, characterized in that, The system includes a memory and a processor. The memory stores a computer program, which, when executed by the processor, implements the processing method as described in any one of claims 1-15.

18. A computer-readable storage medium, characterized in that, It stores a computer program, which is loaded by a processor to execute the steps of the processing method according to any one of claims 1-15.

Images