Software development data management method and system based on cloud service

Abstract

The invention provides a software development data management method and system based on cloud service. The method comprises the following steps: acquiring code version difference data generated in a multi-version development process from a cloud service environment, and allocating the code version difference data to a corresponding storage position according to a version sequence identifier; a version relation graph is constructed based on the calling relation between the version branches, and the data flow direction and the logic dependency relation between versions are dynamically recorded; carrying out sorting and logic dependence verification on conflict contents in combination with the conflict state and the merging strategy, and generating a traceable merging operation instruction set; and finally, executing feedback data according to an instruction set to update a graph conflict state, synchronously triggering storage data update and redistribution of version identifiers, and realizing full-link closed-loop management of development data. According to the technical scheme provided by the invention, the efficiency and accuracy of software development data management can be improved.

Description

Technical Field

[0001] The present application relates to the technical field of software development data management, and in particular to a software development data management method and system based on cloud services. Background Art

[0002] In multi-version parallel software development scenarios supported by cloud services, multiple development teams or individuals often develop functional branches within the same project, resulting in frequent code merges and overlapping versions. This application scenario requires the construction of an efficient data management method that can detect code conflicts between different versions in real time and enable dynamic merges without interrupting the development process. In addition, it must support version tracking, change impact analysis, and automated merge suggestion generation in a cloud-based collaborative development environment to improve development efficiency and code quality, while reducing the risk of errors caused by manual intervention.

[0003] To address these technical requirements, some cloud-based development platforms have introduced structured code difference analysis mechanisms, combining them with abstract syntax tree comparison technology to identify code conflicts. This solution parses different versions of code into a unified grammatical structure representation, automatically identifying changes to key elements such as functions, variables, and control flow, and then determining whether there are logical or structural conflicts. The system also integrates a lightweight merge strategy engine that provides preliminary merge suggestions when conflicts are detected and feeds the results back to the developer for confirmation, forming a somewhat automated conflict resolution process.

[0004] However, this existing solution still has obvious limitations. First, it relies on a static syntax comparison mechanism, which makes it difficult to accurately identify conflicts at the semantic level, such as changes in logical order or destruction of contextual dependencies. Second, this method lacks the ability to understand the context of development behavior and cannot make intelligent merging decisions based on the purpose and intention of code changes, resulting in a large number of inefficient manual reviews. In addition, when faced with large-scale concurrent development scenarios, the system response delay is high and the merging process is not stable enough, affecting the overall collaboration efficiency. Therefore, there is an urgent need for a more intelligent cloud-based software development data management method with semantic understanding capabilities and efficient collaboration mechanisms to meet the complex challenges brought about by multi-version parallel development. Summary of the Invention

[0005] The present application provides a cloud service-based software development data management method and system to solve the problems of low efficiency and poor accuracy of software development data management in the prior art.

[0006] In a first aspect, the present application provides a software development data management method based on cloud services, comprising:

[0007] Obtain code version difference data generated during the multi-version software development process in the cloud service environment, and allocate the code version difference data to a storage location corresponding to the version sequence identifier according to the version sequence identifier;

[0008] Based on the calling relationship between the version branches in the code version difference data, a version relationship graph is constructed to reflect the data flow direction and logical dependency relationship between the versions;

[0009] According to the conflict status and correlation strength of the logical dependency relationships in the version relationship graph, a multi-version merging strategy adapted to multi-version software development is matched from a preset strategy library;

[0010] When concurrent modification requests are detected for code with the same version sequence identifier, based on the conflict status of the version relationship graph and the multi-version merge strategy, the conflicting contents in the code version difference data are sorted and logical dependencies are verified to generate a merge operation instruction set;

[0011] According to the feedback data of the merge operation instruction set, the conflict status in the version relationship map is updated, and the data update of the storage location and the reallocation of the version sequence identifier are synchronously triggered.

[0012] Optionally, the step of sorting the conflicting contents in the code version difference data and performing logical dependency verification based on the conflict status of the version relationship graph and the multi-version merge strategy to generate a merge operation instruction set includes:

[0013] Extracting a logical dependency relationship associated with the conflict state from the version relationship graph, wherein the logical dependency relationship includes interface parameter type requirements, return value format rules, and call sequence requirements;

[0014] Based on the conflict handling priority rules defined in the multi-version merge strategy, the conflicting contents in the code version difference data are sorted to generate a conflicting content sequence;

[0015] According to the interface parameter type requirements and call sequence requirements in the logical dependency relationship, perform parameter type matching verification and call sequence consistency verification on each conflicting content identifier in the conflicting content sequence, and mark the conflicting content identifier that fails the verification as a conflict to be processed item;

[0016] The verified conflict content identifiers in the conflict content sequence are converted into executable operation instructions, prompt information is generated for the conflicting items to be processed, and the executable operation instructions and the prompt information are combined in an execution order to generate a merged operation instruction set.

[0017] Optionally, sorting the conflicting contents in the code version difference data based on the conflict handling priority rules defined in the multi-version merge strategy to generate a conflicting content sequence includes:

[0018] Extracting the conflict type, associated version sequence identifier, and submitter identifier corresponding to each conflict content in the code version difference data, and generating a conflict content attribute set;

[0019] performing a preliminary classification of the conflicting contents in the conflicting content attribute set according to the conflict handling priority rule defined in the multi-version merge strategy to generate a conflicting content classification set;

[0020] Based on the version submission time condition and the submitter authority condition in the conflict handling priority rule, the sorting weight value of the conflicting content in the conflicting content classification set is calculated, and the conflicting content in the conflicting content classification set is sorted according to the sorting weight value to generate a conflicting content sequence.

[0021] Optionally, the constructing of a version relationship graph reflecting the data flow direction and logical dependency relationship between versions based on the calling relationship between the version branches in the code version difference data includes:

[0022] Extracting call records between each version branch from the code version difference data, wherein the call record includes a calling version identifier, a called version identifier, and a call operation type;

[0023] Determine the data flow direction between the calling version identifier and the called version identifier according to the calling operation type in the calling record, and establish a data flow link from the called version identifier to the calling version identifier according to the data flow direction;

[0024] Based on the interface constraint in the called version identifier, marking the corresponding logical dependency on the data flow link;

[0025] The data flow link and the logical dependency relationship are combined according to the version identifier to form a version relationship graph with the version identifier as the node and the data flow link and the logical dependency relationship as the connection relationship.

[0026] Optionally, matching a multi-version merging strategy adapted to multi-version software development from a preset strategy library based on the conflict status and association strength of the logical dependency relationships in the version relationship graph includes:

[0027] Determine the conflicting major version identifier and minor version identifier according to the conflict status marked in the version relationship map, where the major version identifier is the version corresponding to the current main development path;

[0028] Extracting a logical dependency relationship between the major version identifier and the minor version identifier, identifying a set of constraints affected by the conflict from the logical dependency relationship, and calculating a conflict impact value based on the number of constraints in the constraint set and a preset weight value;

[0029] A merge strategy whose applicable conflict type matches the conflict status and whose priority value is positively correlated with the conflict impact value is selected from the preset strategy library, and the merge strategy, major version identifier and minor version identifier are correspondingly associated to generate a multi-version merge strategy.

[0030] Optionally, extracting the logical dependency relationship between the major version identifier and the minor version identifier, and identifying a set of constraint conditions affected by the conflict from the logical dependency relationship, includes:

[0031] Extracting the logical dependency relationship between the major version identifier and the minor version identifier from the version relationship graph, and determining the interactive operation record and interface constraint declaration between the versions based on the logical dependency relationship;

[0032] Analyze the interaction behavior direction in the logical dependency relationship according to the interaction type of the interaction operation record, and generate a constraint validation link;

[0033] Based on the constraint validation link and the interface constraint declaration, the constraint conditions between the major version identifier and the minor version identifier that violate the logical dependency relationship are identified, and a constraint condition set is generated.

[0034] Optionally, updating the conflict status in the version relationship graph according to the feedback data of the merge operation instruction set, and synchronously triggering the data update of the storage location and the reallocation of the version sequence identifier, includes:

[0035] Parsing feedback data of the merge operation instruction set, extracting the modification content identifier, conflict handling status, and conflict content identifier recorded in the feedback data, extracting the modification content corresponding to the modification content identifier from the code version difference data, and storing the modification content in the storage location;

[0036] According to the conflict handling status, updating the data flow link between the major version sequence identifier and the minor version sequence identifier associated with the conflicting content identifier in the version relationship graph to generate a new version sequence identifier;

[0037] The new version sequence identifier is bound to the storage location, and the connection relationship and conflict status of the main version sequence identifier node in the version relationship graph are synchronously updated.

[0038] In a second aspect, the present application provides a cloud-based software development data management system, including:

[0039] An acquisition module is configured to acquire code version difference data generated during the development of multiple versions of software in a cloud service environment, and to allocate the code version difference data to a storage location corresponding to the version sequence identifier according to the version sequence identifier;

[0040] A construction module, based on the calling relationship between the version branches in the code version difference data, constructs a version relationship map reflecting the data flow direction and logical dependency relationship between the versions;

[0041] A matching module, which matches a multi-version merging strategy adapted to multi-version software development from a preset strategy library based on the conflict status and association strength of the logical dependency relationships in the version relationship graph;

[0042] a generation module that, upon detecting concurrent modification requests for code with the same version sequence identifier, sorts the conflicting contents in the code version difference data and performs logical dependency verification based on the conflict status of the version relationship graph and the multi-version merge strategy, and generates a merge operation instruction set;

[0043] An update module updates the conflict status in the version relationship map according to feedback data of the merge operation instruction set, and synchronously triggers the data update of the storage location and the reallocation of the version sequence identifier.

[0044] In a third aspect, an embodiment of the present application provides a computing device comprising a processing component and a storage component; the storage component stores one or more computer instructions; the one or more computer instructions are used to be called and executed by the processing component to implement a cloud service-based software development data management method as described in the first aspect above.

[0045] In a fourth aspect, an embodiment of the present application provides a computer storage medium storing a computer program. When the computer program is executed by a computer, it implements a cloud service-based software development data management method as described in the first aspect.

[0046] In an embodiment of the present application, code version difference data generated during the development of multi-version software in a cloud service environment is obtained, and the code version difference data is allocated to a storage location corresponding to the version sequence identifier according to the version sequence identifier; based on the calling relationship between the version branches in the code version difference data, a version relationship graph reflecting the data flow direction and logical dependency relationship between the versions is constructed; according to the conflict status and correlation strength of the logical dependency relationship in the version relationship graph, a multi-version merge strategy adapted to the multi-version software development is matched from a preset strategy library; when concurrent modification requests are detected for code with the same version sequence identifier, the conflicting content in the code version difference data is sorted and the logical dependency is verified based on the conflict status of the version relationship graph and the multi-version merge strategy, and a merge operation instruction set is generated; according to the feedback data of the merge operation instruction set, the conflict status in the version relationship graph is updated, and the data update of the storage location and the reallocation of the version sequence identifier are synchronously triggered.

[0047] The technical solution of this application has the following beneficial effects:

[0048] This application provides an accurate data source for conflict detection and merging by implementing structured storage and rapid positioning of multi-version difference data, thus avoiding the problem of inefficient retrieval caused by data mixing. Dynamically map the data flow and logical dependencies between versions, track the impact of code modifications on the dependency chain in real time, and provide a visual decision-making basis for conflict analysis. Intelligently select adaptation strategies based on conflict status and dependency strength to improve the accuracy of strategy matching in complex conflict scenarios and reduce the cost of manual intervention. Through conflict content sorting and logical dependency verification, ensure that the merge operation complies with the constraint relationship between versions, and reduce code logic errors caused by policy misjudgment. Establish a closed-loop feedback mechanism for conflict handling, graph update and data synchronization to ensure the consistency of multi-version data and avoid the recurrence of the same conflict.

[0049] Furthermore, in the conflict handling stage, the logical dependencies related to the conflict are first extracted from the version relationship graph, and the conflicting contents are sorted to generate a sequence based on the priority rules of the merge strategy. Subsequently, the conflicting items in the sequence are verified for compliance with the parameter types and call order, and the items that fail the verification are marked as pending items. Finally, the conflicting items that pass the verification are converted into executable instructions, and prompt information is generated for the pending items, which are combined in the order of execution to form an instruction set. Through the dual verification of dynamic priority sorting and logical dependencies, it is ensured that the merge operation strictly follows the constraint rules between versions, significantly reducing the risk of runtime errors in the merged code. At the same time, the prompt information of the conflict pending items provides developers with accurate conflict location and repair suggestions, improves the collaboration efficiency in complex conflict scenarios, and avoids system-level failures caused by omitted verification.

[0050] These and other aspects of the present application will become more readily apparent from the description of the following embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, a brief introduction will be given below to the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0052] Figure 1 A flowchart of a cloud service-based software development data management method provided by the present application is shown;

[0053] Figure 2 A schematic diagram of the structure of a cloud-based software development data management system provided by the present application is shown;

[0054] Figure 3 A schematic structural diagram of a computing device provided by the present application is shown. DETAILED DESCRIPTION

[0055] In order to enable those skilled in the art to better understand the solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application.

[0056] In some of the processes described in the specification and claims of this application and the above-mentioned figures, multiple operations that appear in a specific order are included, but it should be clearly understood that these operations may not be executed in the order in which they appear in this document or may be executed in parallel. The serial numbers of the operations, such as 101, 102, etc., are only used to distinguish between different operations, and the serial numbers themselves do not represent any order of execution. In addition, these processes may include more or fewer operations, and these operations may be executed in sequence or in parallel. It should be noted that the descriptions of "first", "second", etc. in this document are used to distinguish different messages, devices, modules, etc., and do not represent a sequential order, nor do they limit "first" and "second" to being different types.

[0057] Current mainstream automated merge tools based on static dependency analysis have significant limitations in multi-version software development scenarios in cloud service environments. First, static dependency graphs cannot capture dynamic logical dependency changes caused by concurrent modifications on multiple terminals in real time, resulting in delayed or missed conflict detection, making it difficult to meet the cloud service's requirements for high-concurrency modification requests and real-time data synchronization. Second, the policy matching mechanism of the predefined rule base lacks adaptability to complex conflict scenarios. The single policy priority leads to an increased logical error rate in the merged code, and the policy base cannot be dynamically optimized based on historical conflict handling experience. Finally, the existing solution separates merge operations from conflict status management, lacks a dynamic feedback mechanism for the dependency graph and policy base, and causes the same type of conflicts to recur repeatedly during the iteration process, significantly increasing manual troubleshooting costs and reducing collaboration efficiency.

[0058] In response to the above problems, this application proposes a software development data management method based on cloud services. This method achieves breakthroughs through the following technical means: first, based on the code version difference data, a version relationship graph is dynamically constructed to reflect the logical dependency relationship and data flow direction between versions in real time, thereby accurately capturing dynamic logical dependency changes; second, according to the conflict status and correlation strength of the version relationship graph, the merge strategy adapted to the multi-version development scenario is intelligently matched to replace the rigid matching mechanism of the traditional single rule base; third, when concurrent modification requests are detected, the conflicting content is sorted and the logical dependency is verified based on the version relationship graph and the merge strategy to generate a highly reliable merge operation instruction set; finally, the version relationship graph and the storage location data are dynamically updated through feedback data, and the reallocation of the version sequence identifier is triggered to form a closed-loop optimization mechanism. Through dynamic graph construction, intelligent strategy matching and real-time feedback optimization, this solution effectively solves key defects such as the lag of static dependency analysis, insufficient strategy adaptability and lack of conflict handling experience reuse, significantly improving the conflict detection accuracy and merge efficiency of multi-version parallel development in cloud service environments.

[0059] The following will be combined with the drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without making creative efforts are within the scope of protection of this application.

[0060] Figure 1 A flowchart of a software development data management method based on cloud services is provided for an embodiment of the present application. Figure 1 As shown, the method includes:

[0061] 101. Obtain code version difference data generated during the multi-version software development process in the cloud service environment, and allocate the code version difference data to a storage location corresponding to the version sequence identifier according to the version sequence identifier;

[0062] In this step, multi-version software development refers to a collaborative development model in which multiple functional branches, repair branches, and release versions are managed through a version control system during the software development process.

[0063] A cloud service environment refers to a distributed environment that delivers computing power, storage capacity, and network services to users on demand through a virtualized resource pool provided by cloud computing technology.

[0064] Code version difference data refers to the modification records between different versions of the code, including newly added, deleted, or modified code snippets and their metadata.

[0065] A version sequence identifier is a string that uniquely identifies a code version, usually generated by combining a timestamp, hash value, and branch name.

[0066] A storage location refers to a logical storage area in a cloud service that is divided by version identifier and is used to isolate and store differential data between different versions.

[0067] In an embodiment of the present application, first, the code submission events are monitored in real time through the application programming interface of the version control system to collect the code version difference data of each branch in the multi-version software development process, including the newly added, modified or deleted code snippets and function call relationships. Subsequently, a static analysis tool is used to parse the function call chain in the difference data and extract the call relationship between the version branches. Then, a unique version sequence identifier is generated based on the branch name and timestamp, and the identifier is bound to the difference data. Finally, the difference data is stored in the corresponding storage location according to the version sequence identifier through a distributed storage system.

[0068] In a software development project for an intelligent transportation system, multiple development teams are responsible for upgrading different modules. For example, one team focuses on optimizing the signal light control logic, while another team is responsible for updating the traffic flow prediction model. Because the system adopts a multi-version parallel development model, the two teams make code modifications on their respective branches and regularly submit merge requests to the main branch. The system first collects the code changes on each branch and generates a unique version sequence identifier for each submission, classifying and storing the corresponding code version difference data in a specified path. For example, in one submission, the signal light control module added an adaptive adjustment function. The system identified the modified content and stored it in a bound and corresponding version sequence identifier, providing a data basis for subsequent analysis.

[0069] 102. Based on the calling relationship between the version branches in the code version difference data, construct a version relationship map reflecting the data flow direction and logical dependency relationship between the versions;

[0070] In this step, the calling relationship refers to the function call, class inheritance, or interface reference relationship across branches in the code.

[0071] Data flow direction refers to the source and destination of data during code execution.

[0072] Logical dependencies refer to the constraints between codes, including interface parameter matching, return value compatibility, and calling order restrictions.

[0073] A version relationship graph is a graphical data structure used to describe the dependency, call, or evolution relationship between software versions.

[0074] In an embodiment of the present application, first, the code difference data of each version branch is read from the storage location of step 101, and the function call chain and parameter passing relationship are extracted using a static analysis tool. Subsequently, based on a graph database or a memory graph structure, the call relationship is mapped to nodes and edges to construct an initial version relationship graph. Next, when new difference data is written to the storage location, the nodes and edges in the graph are dynamically adjusted through the incremental update mechanism of the graph database to ensure that the graph reflects the dependencies of the latest version. Finally, the correlation strength between nodes is calculated in combination with the logical dependency analysis algorithm, and potential conflict areas are marked. Throughout the entire process, difference data analysis provides the basis for graph construction, the graph database supports dynamic updates, and logical dependency analysis enhances the accuracy of the graph, ultimately forming a version relationship graph that reflects the data flow direction and logical dependency relationships between versions in real time.

[0075] In a software development project for a smart transportation system, the system analyzed the calling relationships between versions based on the previously acquired code version difference data. It discovered that the traffic prediction module depended on some interface definitions in the traffic light control module. Based on this, the system used graph database technology to construct a version relationship map, visually presenting the direction and strength of the dependency between the two versions, forming a complete logical structure model between the versions.

[0076] 103. Matching a multi-version merging strategy adapted to multi-version software development from a preset strategy library based on the conflict status and correlation strength of the logical dependency relationships in the version relationship graph;

[0077] In this step, the conflict status refers to the logical contradiction or functional conflict caused by code modification between versions. For example, the same function is modified in different ways in multiple versions.

[0078] The strength of the association is the closeness of the dependency between versions, which is usually quantified by the call frequency or data flow volume.

[0079] The preset strategy library is a set of rules that stores multiple merge strategies, such as giving priority to retaining the main branch code and automatically rolling back conflicting versions.

[0080] A multi-version merge strategy is a solution developed for specific conflict scenarios to guide code merge operations.

[0081] In an embodiment of the present application, based on the version relationship map, the system analyzes the logical dependencies between the versions, especially whether there is a conflict state and the strength of the association. The conflict state is judged by comparing the modified content of the same function or variable in the code, and the strength of the association is calculated by the number of shared modules and the frequency of interaction. Subsequently, a merge strategy that matches the current conflict state and association strength is searched from the preset strategy library. These strategies may include giving priority to retaining modifications to highly correlated versions, adopting a three-way merge mechanism, or performing manual confirmation intervention. Finally, a set of multi-version merge strategies applicable to the current version combination is output to provide decision support for subsequent specific merge operations.

[0082] When the development team detects that both versions have modified shared configuration parameters, they initiate a conflict assessment process. By analyzing the strength of the association and the type of conflict between the two versions, they select a merge strategy from the strategy library that best fits the situation. This prioritizes preserving the parameter settings on the prediction model side while also recommending appropriate adjustments for the control module.

[0083] 104. When concurrent modification requests are detected for code with the same version sequence identifier, based on the conflict status of the version relationship graph and the multi-version merge strategy, the conflicting contents in the code version difference data are sorted and logical dependencies are verified to generate a merge operation instruction set;

[0084] In this step, concurrent modification requests are requests from multiple developers to modify the code with the same version sequence identifier at the same time.

[0085] Sorting is to arrange conflicting contents according to conflict priority and dependency.

[0086] Logical dependency verification checks whether the conflicting content destroys the call chain or data flow between versions.

[0087] The merge operation instruction set is an operation guide that includes specific merge steps and rules, such as retaining a certain version of code and overwriting a certain version of code.

[0088] In an embodiment of the present application, when the system detects that there are multiple concurrent modification requests for a code identified by a certain version sequence, the conflict detection process is immediately started. Combining the conflict status in the version relationship map with the matched multi-version merge strategy, the conflict content in the relevant code version difference data is sorted and the logical dependency verification is performed. The sorting is based on modification time, version dependency weight and user-specified priority; the logical dependency verification ensures that the merged code does not destroy the original call chain. After the verification is completed, the system generates a set of detailed merge operation instruction sets, including information such as file merge order, conflict resolution suggestions, code insertion points, etc., as a standard guide for the actual execution of the merge.

[0089] Based on this solution, the development team combined the conflict information in the version relationship graph with the established merge strategy to sort and verify the conflicts in the relevant code version difference data, ensuring the merge order was reasonable and logical consistency was intact. Ultimately, they generated a detailed set of merge operation instructions, including the specific file merge order, conflict resolution suggestions, and code insertion points, for subsequent execution layer processing.

[0090] 105. Update the conflict status in the version relationship map according to the feedback data of the merge operation instruction set, and synchronously trigger the data update of the storage location and the reallocation of the version sequence identifier.

[0091] In this step, the feedback data is the result information after the merge operation is executed, such as a successful merge, a partial failure, or residual conflicts.

[0092] Updating the version relationship graph is to adjust the conflict status and dependency relationships based on feedback data.

[0093] The data update of the storage location is to write the merged code difference data into the new storage location.

[0094] The reallocation of version sequence identifiers is to generate a new unique identifier for the merged code to ensure the continuity of version management.

[0095] In an embodiment of the present application, after the merge operation is completed, the system receives feedback data from the execution layer, such as whether the merge is successful, whether the conflict is completely resolved, and other information. Based on this feedback, the system dynamically updates the conflict status in the version relationship map and marks it as "resolved." At the same time, in order to prevent version confusion, the system reallocates a new version sequence identifier to the merged new version and synchronously updates its storage path in the storage system. The entire process forms a closed-loop management to ensure that each merge can be accurately recorded and tracked, while providing the latest version reference for the next round of development.

[0096] After the merge is completed, the system receives execution feedback, confirms that the conflict has been correctly handled, and dynamically updates the conflict status in the version relationship map. At the same time, it reallocates a new version sequence identifier to the merged new version and synchronously updates its storage location in the storage system, completing the closed-loop management of the software development project of the intelligent transportation system.

[0097] In summary, steps 101 to 105 effectively address code conflicts during multi-version parallel development by acquiring and classifying code version difference data, constructing a version relationship graph, intelligently matching merge strategies, automatically generating merge instructions, and dynamically updating version information. Furthermore, by introducing version sequence identifiers and cloud-based collaboration mechanisms, efficient management and traceability of version data are achieved, comprehensively improving collaborative efficiency and code quality in cloud-based software development.

[0098] To address the difficulty of automatically handling code conflicts in multi-version parallel development, this solution extracts logical dependencies such as interface parameter types, return value formats, and call sequences from the version relationship graph, sorts the conflicting content based on the priority rules in the multi-version merge strategy, and verifies and filters based on the logical dependencies, converting the executable parts into operation instructions, ultimately forming a merge operation instruction set with a clear structure and orderly execution. In some embodiments, step 104, based on the conflict status of the version relationship graph and the multi-version merge strategy, sorts the conflicting content in the code version difference data and verifies the logical dependencies to generate a merge operation instruction set, including:

[0099] 201. Extracting a logical dependency relationship associated with the conflict state from the version relationship graph, wherein the logical dependency relationship includes interface parameter type requirements, return value format rules, and call sequence requirements;

[0100] In step 201, logical dependencies refer to the semantically-level dependency structure formed between two or more versions due to function calls, interface references, or data interactions. These include interface parameter type requirements, return value formatting rules, and call order requirements. These rules are used to determine whether code changes will affect the normal operation of other modules. The version relationship graph is a visual structural model constructed based on the call records between each version branch, reflecting the direction of data flow and the strength of logical dependencies between versions.

[0101] In this embodiment of the application, the system extracts the logical dependencies between major and minor versions by parsing the nodes and edges in the version relationship graph. For example, during the development of a smart transportation system, the traffic light control module and the traffic flow prediction module have an interface call relationship. The system will identify the parameter types, return value formats, and call order required by the interface, and use this information as the basic input for subsequent verification to ensure that the subsequent merging process does not destroy the original logical structure.

[0102] 202. Sort the conflicting contents in the code version difference data based on the conflict handling priority rules defined in the multi-version merge strategy to generate a conflicting content sequence;

[0103] In step 202, the conflict handling priority rules are a set of pre-defined conditions used to determine which conflicts should be handled first. These typically include factors such as the time of revision submission, the submitter's permissions, and the importance of the associated modules. These rules guide the system in how to prioritize the handling of conflicting content. The conflict content sequence is the resulting list generated by sorting the conflicting content according to the conflict handling priority rules.

[0104] In an embodiment of the present application, the system extracts the attributes of each conflicting content from the code version difference data, including the conflict type, version identifier, and submitter identity information, and constructs a set of conflicting content attributes. Subsequently, based on the conflict handling priority rules, the system first performs an initial classification by version submission time, and then calculates the sorting weight in combination with the submitter's authority. A multi-objective optimization algorithm is used to sort the conflicting content to ensure that high-priority conflicts can be handled in a timely manner and improve merging efficiency. The system extracts the basic attributes of the conflicting content, and then forms an ordered sequence of conflicting content based on the sorting results of the priority rules to facilitate subsequent processing.

[0105] 203. Perform parameter type matching verification and call sequence consistency verification on each conflicting content identifier in the conflicting content sequence according to the interface parameter type requirements and call sequence requirements in the logical dependency relationship, and mark the conflicting content identifier that fails the verification as a conflict to be processed item;

[0106] In step 203, parameter type matching verification checks whether parameter types for the same interface are consistent across different versions. Call sequence consistency verification confirms whether the inter-module call flow conforms to the expected logic. These two verifications are used to filter content that can be safely merged. Conflicting items are identified during the verification process as conflicting content that does not meet logical dependency requirements and requires further manual processing or adjustment.

[0107] In an embodiment of the present application, the system verifies each item according to the sequence of conflicting contents. For each conflicting content identifier, first compare whether its interface parameter types are consistent. If they are inconsistent, it is marked as a conflict pending item; secondly, check whether the calling sequence is as expected. If it is found that the calling sequence is disordered and may affect the function operation, it is also marked as a conflict pending item. This process uses a pattern matching algorithm to verify the interface parameter type and calling sequence to ensure that only conflicting contents that meet the logical dependency relationship can proceed to the next step. The system performs parameter type matching and calling sequence verification on each conflicting content in turn to ensure the security and correctness of the merge.

[0108] 204. Convert the verified conflicting content identifiers in the conflicting content sequence into executable operation instructions, generate prompt information for the conflicting items to be processed, and combine the executable operation instructions and the prompt information in an execution order to generate a merged operation instruction set.

[0109] In step 204, executable instructions refer to descriptions of code merge actions that can be directly executed by the system. Prompt information provides operational suggestions or warnings for conflicts that cannot be automatically resolved. The merge instruction set consists of a series of specific operational commands that guide the specific steps for subsequent code merges. The conflict content identifier uniquely identifies each conflicting content, facilitating tracking and resolution.

[0110] In an embodiment of the present application, the system uses a scripting language to convert the verified conflict content into specific executable operation instructions, such as "Insert the following code into line X of the specified file" or "Replace a certain function body". At the same time, natural language processing technology is used to generate prompt information with contextual information for the conflicting items to be processed, such as "Please confirm whether this parameter type change affects the caller". Finally, the system combines all executable operation instructions and prompt information into a complete merged operation instruction set in the order of execution for subsequent execution layer calls or user reference.

[0111] Here's a specific example:

[0112] In a software development project for a smart transportation system, multiple development teams were responsible for upgrading the signal control logic and traffic flow prediction modules, respectively. Due to the multi-version parallel development model, conflicts arose when the two branches were submitted to the mainline due to inconsistent interface parameter types. The system first extracted the logical dependencies between the two modules from the version relationship graph, identifying constraints such as interface parameter types, return value formats, and call order. Then, based on the conflict resolution priority rules in the multi-version merge strategy, the conflicting content of the two versions was sorted, prioritizing changes to the traffic flow prediction module. The system then verified parameter type matching and call order consistency, discovering that the parameter types of the signal light module had not been updated, resulting in incompatibility. The system then marked this content as a pending conflict. Finally, the system converted the verified conflicting content into executable instructions, generated prompts for the pending conflict, and output a complete set of merge instructions for developers to reference or for automatic execution. This entire process enables structured analysis and intelligent processing of complex conflicts, improving merge efficiency and accuracy.

[0113] In summary, steps 201 to 204 achieve structured sorting and automated verification of code conflict content by deeply utilizing the logical dependencies in the version relationship graph, combining conflict handling priority rules with a multi-dimensional verification mechanism, and generating an executable merge operation instruction set. This significantly improves the efficiency and security of code merging in multi-version parallel development scenarios, reduces the risks brought by human intervention, and enhances the intelligence level of software development collaboration in cloud environments.

[0114] To further improve the intelligent sorting capabilities of the code merge process, the solution collects and classifies the conflict type, version identifier, and submitter information of the conflicting content, and calculates the sorting weight based on the two dimensions of version submission time and submitter permissions. This achieves scientific sorting of the conflicting content, provides a reasonable execution order for subsequent merge operations, and improves the controllability and automation level of the merge process. In some embodiments, the conflicting content in the code version difference data is sorted based on the conflict handling priority rules defined in the multi-version merge strategy in step 202 to generate a conflict content sequence, including:

[0115] 301. Extract the conflict type, associated version sequence identifier, and submitter identifier corresponding to each conflict content in the code version difference data, and generate a conflict content attribute set;

[0116] In step 301, the conflict type refers to the specific form of code conflict between different versions, including function modification conflicts, variable renaming conflicts, or interface parameter change conflicts. The associated version sequence identifier is an identity tag used to uniquely identify the code branch or version that caused the conflict. The submitter identifier is used to uniquely identify the identity information of the developer or team that submitted the code version. The conflict content attribute set is a structured data set consisting of the conflict type, the associated version sequence identifier, and the submitter identifier, which is used to record the basic attribute information of each conflict content.

[0117] In an embodiment of the present application, the system extracts code segments of all conflicting contents from the code version difference data through static analysis and version comparison technology, and collects the corresponding conflict type, version sequence identifier of the version to which it belongs, and identity identification information of the submitter for the conflicting content in each code segment to form conflict content attributes, providing input basis for subsequent classification and sorting.

[0118] 302. Performing a preliminary classification of the conflicting content in the conflicting content attribute set according to the conflict handling priority rule defined in the multi-version merge strategy to generate a conflicting content classification set;

[0119] In step 302, the conflict handling priority rule is a set of preset conditions that guide how to determine the order of handling conflicting content. The conflicting content classification set is a result set obtained by preliminarily grouping the conflicting content according to some conditions in the conflict handling priority rule.

[0120] In an embodiment of the present application, the system performs an initial classification of the content in the conflict content attribute set based on the conditions set in the conflict handling priority rules, such as the severity of the conflict type, the importance of the version branch, etc. For example, function-level conflicts involving core functional modules are classified as high-priority categories, while conflicts involving only annotations or format adjustments are classified as low-priority categories. This step uses a rule-based classification algorithm to identify and group each conflict content according to preset rules, and generate a conflict content classification set as the basis for the next step of sorting.

[0121] 303. Based on the version submission time condition and the submitter authority condition in the conflict handling priority rule, calculate the sorting weight value of the conflicting content in the conflicting content classification set, and sort the conflicting content in the conflicting content classification set according to the sorting weight value to generate a conflicting content sequence.

[0122] In step 303, the version submission time condition refers to the order of submission time of the versions to which the conflicting content belongs, the submitter authority condition refers to the authority level of the developer who submitted the conflicting content, and the sorting weight value is a value calculated after comprehensively considering the version submission time and the submitter authority, and is used to measure the relative priority of how the conflicting content should be processed.

[0123] In an embodiment of the present application, the system obtains the submission time of the version to which each conflicting content belongs from the version management system, and assigns corresponding initial weight values ​​in combination with the role authority level of the submitter. For example, versions submitted earlier receive a higher basic weight, while content submitted by core developers receives additional points. Subsequently, the system uses a weighted scoring algorithm to merge the weights of these two dimensions to obtain the final ranking weight value of each conflicting content. After completing the weight calculation of all conflicting content, the system uses a sorting algorithm to arrange the conflicting content from high to low according to the weight value to generate a conflicting content sequence.

[0124] Here's a specific example:

[0125] In a software development project for an intelligent transportation system, multiple development teams were responsible for upgrading the signal light control logic and traffic flow prediction modules, respectively. Due to the multi-version parallel development model, the two teams made code modifications on their respective branches, resulting in multiple conflicts during the merge. The system first extracted these conflicts, identified their conflict type, version, and submitter identity, and constructed a set of conflicting content attributes. Next, based on the type classification criteria in the conflict handling priority rules, conflicts affecting interface calls were classified as high priority, while formatting modifications were classified as low priority. The system then calculated a ranking weight for each conflicting content, taking into account the version submission time and submitter permissions, ultimately generating an ordered sequence of conflicting content. This sequence was used to guide the generation of subsequent merge operation instructions, enabling intelligent sorting and efficient processing of complex conflicting content.

[0126] In summary, steps 301 to 303 achieve structured sorting of code conflicts during multi-version parallel development by extracting conflicting content attributes, performing initial classification, and calculating sorting weights. This approach not only improves the rationality of conflict resolution order but also enhances the system's understanding of the development context. This improves the automation and efficiency of code merging, reduces the uncertainty associated with manual intervention, and optimizes the overall collaborative development experience in a cloud environment.

[0127] To address the difficulty in structurally expressing the calling relationships between versions during multi-version parallel development, the solution analyzes the call records between each version branch, identifies the direction of data flow, and annotates the logical dependencies in combination with interface constraints. Ultimately, the interaction structure between versions is presented in the form of a graph, providing semantic support for conflict detection and merge strategy matching, and enhancing the system's ability to understand code dependencies. In some embodiments, step 102 constructs a version relationship graph reflecting the data flow direction and logical dependencies between versions based on the calling relationships between each version branch in the code version difference data, including:

[0128] 401. Extract call records between each version branch from the code version difference data, wherein the call record includes a calling version identifier, a called version identifier, and a call operation type;

[0129] In step 401, the call record is the historical information about function calls, interface references, or module imports between two versions. The calling version ID is the identity tag of the code version that initiated the call operation. The called version ID is the identity tag of the code version to which the called module belongs. The call operation type describes the specific nature of the call operation, such as function call, interface reference, or data access.

[0130] In an embodiment of the present application, the system first parses the source code structure of each version, and identifies the statements involving external version calls through static code analysis technology and version change comparison mechanism; then, combined with the version submission history, it determines whether the calling behavior exists in the current version, and extracts the calling version identifier, the called version identifier and the calling operation type to generate a complete call record as the basic input for the subsequent construction of the data flow link.

[0131] 402. Determine a data flow direction between the calling version identifier and the called version identifier based on the calling operation type in the calling record, and establish a data flow link from the called version identifier to the calling version identifier based on the data flow direction.

[0132] In step 402, the data flow direction refers to the direction in which data flows from one version to another during code execution, typically determined by the calling relationship. A data flow link is a structured description of the data transmission path between versions, reflecting the information exchange between the calling and called versions.

[0133] In an embodiment of the present application, the system determines the direction of data flow based on the call operation type in the call record. For example, in a function call scenario, if the calling version calls the function of the called version, data flows from the called version to the calling version. Based on this, the system establishes a data flow link from the called version identifier to the calling version identifier. This process uses graph structure modeling technology to convert each call record into a directed edge and attach a direction attribute, ultimately generating multiple data flow links for subsequent annotation of logical dependencies.

[0134] 403. Based on the interface constraint in the called version identifier, mark the corresponding logical dependency on the data flow link;

[0135] In step 403, interface constraints refer to restrictive rules such as interface parameter types, return value formats, and call order defined in the called version. Logical dependencies refer to the semantic dependency structure formed by interface calls between two versions, which affects compatibility judgment during code merging.

[0136] In an embodiment of the present application, on each data flow link, the system analyzes whether it complies with the interface constraints defined by the called version based on the actual usage of the interface by the calling version. If there is a specific type of dependency, such as parameter type dependency or call order dependency, the corresponding logical dependency is marked on the data flow link. This process uses syntax tree parsing and interface contract verification technology to compare the call expression and interface declaration in the source code, identify the specific logical dependency, and attach it to the corresponding data flow link, thereby enhancing the semantic expression ability of the call relationship between versions and providing a basis for subsequent conflict detection.

[0137] 404. Combine the data flow link and the logical dependency relationship according to the version identifier to form a version relationship graph with the version identifier as a node and the data flow link and the logical dependency relationship as a connection relationship.

[0138] In step 404, the version relationship graph is a visual structural model with version identifiers as nodes and data flow links and logical dependencies as connection relationships, reflecting the data flow direction and logical dependency strength between versions.

[0139] In the embodiment of the present application, the system first treats all version identifiers as nodes in a graph, where each node represents an independent code version. Next, the system uses the previously generated data flow links as directional edges to connect the corresponding calling version nodes and called version nodes. At the same time, the system converts the logical dependencies marked on the data flow links into attribute labels on the edges to express the interface dependency types between different versions. Finally, the system integrates all nodes and attributed edges through graph database technology to construct a complete version relationship graph.

[0140] Here's a specific example:

[0141] In the software development project for a smart transportation system, multiple development teams were responsible for upgrading the signal light control module and the traffic flow prediction module, respectively. Due to the multi-version parallel development model, interface call relationships existed between the two versions. The system first extracted call records from the code version difference data, identified function call behavior between the calling and called versions, and determined the call operation type. The system then determined the data flow direction based on the call type and established a data flow link from the called version to the calling version. Finally, the system integrated all data flow links with logical dependencies to construct a version relationship graph with version identifiers as nodes and links and dependencies as edges.

[0142] In summary, steps 401 to 404 achieve a visual representation of the dependencies between multiple versions of code by structurally extracting and modeling the logical dependencies between versions. This approach improves the system's understanding of the data flow and semantic dependencies between versions, enhances the intelligence of conflict detection and merge decisions, and significantly improves the efficiency of collaborative development and code management in parallel multi-version development in cloud environments.

[0143] To further improve the decision-making rationality and automation level of code conflict handling, the solution analyzes the logical dependencies between the primary and secondary versions, identifies the constraints affected by the conflict, and calculates the conflict impact value. It then selects an appropriate merge strategy from the strategy library, dynamically associates strategy selection with conflict severity, and enhances the intelligence level of merge decisions. In some embodiments, step 103, based on the conflict status and correlation strength of the logical dependencies in the version relationship graph, matches a multi-version merge strategy adapted to multi-version software development from a preset strategy library, including:

[0144] 501. Determine the conflicting major version identifier and minor version identifier according to the conflict status marked in the version relationship map, where the major version identifier is the version corresponding to the current main development path;

[0145] In step 501, a conflicting state indicates that different versions have made conflicting changes to the same code, making it impossible to merge directly. The major version ID is the version identity label corresponding to the current main development path, typically representing a core branch or stable branch. The minor version ID is the identity label of other versions that conflict with the major version.

[0146] In an embodiment of the present application, the system first scans all nodes and edges in the version relationship graph through a graph traversal algorithm, identifies a set of version nodes in a conflicting state, and uses an algorithm based on a branch weight evaluation model to determine which version node should be identified as the primary version. A weight score is assigned to each version based on its stability, importance, and influence in the project development process, and the one with the highest weight is used as the primary version identifier. The remaining versions that conflict with the primary version are classified as secondary version identifiers. This process not only takes into account the topological structure between versions, but also introduces historical submission behavior analysis to ensure the accuracy of the primary and secondary divisions, providing a reliable basic input for subsequent conflict impact assessments.

[0147] 502. Extract the logical dependency relationship between the major version identifier and the minor version identifier, identify the constraint set affected by the conflict from the logical dependency relationship, and calculate the conflict impact value based on the number of constraints in the constraint set and a preset weight value;

[0148] In step 502, a logical dependency refers to the semantic dependency structure between two versions due to function calls, interface references, or data interactions. A constraint set, consisting of multiple interface parameter type requirements, return value format rules, and call sequence requirements, describes the specific restrictions within a logical dependency. The conflict impact value is a numerical indicator that measures the severity of the conflict and is determined by the number of constraints and their corresponding preset weights.

[0149] In an embodiment of the present application, the system uses a subgraph matching algorithm to extract all logical dependencies between the major version identifier and the minor version identifier from the version relationship graph. Then, the syntax tree comparison technology is used to analyze the interface definition information in these logical dependencies one by one to identify which interface constraints are affected by the conflicting content. For example, if the parameter type, return value format or call order of an interface is inconsistent in the two versions, it will be included in the constraint set. Subsequently, the system assigns a corresponding weight value to each constraint based on a pre-set constraint weight table. The weight value is dynamically adjusted according to the importance of the interface in the system, the frequency of use and the scope of change impact. Finally, the system calculates the conflict impact value by weighted summation.

[0150] 503. Select a merge strategy from a preset strategy library whose applicable conflict type matches the conflict status and whose priority value is positively correlated with the conflict impact value, and associate the merge strategy, major version identifier, and minor version identifier to generate a multi-version merge strategy.

[0151] In step 503, the preset policy library is a repository of various merge policies, each corresponding to a specific conflict type and priority value. A merge policy is a set of rules that guides the system on how to handle different types of code conflicts. The priority value indicates the severity of the conflict for which a merge policy applies.

[0152] In an embodiment of the present application, the system uses a rule matching algorithm and a similarity sorting mechanism to search for a merge strategy that matches the current conflict type from a preset strategy library. First, the system performs pattern matching on the conflict type in the conflict state with the strategy type in the strategy library to screen out a set of candidate strategies. Then, based on the calculated conflict impact value, a linear interpolation method is used to map the conflict impact value to the priority value interval in the strategy library to find the most suitable strategy. Finally, the system binds the selected merge strategy to the major version identifier and the minor version identifier by constructing a mapping relationship table to generate a complete multi-version merge strategy.

[0153] Here's a specific example:

[0154] In a software development project for an intelligent transportation system, multiple development teams were responsible for upgrading the signal light control module and the traffic flow prediction module, respectively. Due to the use of a multi-version parallel development model, conflicts arose between the two versions regarding interface parameter definitions. The system first identified conflicting states from the version relationship graph using a graph traversal algorithm. Combining version submission time, branch hierarchy, and data flow direction, the system employed a branch weight evaluation model to determine the primary version as the current trunk branch and the secondary version as the feature branch. Next, the system employed a rule matching algorithm and priority mapping mechanism to select an appropriate merge strategy from a preset strategy library. Finally, the system associated this strategy with the primary and secondary version identifiers to generate a complete multi-version merge strategy. This entire process enabled intelligent identification and strategy matching of complex conflicts, improving merge efficiency and quality.

[0155] In summary, steps 501 to 503 implement intelligent strategy matching for multi-version code conflicts by classifying conflicting states in the version relationship graph into major and minor versions, combining constraint identification and conflict impact calculation within logical dependencies, and integrating rule matching with priority mapping mechanisms. This approach not only improves the automation of the merge process but also enhances the system's understanding of the semantic dependencies between versions, effectively reducing the uncertainty introduced by manual intervention and significantly optimizing the collaborative efficiency and code stability of multi-version parallel development in cloud environments.

[0156] To further improve the explainability and operability of conflict points in logical dependencies, the solution determines the constraint validation link based on the interaction behavior records and interface constraint declarations between the major version and the minor version, and thereby identifies the specific constraint conditions that violate the logical dependency, generating a complete constraint set, and providing key input for conflict impact assessment and policy matching. In some embodiments, extracting the logical dependency relationship between the major version identifier and the minor version identifier in step 502 and identifying the constraint set affected by the conflict from the logical dependency relationship includes:

[0157] 601. Extract the logical dependency relationship between the major version identifier and the minor version identifier from the version relationship graph, and determine the interactive operation record and interface constraint declaration between the versions based on the logical dependency relationship;

[0158] In step 601, the logical dependency relationship refers to the semantic dependency structure formed between two versions due to function calls, interface references, or data interactions. The interaction operation record describes the specific call behavior between the calling version and the called version. The interface constraint declaration refers to the restrictive rules defined in the called version, such as interface parameter types, return value formats, and call order.

[0159] In this embodiment of the application, the system uses a subgraph matching algorithm to locate all logical dependencies between major and minor version identifiers from the version relationship graph and extract the actual call paths involved. The system then uses graph traversal technology to traverse these paths and obtain the corresponding interaction operation records, including the calling method name, parameter passing method, and interface usage mode. At the same time, the system also extracts interface constraint declarations from the code metadata to form a complete interface specification list.

[0160] 602. Analyze the interaction behavior direction in the logical dependency relationship according to the interaction type of the interaction operation record, and generate a constraint validation link;

[0161] In step 602, the interaction type refers to the specific form of call behavior between different versions, such as function calls, asynchronous callbacks, or event monitoring. The interaction direction represents the flow of data between the caller and the callee during code execution. The constraint enforcement link is a path model constructed based on the interaction direction, representing the path by which interface constraints are propagated and enforced between versions.

[0162] In an embodiment of the present application, the system first classifies the interactive operation records obtained in the previous step according to the interaction type, and distinguishes different types of call behaviors such as synchronous calls and asynchronous calls. Then, the system determines the directionality of each call behavior based on call stack analysis technology and data flow tracking algorithm, that is, whether the data flows from the main version to the secondary version or vice versa. On this basis, the system constructs a constraint effectiveness link, models the propagation of interface constraints along the call path, and clarifies which versions of modifications will directly affect the establishment of interface constraints. This process ensures that the system can accurately understand the propagation path of interface constraints in the entire call chain, providing a basis for the next step of conflict identification.

[0163] 603. Based on the constraint validation link and the interface constraint declaration, identify the constraint conditions between the major version identifier and the minor version identifier that violate the logical dependency relationship, and generate a constraint condition set.

[0164] In step 603, the constraint condition set is a set consisting of multiple interface parameter type requirements, return value format rules and call sequence requirements, which is used to describe the interface restriction conditions that are violated in the logical dependency relationship.

[0165] In an embodiment of the present application, the system compares the constraint effectiveness link constructed in the previous step with the interface constraint declaration item by item, and uses syntax tree difference analysis technology to detect whether there are inconsistencies. For example, if the parameter type of a certain interface in the main version is integer, and the secondary version changes it to floating point, then the item is included in the constraint condition set; similarly, if the call order changes, resulting in a break in the dependency chain, it will also be identified as a violation. The entire identification process integrates structured comparison algorithms and semantic parsing technology to ensure that all constraints affected by the conflict can be accurately captured, and ultimately generate a constraint condition set with a clear structure and complete content, providing key input for subsequent conflict impact assessment and policy matching.

[0166] Here's a specific example:

[0167] In a software development project for a smart transportation system, multiple development teams were responsible for upgrading the signal light control module and the traffic flow prediction module, respectively. Due to the multi-version parallel development model, the two teams made code modifications on their respective branches. During the merging process, they discovered inconsistent interface parameter types. The system first used a subgraph matching algorithm to extract the logical dependencies between the two versions from the version relationship graph, identifying the call paths and interface usage records. Next, the system analyzed the direction of interaction behavior, constructed constraint validation links, and clarified the propagation of interface constraints along the call paths. The system then compared the interface declarations with actual calls and discovered that the signal light control module had changed the parameter type of an interface in the secondary version, violating the original logical dependency. This anomaly was added to the constraint set. This entire process accurately identified the scope of the conflict, improving the accuracy and rationality of merging strategy selection.

[0168] In summary, steps 601 to 603 achieve precise identification of conflicting constraints by deeply exploring the logical dependencies between the primary and secondary versions, combined with interaction behavior direction analysis and interface declaration comparison. This approach not only improves the system's understanding of the dependency structure between versions but also provides a structured decision-making basis for subsequent conflict impact assessment and merge strategy matching. This significantly enhances automated conflict resolution in a multi-version parallel development environment, reduces manual intervention costs, and ensures code quality and system stability.

[0169] To further improve the automation of graph state synchronization and new version generation after version merging, the solution parses the merge feedback data, extracts the modified content and conflict handling status, updates the conflict markers and data flow in the version relationship graph, assigns a unique identifier to the newly generated version, and synchronizes the storage location binding to ensure the consistency and traceability of version information, thereby improving the entire version lifecycle management process. In some embodiments, step 105 updates the conflict status in the version relationship graph based on the feedback data of the merge operation instruction set, and synchronously triggers the data update of the storage location and the reallocation of the version sequence identifier, including:

[0170] 701. Parse the feedback data of the merge operation instruction set, extract the modification content identifier, conflict handling status, and conflict content identifier recorded in the feedback data, extract the modification content corresponding to the modification content identifier from the code version difference data, and store the modification content in the storage location;

[0171] In step 701, the feedback data for the merge operation instruction set refers to the result information returned by the system after executing the code merge operation, including the modified content identifier, conflict resolution status, and conflict content identifier. The modified content identifier uniquely identifies the modified code segment or interface definition. The conflict resolution status indicates whether the conflict has been successfully resolved. The storage location is the physical or logical path used to save the code change results.

[0172] In the embodiment of the present application, the system first performs a structured analysis of the feedback data of the merge operation instruction set through log parsing technology, and extracts the modification content identifier, conflict handling status, and conflict content identifier recorded therein. Subsequently, the system retrieves the original change content corresponding to these modification content identifiers from the code version difference data, and writes these change contents to the specified storage location according to the preset format. This process uses a text difference analysis algorithm and a log structured processing mechanism to ensure that all completed modifications can be accurately implemented in persistent storage, providing data support for subsequent version identification updates.

[0173] 702. Update the data flow link between the major version sequence identifier and the minor version sequence identifier associated with the conflicting content identifier in the version relationship graph according to the conflict handling status, and generate a new version sequence identifier.

[0174] In step 702, the primary version sequence identifier is the identity tag of the version corresponding to the current primary development path. The secondary version sequence identifier is the identity tag of other versions that conflict with it. The data flow link is a structured description of the data transmission path between versions. The new version sequence identifier is the identity tag of the new version generated after the merge is completed.

[0175] In an embodiment of the present application, the system determines whether the conflict has been completely resolved based on the conflict handling status. If the status is "resolved", the system deletes the conflict mark between the original major version and the minor version in the version relationship graph through the graph update algorithm, and rebuilds the data flow link based on the merged code structure. At the same time, the system uses an incremental naming strategy to generate a new version sequence identifier, which is composed of the original major version identifier and a timestamp to ensure its uniqueness. The entire process integrates graph database transaction processing and version naming specification control technology to ensure that the generation of the new version identifier is completed synchronously with the graph status update, forming a unified version evolution path.

[0176] 703. Bind the new version sequence identifier to the storage location, and synchronously update the connection relationship and conflict status of the main version sequence identifier node in the version relationship graph.

[0177] In step 703, the new version sequence identifier is the identity tag of the new version generated after the merge is complete. The storage location is the physical or logical path used to save the code change results. The connection relationship refers to the edge structure between nodes in the version relationship graph, reflecting the call and dependency relationships between versions. The conflict status indicates whether there are unresolved code conflicts between different versions.

[0178] In this embodiment of the present application, the system establishes a mapping relationship between the new version sequence identifier and the storage location written in the previous step, and adds it as a new node in the version relationship graph. Subsequently, the system uses a graph reconstruction algorithm to update the connection relationship between the main version node and other related nodes, removes resolved conflict markers, and adds a new edge pointing to the new version node to reflect the connection relationship and conflict status of the latest main version sequence identifier node. This entire process is implemented based on the dynamic update mechanism of the graph database, ensuring that the graph state is consistent with the actual code version and improving the integrity of version management.

[0179] Here's a specific example:

[0180] In a software development project for an intelligent transportation system, multiple development teams were responsible for upgrading the signal light control module and the traffic flow prediction module, respectively. Due to the use of a multi-version parallel development model, the codes submitted by the two teams conflicted in interface parameter types. After the system performed a merge operation, it generated feedback data containing a modification content identifier, a conflict resolution status, and a conflict content identifier. The system first parsed the feedback data, extracted the modifications, and wrote them to the designated storage path. Next, based on the conflict resolution status, the system updated the data flow link in the version relationship graph and generated a new version sequence identifier. Finally, the system bound the new version identifier to the storage location, updated the connection relationship between the main version nodes in the graph, removed the conflict markers, and formed a complete version evolution path. The entire process achieved automatic updates of version status and real-time synchronization of the graph structure, improving the intelligent management level of multi-version collaborative development.

[0181] In summary, steps 701 to 703 achieve closed-loop updates and state consistency assurance for the version relationship graph after merging multiple versions of code by parsing and storing the merge operation feedback data, dynamically adjusting the data flow link and generating new version identifiers, and synchronously maintaining the graph connection relationships and conflict states. This approach not only improves the traceability and visualization of the version evolution process, but also enhances the automation and stability of the version management system in the cloud environment, significantly optimizing collaboration efficiency and code quality in multi-version parallel development scenarios.

[0182] Figure 2 A schematic diagram of a software development data management system based on cloud services is provided for the embodiment of the present application. Figure 2 As shown, the system includes:

[0183] An acquisition module 21 acquires code version difference data generated during the multi-version software development process in a cloud service environment, and allocates the code version difference data to a storage location corresponding to the version sequence identifier according to the version sequence identifier;

[0184] A construction module 22 constructs a version relationship graph reflecting the data flow direction and logical dependency relationship between versions based on the calling relationship between the version branches in the code version difference data;

[0185] A matching module 23 matches a multi-version merging strategy adapted to multi-version software development from a preset strategy library based on the conflict status and correlation strength of the logical dependency relationships in the version relationship graph;

[0186] When concurrent modification requests are detected for code with the same version sequence identifier, the generation module 24 sorts the conflicting contents in the code version difference data and performs logical dependency verification based on the conflict status of the version relationship graph and the multi-version merge strategy, and generates a merge operation instruction set.

[0187] The updating module 25 updates the conflict status in the version relationship map according to the feedback data of the merge operation instruction set, and synchronously triggers the data update of the storage location and the reallocation of the version sequence identifier.

[0188] Figure 2 The software development data management system based on cloud service can execute Figure 1 The implementation principles and technical effects of the cloud-based software development data management method described in the illustrated embodiment are not further elaborated. The specific manner in which each module and unit performs operations in the cloud-based software development data management system in the above embodiment has been described in detail in the embodiments of the method and will not be elaborated on here.

[0189] In one possible design, Figure 2 A cloud service-based software development data management system according to the embodiment shown can be implemented as a computing device, such as Figure 3 As shown, the computing device may include a storage component 31 and a processing component 32;

[0190] The storage component 31 stores one or more computer instructions, wherein the one or more computer instructions are called and executed by the processing component 32 .

[0191] The processing component 32 is used for the above Figure 1 The embodiment provides a software development data management method based on cloud services.

[0192] The processing component 32 may include one or more processors to execute computer instructions to perform all or part of the steps in the above method. Of course, the processing component may also be implemented as one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the above method.

[0193] The storage component 31 is configured to store various types of data to support operations at the terminal. The storage component can be implemented by any type of volatile or non-volatile memory device, or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk, or optical disk.

[0194] Of course, a computing device may also include other components, such as input / output interfaces, display components, communication components, etc.

[0195] The input / output interface provides an interface between the processing component and the peripheral interface module, which can be an output device, an input device, etc.

[0196] The communication component is configured to facilitate, among other things, wired or wireless communications between the computing device and other devices.

[0197] Among them, the computing device can be a physical device or an elastic computing host provided by a cloud computing platform, etc. In this case, the computing device can refer to a cloud server, and the above-mentioned processing components, storage components, etc. can be basic server resources rented or purchased from the cloud computing platform.

[0198] The present application also provides a computer storage medium storing a computer program, wherein the computer program can achieve the above-mentioned Figure 1 The illustrated embodiment provides a software development data management method based on cloud services.

[0199] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0200] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, i.e., they may be located in one location or distributed across multiple network units. Some or all of the modules may be selected based on actual needs to achieve the objectives of the present embodiment. Persons of ordinary skill in the art will be able to understand and implement the present invention without inventive effort.

[0201] Through the description of the above embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus a necessary general hardware platform, or of course, by hardware. Based on this understanding, the essence of the above technical solution or the part that contributes to the existing technology can be embodied in the form of a software product. The computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, a magnetic disk, an optical disk, etc., and includes a number of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in each embodiment or certain parts of the embodiments.

[0202] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A software development data management method based on cloud services, characterized in that: include: Obtain code version difference data generated during the multi-version software development process in the cloud service environment, and allocate the code version difference data to a storage location corresponding to the version sequence identifier according to the version sequence identifier; Based on the calling relationship between the version branches in the code version difference data, a version relationship graph is constructed to reflect the data flow direction and logical dependency relationship between the versions; According to the conflict status and correlation strength of the logical dependency relationships in the version relationship graph, a multi-version merging strategy adapted to multi-version software development is matched from a preset strategy library; When concurrent modification requests are detected for code with the same version sequence identifier, based on the conflict status of the version relationship graph and the multi-version merge strategy, the conflicting contents in the code version difference data are sorted and logical dependencies are verified to generate a merge operation instruction set; According to the feedback data of the merge operation instruction set, the conflict status in the version relationship map is updated, and the data update of the storage location and the reallocation of the version sequence identifier are synchronously triggered.

2. The method according to claim 1, characterized in that The conflicting contents in the code version difference data are sorted and logically dependant verified based on the conflict status of the version relationship graph and the multi-version merge strategy, and a merge operation instruction set is generated, including: Extracting a logical dependency relationship associated with the conflict state from the version relationship graph, wherein the logical dependency relationship includes interface parameter type requirements, return value format rules, and call sequence requirements; Based on the conflict handling priority rules defined in the multi-version merge strategy, the conflicting contents in the code version difference data are sorted to generate a conflicting content sequence; According to the interface parameter type requirements and call sequence requirements in the logical dependency relationship, perform parameter type matching verification and call sequence consistency verification on each conflicting content identifier in the conflicting content sequence, and mark the conflicting content identifier that fails the verification as a conflict to be processed item; The verified conflict content identifiers in the conflict content sequence are converted into executable operation instructions, prompt information is generated for the conflicting items to be processed, and the executable operation instructions and the prompt information are combined in an execution order to generate a merged operation instruction set.

3. The method according to claim 2, characterized in that The step of sorting the conflicting contents in the code version difference data based on the conflict handling priority rules defined in the multi-version merge strategy to generate a conflicting content sequence includes: Extracting the conflict type, associated version sequence identifier, and submitter identifier corresponding to each conflict content in the code version difference data, and generating a conflict content attribute set; performing a preliminary classification of the conflicting contents in the conflicting content attribute set according to the conflict handling priority rule defined in the multi-version merge strategy to generate a conflicting content classification set; Based on the version submission time condition and the submitter authority condition in the conflict handling priority rule, the sorting weight value of the conflicting content in the conflicting content classification set is calculated, and the conflicting content in the conflicting content classification set is sorted according to the sorting weight value to generate a conflicting content sequence.

4. The method according to claim 1, wherein The step of constructing a version relationship graph reflecting the data flow direction and logical dependency relationship between versions based on the calling relationship between the version branches in the code version difference data includes: Extracting call records between each version branch from the code version difference data, wherein the call record includes a calling version identifier, a called version identifier, and a call operation type; Determine the data flow direction between the calling version identifier and the called version identifier according to the calling operation type in the calling record, and establish a data flow link from the called version identifier to the calling version identifier according to the data flow direction; Based on the interface constraint in the called version identifier, marking the corresponding logical dependency on the data flow link; The data flow link and the logical dependency relationship are combined according to the version identifier to form a version relationship graph with the version identifier as the node and the data flow link and the logical dependency relationship as the connection relationship.

5. The method according to claim 1, wherein The method of matching a multi-version merging strategy adapted to multi-version software development from a preset strategy library based on the conflict status and association strength of the logical dependency relationships in the version relationship graph includes: Determine the conflicting major version identifier and minor version identifier according to the conflict status marked in the version relationship map, where the major version identifier is the version corresponding to the current main development path; Extracting a logical dependency relationship between the major version identifier and the minor version identifier, identifying a set of constraints affected by the conflict from the logical dependency relationship, and calculating a conflict impact value based on the number of constraints in the constraint set and a preset weight value; A merge strategy whose applicable conflict type matches the conflict status and whose priority value is positively correlated with the conflict impact value is selected from a preset strategy library, and the merge strategy, major version identifier and minor version identifier are correspondingly associated to generate a multi-version merge strategy.

6. The method according to claim 5, characterized in that The extracting the logical dependency relationship between the major version identifier and the minor version identifier, and identifying the set of constraint conditions affected by the conflict from the logical dependency relationship, includes: Extracting the logical dependency relationship between the major version identifier and the minor version identifier from the version relationship graph, and determining the interactive operation record and interface constraint declaration between the versions based on the logical dependency relationship; Analyze the interaction behavior direction in the logical dependency relationship according to the interaction type of the interaction operation record, and generate a constraint validation link; Based on the constraint validation link and the interface constraint declaration, the constraint conditions between the major version identifier and the minor version identifier that violate the logical dependency relationship are identified, and a constraint condition set is generated.

7. The method according to claim 1, characterized in that The updating of the conflict status in the version relationship graph according to the feedback data of the merge operation instruction set, and synchronously triggering the data update of the storage location and the reallocation of the version sequence identifier, includes: Parsing feedback data of the merge operation instruction set, extracting the modification content identifier, conflict handling status, and conflict content identifier recorded in the feedback data, extracting the modification content corresponding to the modification content identifier from the code version difference data, and storing the modification content in the storage location; According to the conflict handling status, updating the data flow link between the major version sequence identifier and the minor version sequence identifier associated with the conflicting content identifier in the version relationship graph to generate a new version sequence identifier; The new version sequence identifier is bound to the storage location, and the connection relationship and conflict status of the main version sequence identifier node in the version relationship graph are synchronously updated.

8. A software development data management system based on cloud services, characterized in that: include: An acquisition module is configured to acquire code version difference data generated during the development of multiple versions of software in a cloud service environment, and to allocate the code version difference data to a storage location corresponding to the version sequence identifier according to the version sequence identifier; A construction module, based on the calling relationship between the version branches in the code version difference data, constructs a version relationship map reflecting the data flow direction and logical dependency relationship between the versions; A matching module, which matches a multi-version merging strategy adapted to multi-version software development from a preset strategy library based on the conflict status and association strength of the logical dependency relationships in the version relationship graph; a generation module that, upon detecting concurrent modification requests for code with the same version sequence identifier, sorts the conflicting contents in the code version difference data and performs logical dependency verification based on the conflict status of the version relationship graph and the multi-version merge strategy, and generates a merge operation instruction set; An update module updates the conflict status in the version relationship map according to feedback data of the merge operation instruction set, and synchronously triggers the data update of the storage location and the reallocation of the version sequence identifier.

9. A computing device, characterized in that It includes a processing component and a storage component; the storage component stores one or more computer instructions; the one or more computer instructions are used to be called and executed by the processing component to implement a cloud service-based software development data management method as described in any one of claims 1 to 7.

10. A computer storage medium, characterized in that A computer program is stored, and when the computer program is executed by a computer, the cloud service-based software development data management method according to any one of claims 1 to 7 is implemented.

Images