A cloud service-based software development data management method and system

Abstract

The application provides a cloud service-based software development data management method and system. In the application, code version difference data generated in a multi-version development process is obtained from a cloud service environment and distributed to a corresponding storage location according to a version sequence identifier. A version relationship graph is constructed based on a calling relationship between version branches, and a data flow direction and a logical dependency relationship between versions are dynamically recorded. Conflict content is sorted and logically dependent according to a conflict state and a merging strategy, and a traceable merging operation instruction set is generated. Finally, the instruction set is executed to update the graph conflict state, and the storage data is updated and the version identifier is re-distributed, so that the development data full-link closed-loop management is realized. The technical scheme provided by the application can improve the efficiency and accuracy of software development data management.

Description

TECHNICAL FIELD

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

[0002] In a cloud service supported multi-version parallel software development scenario, multiple development teams or individuals often develop function branches in the same project, resulting in frequent code merging and version interlacing. This application scenario requires the construction of an efficient data management method that can detect code conflicts between different versions in real time and implement dynamic merging without interrupting the development process. In addition, it also needs to support version tracking, change impact analysis and automatic merging suggestion generation in a cloud collaborative development environment to improve development efficiency and code quality and reduce the risk of errors caused by manual intervention.

[0003] To address the above technical needs, some existing development platforms based on cloud services have introduced a structured code difference analysis mechanism and combined with abstract syntax tree comparison technology to identify code conflicts. This scheme parses the code of different versions into a unified syntax structure representation form, automatically identifies the change of key elements such as functions, variables and control flow, and then judges whether there is a logical or structural conflict. At the same time, the system also integrates a lightweight merging strategy engine to provide preliminary merging suggestions when conflicts are detected, and feeds back the results to the developers for confirmation, forming a certain degree of automatic conflict processing process.

[0004] However, the existing scheme still has obvious limitations. First, it relies on static syntax comparison mechanism and cannot accurately identify semantic level conflicts such as logical order change or context dependency relationship destruction. Second, this method lacks understanding ability of development behavior context and cannot make intelligent merging decisions according to the purpose and intention of code changes, resulting in a large number of inefficient manual review still existing. In addition, in the face of large-scale concurrent development scenarios, the system response delay is high and the merging process stability is insufficient, which affects the overall collaboration efficiency. Therefore, there is an urgent need for a more intelligent, semantic understanding and efficient collaboration mechanism based on cloud service software development data management method to cope with the complex challenges brought by multi-version parallel development. SUMMARY

[0005] The present application provides a software development data management method and system based on cloud services to solve the problems of low efficiency and poor precision in 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] Obtaining code version difference data generated in a multi-version software development process in a cloud service environment, and distributing the code version difference data to a storage location corresponding to a version sequence identifier according to the version sequence identifier;

[0008] Based on the calling relationship between each version branch in the code version difference data, a version relationship graph reflecting the data flow direction and logical dependency relationship between each version is constructed;

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

[0010] When detecting a concurrent modification request for the same version sequence identifier, based on the conflict state of the version relationship graph and the multi-version merging strategy, the conflict content in the code version difference data is sorted and logically dependent, and a merging operation instruction set is generated;

[0011] According to the feedback data of the merging operation instruction set, the conflict state in the version relationship graph is updated, and the data update of the storage location and the reassignment of the version sequence identifier are triggered synchronously.

[0012] Optionally, based on the conflict state of the version relationship graph and the multi-version merging strategy, the conflict content in the code version difference data is sorted and logically dependent, and a merging operation instruction set is generated, comprising:

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

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

[0015] According to the interface parameter type requirements and the calling sequence requirements in the logical dependency relationship, the parameter type matching verification and the calling sequence consistency verification are performed on each conflict content identifier in the conflict content sequence, and the conflict content identifier that fails the verification is marked as a conflict to be handled item;

[0016] The conflict content identifier that passes the verification in the conflict content sequence is converted into an executable operation instruction, and prompt information is generated for the conflict to be handled item. The executable operation instruction and the prompt information are combined in execution order to generate a merging operation instruction set.

[0017] Optionally, the conflict content in the code version difference data is sorted based on the conflict processing priority rule defined in the multi-version merging strategy to generate a conflict content sequence, including:

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

[0019] The conflict content in the conflict content attribute set is initially classified based on the conflict processing priority rule defined in the multi-version merging strategy to generate a conflict content classification set;

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

[0021] Optionally, the version relationship graph reflecting the data flow direction and logical dependency relationship between versions is constructed based on the calling relationship between version branches in the code version difference data, including:

[0022] The calling record between version branches is extracted from the code version difference data, and the calling record contains the calling version identifier, the called version identifier, and the calling operation type;

[0023] The data flow direction between the calling version identifier and the called version identifier is determined according to the calling operation type in the calling record, and a data flow link pointing from the called version identifier to the calling version identifier is established according to the data flow direction;

[0024] Based on the interface constraint condition in the called version identifier, the corresponding logical dependency relationship is marked 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 a node and the data flow link and the logical dependency relationship as a connection relationship.

[0026] Optionally, the multi-version merging strategy adapted to multi-version software development is matched from a preset strategy library according to the conflict state and associated strength of the logical dependency relationship in the version relationship graph, including:

[0027] The main version identifier and the secondary version identifier of the conflict are determined according to the conflict state marked in the version relationship graph, and the main 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 constraint condition set affected by the conflict from the logical dependency relationship, calculating a conflict impact value based on a constraint condition quantity in the constraint condition set and a preset weight value;

[0029] selecting a merging strategy from a preset strategy library, which matches an applicable conflict type and the conflict state, and in which a priority value is positively correlated with the conflict impact value, and correspondingly associating the merging strategy, the major version identifier and the minor version identifier to generate a multi-version merging strategy.

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

[0031] extracting the logical dependency relationship between the major version identifier and the minor version identifier from a version relationship graph, and determining an interactive operation record and an interface constraint declaration between versions according to the logical dependency relationship;

[0032] analyzing an interaction behavior direction in the logical dependency relationship according to an interaction type of the interactive operation record to generate a constraint effective link;

[0033] identifying a constraint condition between the major version identifier and the minor version identifier that violates the logical dependency relationship based on the constraint effective link and the interface constraint declaration, and generating a constraint condition set.

[0034] Optionally, the updating the conflict state in the version relationship graph according to the feedback data of the merging operation instruction set, and synchronously triggering data update of the storage location and re-allocation of the version sequence identifier comprises:

[0035] parsing feedback data of the merging operation instruction set, extracting a modification content identifier, a conflict processing state and a conflict content identifier recorded in the feedback data, and extracting modification content corresponding to the modification content identifier from code version difference data, and storing the modification content in the storage location;

[0036] updating a data flow direction link between the major version sequence identifier and the minor version sequence identifier associated with the conflict content identifier in the version relationship graph according to the conflict processing state to generate a new version sequence identifier;

[0037] binding the new version sequence identifier to the storage location, and synchronously updating connection relationship and a conflict state of the major version sequence identifier node in the version relationship graph.

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

[0039] an acquisition module, configured to acquire code version difference data generated in a multi-version software development process in a cloud service environment, and distribute the code version difference data to a storage location corresponding to a version sequence identifier according to the version sequence identifier;

[0040] a construction module, configured to construct a version relationship graph reflecting data flow direction and logical dependency relationship among versions based on a calling relationship among version branches in the code version difference data;

[0041] a matching module, configured to match a multi-version merging strategy adapted to the multi-version software development from a preset strategy library according to a conflict state and an association strength of the logical dependency relationship in the version relationship graph;

[0042] a generation module, configured to, when detecting a concurrent modification request for the same version sequence identifier, sort and logically verify conflict content in the code version difference data based on a conflict state of the version relationship graph and the multi-version merging strategy, and generate a merging operation instruction set;

[0043] an update module, configured to update the conflict state in the version relationship graph according to feedback data of the merging operation instruction set, and synchronously trigger data update of the storage location and re-distribution of the version sequence identifier.

[0044] In a third aspect, an embodiment of the present application provides a computing device, including 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, and implement the software development data management method based on a cloud service in the first aspect.

[0045] In a fourth aspect, an embodiment of the present application provides a computer storage medium, which stores a computer program; when the computer program is executed by a computer, the software development data management method based on a cloud service in the first aspect is implemented.

[0046] In the embodiments of the present application, code version difference data generated in the development process of multi-version software in a cloud service environment is obtained, and the code version difference data is distributed to a storage location corresponding to a version sequence identifier according to the version sequence identifier. Based on the calling relationship between each version branch in the code version difference data, a version relationship graph reflecting the data flow direction and logical dependency relationship between each version is constructed. According to the conflict state and correlation strength of the logical dependency relationship in the version relationship graph, a multi-version merging strategy suitable for multi-version software development is matched from a preset strategy library. When a concurrent modification request for the code of the same version sequence identifier is detected, the conflict content in the code version difference data is sorted and logically dependent based on the conflict state of the version relationship graph and the multi-version merging strategy, and a merging operation instruction set is generated. According to the feedback data of the merging operation instruction set, the conflict state in the version relationship graph is updated, and the data update of the storage location and the re-distribution of the version sequence identifier are triggered synchronously.

[0047] The technical scheme of the present application has the following beneficial effects:

[0048] The present application provides accurate data sources for conflict detection and merging by realizing the structured storage and rapid positioning of multi-version difference data, avoiding the problem of low retrieval efficiency caused by data mixing. The dynamic mapping of data flow and logical dependency between versions traces the impact of code modification on the dependency chain in real time, providing visual decision basis for conflict analysis. Based on the conflict state and dependency strength, the adaptive strategy is intelligently selected to improve the strategy matching accuracy in complex conflict scenarios and reduce the cost of manual intervention. By sorting and logically verifying the conflict content, it is ensured that the merging operation conforms to the constraint relationship between versions, reducing the code logic errors caused by strategy misjudgment. A closed-loop feedback mechanism for conflict processing, graph updating and data synchronization is established to ensure the consistency of multi-version data and avoid the same conflict from occurring repeatedly.

[0049] Further, in the conflict processing stage, first, the logical dependency relationship related to the conflict is extracted from the version relationship graph, and the conflict content is sorted to generate a sequence based on the priority rules of the merging strategy. Then, the conflict items in the sequence are verified for compliance of parameter type and calling order, and the verification failed items are marked as to-be-processed items. Finally, the conflict items that pass the verification are converted into executable instructions, and prompt information is generated for the to-be-processed items, which are combined into an instruction set according to the execution order. Through dynamic priority sorting and logical dependency double verification, it is ensured that the merging operation strictly follows the constraint rules between versions, significantly reducing the runtime error risk of the merged code. At the same time, the conflict to-be-processed item prompt information provides accurate conflict positioning and repair suggestions for developers, improves the collaboration efficiency in complex conflict scenarios, and avoids system-level failures caused by missed verification.

[0050] These aspects or other aspects of the present application will be made clearer in the following description of embodiments. BRIEF DESCRIPTION OF DRAWINGS

[0051] In order to more clearly illustrate the technical solutions of the embodiments of the present application or the prior art, the following will briefly introduce the drawings needed to be used in the description of embodiments or prior art. Obviously, the drawings in the following description are some embodiments of the present application, and other drawings can also be obtained by those skilled in the art without creative labor on the basis of these drawings.

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

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

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

[0055] In order to make the person skilled in the art better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described in the following with reference to the drawings in the embodiments of the present application.

[0056] In some of the descriptions of the specification, claims and the above drawings, a plurality of operations appearing in a specific order, but it should be clear that these operations can not be executed in the order appearing in the text or in parallel, the serial numbers of the operations such as 101, 102, etc. are only used to distinguish different operations, and the serial numbers themselves do not represent any execution order. In addition, these processes can include more or less operations, and the operations can be executed in sequence or in parallel. It should be noted that the "first", "second" and the like in the text are used to distinguish different messages, devices, modules, etc., and do not represent the order of precedence, nor do "first" and "second" represent different types.

[0057] Current mainstream automatic merging tools based on static dependency analysis have significant limitations in the multi-version software development scenario under the cloud service environment. First, the static dependency graph cannot capture the dynamic logical dependency changes caused by multi-terminal concurrent modification in real time, leading to conflict detection lag or omission, making it difficult to meet the needs of real-time synchronization of high-concurrency modification requests and data in cloud services. Second, the strategy matching mechanism of the pre-defined rule library lacks adaptability to complex conflict scenarios, and the single priority of the strategy leads to an increase in the logical error rate of the merged code, and the strategy library cannot be dynamically optimized according to historical conflict handling experience. Finally, the merging operation and conflict state management in the existing solution are mutually separated, lacking a dynamic feedback mechanism for dependency graph and strategy library, resulting in repeated occurrence of the same type of conflict in the iteration process, significantly increasing the cost of manual troubleshooting and reducing collaboration efficiency.

[0058] To solve the above problems, the present application provides a software development data management method based on cloud services. This method breaks through by 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 state and associated strength of the version relationship graph, the merging strategy suitable for the multi-version development scenario is intelligently matched, replacing the rigid matching mechanism of the traditional single rule library. Third, when concurrent modification requests are detected, the conflict content is sorted and logically dependent based on the version relationship graph and merging strategy, generating a high-reliability merging operation instruction set. Finally, the version relationship graph and the data in the storage location are dynamically updated through feedback data, and the version sequence identifier is re-allocated, forming a closed-loop optimization mechanism. This solution effectively solves the key defects of static dependency analysis lag, insufficient strategy adaptability, and lack of conflict handling experience reuse, significantly improving the conflict detection accuracy and merging efficiency of multi-version parallel development under the cloud service environment.

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

[0060] Figure 1 A flowchart of a software development data management method based on cloud services is provided for the embodiments of the present application, as shown in Figure 1 The method comprises:

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

[0062] In this step, multi-version software development refers to a collaborative development mode of managing multiple function branches, repair branches and release versions in the software development process through a version control system.

[0063] The cloud service environment refers to a virtualized resource pool provided by cloud computing technology, which provides distributed environment for users to deliver computing power, storage capacity and network services on demand.

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

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

[0066] The storage location refers to a logical storage area divided according to the version identifier in the cloud service, which is used to isolate the storage of difference data of different versions.

[0067] In the embodiments of the present application, first, the application programming interface of the version control system is used to listen to the code submission event in real time, and the code version difference data of each branch in the multi-version software development process is collected, including the newly added, modified or deleted code segments and function call relationships. Then, the function call chain in the difference data is parsed using a static analysis tool to extract the call relationship between version branches. Next, 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 storage location corresponding to the version sequence identifier through a distributed storage system.

[0068] In a software development project of a smart traffic system, multiple development teams are responsible for upgrading different modules. For example, one team focuses on optimizing the signal light control logic, and another team is responsible for updating the traffic flow prediction model. Since the system uses a multi-version parallel development mode, the two teams modify the code on their respective branches and periodically 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, and stores the corresponding code version difference data in the specified path. For example, in one submission, the signal light control module adds an adaptive adjustment function, and the system identifies the modification content and stores it with the corresponding version sequence identifier, providing a data basis for subsequent analysis.

[0069] 102. constructing a version relationship graph reflecting data flow direction and logical dependency relationship between versions based on the calling relationship between each version branch in the code version difference data;

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

[0071] The data flow direction refers to the source and destination of data in the code execution process.

[0072] The logical dependency relationship refers to the constraint relationship between codes, including interface parameter matching, return value compatibility and call sequence restriction.

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

[0074] In the embodiments 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. Then, based on a graph database or in-memory graph structure, the calling 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 latest version dependency. Finally, the association strength between nodes is calculated in combination with a logical dependency analysis algorithm to mark potential conflict areas. In the entire process, difference data parsing provides the basis for graph construction, graph database supports dynamic updating, 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 relationship between versions in real time.

[0075] In the software development project of the intelligent transportation system, based on the code version difference data obtained above, the system parses the calling relationship between versions and finds that the traffic prediction module depends on some interface definitions in the signal light control module. Based on this, the system uses graph database technology to construct a version relationship graph, presents the dependency direction and strength between the two versions in a visual way, and forms a complete inter-version logical structure model.

[0076] 103. matching a multi-version merging strategy suitable for multi-version software development from a preset strategy library according to the conflict state and association strength of the logical dependency relationship in the version relationship graph;

[0077] In this step, the conflict state 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 association strength is the closeness of the dependency relationship between versions, which is usually quantified by calling frequency or data flow volume.

[0079] The preset policy library is a rule set for storing a plurality of merging policies, such as priority reservation of main branch code, automatic rollback of conflict version, and the like.

[0080] The multi-version merging policy is a solution developed for a specific conflict scenario and used to guide code merging operations.

[0081] In the embodiment of the present application, on the basis of the version relationship graph, the system analyzes the logical dependency relationship between versions, in particular, whether there is a conflict state and the high and low of the association strength. The conflict state is judged by comparing the modification contents of the same function or variable in the code, and the association strength is calculated by the number of shared modules and the interaction frequency. Subsequently, a merging policy matching the current conflict state and association strength is found from the preset policy library. These strategies may include priority reservation of high association degree version modification, adoption of a three-way merging mechanism, or manual confirmation intervention, and the like. Finally, a set of multi-version merging policies suitable for the current version combination is output, providing decision support for subsequent specific merging operations.

[0082] When the development team detects that both versions have modified the shared configuration parameters, the conflict state evaluation process is started. By analyzing the association strength and conflict type between the two versions, a merging policy suitable for the current situation is matched from the policy library, that is, the parameter setting of the prediction model side is preferentially reserved, and the corresponding adaptation suggestions are made to the control module.

[0083] 104、When detecting that there are concurrent modification requests for the code with the same version sequence identifier, based on the conflict state of the version relationship graph and the multi-version merging policy, the conflict content in the code version difference data is sorted and logically dependent, and a merging operation instruction set is generated;

[0084] In this step, the concurrent modification request is that multiple developers simultaneously propose modification requirements for the code with the same version sequence identifier.

[0085] The sorting is to arrange the conflict content according to the conflict priority and dependency relationship.

[0086] The logical dependency verification is to check whether the conflict content destroys the call chain or data flow between versions.

[0087] The merging operation instruction set is an operation guide containing specific merging steps and rules, for example, reserving the code of a version to cover the code of another version.

[0088] In the embodiments of the present application, when the system detects multiple concurrent modification requests for a certain version sequence identifier, a conflict detection process is immediately started. In combination with the conflict state in the version relationship graph and the matched multi-version merging strategy, the conflict content in the related code version difference data is sorted and logically dependent. The sorting basis includes modification time, version dependency weight and user specified priority; logical dependency verification ensures that the merged code will not damage the original call chain. After verification, the system generates a set of detailed merging operation instruction set, including file merging order, conflict resolution suggestion, code insertion point and other information, as a standard guide for actual execution of merging.

[0089] Based on the above scheme, the development team combines the conflict information in the version relationship graph and the determined merging strategy to sort and verify the conflict content in the related code version difference data, ensuring that the merging order is reasonable and the logical consistency is not damaged. Finally, a set of detailed merging operation instruction set is generated, including specific file merging order, conflict resolution suggestion and code insertion point information, for subsequent execution layer call processing.

[0090] 105、According to the feedback data of the merging operation instruction set, update the conflict state in the version relationship graph, and synchronously trigger the data update of the storage location and the reassignment of the version sequence identifier.

[0091] In this step, the feedback data is the result information after the merging operation is executed, such as merging success, partial failure or conflict residue.

[0092] Updating the version relationship graph is to adjust the conflict state and dependency relationship according to the feedback data.

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

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

[0095] In the embodiments of the present application, after the merging operation is executed, the system receives feedback data from the execution layer, such as whether the merging is successful, whether the conflict is completely resolved and other information. According to these feedbacks, the system dynamically updates the conflict state in the version relationship graph, which is marked as "solved". At the same time, in order to prevent version confusion, the system reassigns a new version sequence identifier for the merged new version, and synchronously updates its storage path in the storage system. The whole process forms a closed loop management, ensuring that each merging can be accurately recorded and tracked, and providing the latest version reference for the next round of development.

[0096] After the merging is completed, the system receives an execution feedback, confirms that the conflict has been correctly handled, dynamically updates the conflict state in the version relationship graph, reassigns a new version sequence identifier to the merged new version, synchronously updates the storage location of the new version in the storage system, and completes the closed-loop management of the software development project of the intelligent transportation system.

[0097] To sum up, steps 101 to 105 construct a version relationship graph by acquiring and classifying code version difference data, intelligently match merging strategies, automatically generate merging instructions, and realize dynamic updating of version information, effectively dealing with the code conflict problem in multi-version parallel development. At the same time, by introducing version sequence identifiers and cloud collaboration mechanisms, efficient management and traceability of version data are realized, and the collaboration efficiency and code quality of software development in the cloud environment are comprehensively improved.

[0098] To solve the problem of automatic processing of code conflicts in multi-version parallel development, the scheme extracts logical dependency relationships such as interface parameter types, return value formats, and calling sequences from the version relationship graph, combines priority rules in multi-version merging strategies to sort conflict content, and verifies and filters according to logical dependencies to convert executable parts into operation instructions, and finally forms a clear structure and ordered execution of merging operation instruction set. In some embodiments, the conflict content in the code version difference data is sorted and logically dependent according to the conflict state of the version relationship graph and the multi-version merging strategy in step 104, and the merging operation instruction set is generated, including:

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

[0100] In step 201, the logical dependency relationship refers to the semantic level dependency structure formed between two or more versions due to function calls, interface references, or data interactions, including interface parameter type requirements, return value format rules, and calling sequence 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 calling records between version branches, reflecting the data flow direction and logical dependency strength between versions.

[0101] In the embodiments of the present application, the system extracts the logical dependency relationship between the main version and the secondary version by analyzing the node and edge information in the version relationship graph. For example, in the development process of the intelligent transportation system, the signal light control module and the traffic prediction module have an interface calling relationship, the system will identify the required parameter types, return value formats, and calling sequences of the interface, and input these information as the basis for subsequent verification, to ensure that the subsequent merging process will not damage the original logical structure.

[0102] 202、based on the conflict handling priority rules defined in the multi-version merging strategy, sorting the conflict content in the code version difference data to generate a conflict content sequence;

[0103] In step 202, the conflict handling priority rules are a set of conditions preset for determining which conflicts should be handled first, usually including version submission time, submitter authority, associated module importance, and other factors. The rules are used to guide the system on how to arrange the processing order of the conflict content. The conflict content sequence is a result list generated after sorting the conflict content according to the conflict handling priority rules.

[0104] In the embodiments of the present application, the system extracts the attributes of each conflict content from the code version difference data, including conflict type, version identifier, and submitter identity information, to construct a conflict content attribute set. Then, according to the conflict handling priority rules, the conflict content is first classified by version submission time, and then the sorting weight is calculated in combination with the submitter authority, and a multi-objective optimization algorithm is used to sort the conflict content, to ensure that high-priority conflicts can be handled in a timely manner and improve the merging efficiency. The system extracts the basic attributes of the conflict content, and then forms an ordered conflict content sequence according to the sorting results of the priority rules, which facilitates subsequent processing.

[0105] 203、according to the interface parameter type requirements and the calling sequence requirements in the logical dependency relationship, performing parameter type matching verification and calling sequence consistency verification on each conflict content identifier in the conflict content sequence, and marking the conflict content identifier that fails the verification as a conflict to be handled;

[0106] In step 203, the parameter type matching verification refers to checking whether the parameter types of the same interface in different versions are consistent. The calling sequence consistency verification refers to confirming whether the calling process between modules conforms to the expected logic. These two verifications are used to filter out the content that can be safely merged. The conflict to be handled refers to the conflict content that does not meet the requirements of the logical dependency relationship and needs to be further handled or adjusted manually.

[0107] In the embodiments of the present application, the system verifies each item in the conflict content sequence. For each conflict content identifier, first, check whether the interface parameter types are consistent. If not, mark it as a conflict to be handled. Second, check whether the calling sequence conforms to the expectation. If the calling sequence is disordered and may affect the function running, it is also marked as a conflict to be handled. This process uses a pattern matching algorithm to verify the interface parameter types and the calling sequence, to ensure that only the conflict content that meets the logical dependency relationship can proceed to the next step. The system sequentially performs parameter type matching and calling sequence verification on each conflict content to ensure the safety and correctness of the merging.

[0108] 204. Convert the verified conflict content identifiers in the conflict content sequence into executable operation instructions, generate prompt information for the conflict pending items, and combine the executable operation instructions and the prompt information in the execution order to generate a merge operation instruction set.

[0109] In step 204, executable operation instructions refer to code merging actions that can be directly executed by the system. Prompt messages provide operational suggestions or warnings for conflicting content that cannot be automatically handled. The merge operation instruction set is a collection of specific operation commands used to guide the specific execution steps of subsequent code merging. Conflict content identifiers are used to uniquely identify each conflicting content for easy tracking and handling.

[0110] In this embodiment, the system uses a scripting language to convert the verified conflict content into specific executable operation instructions, such as "insert the following code on line X of the specified file" or "replace a certain function body". Simultaneously, natural language processing technology is used to generate contextual prompts for the conflict items, such as "Please confirm whether this parameter type change affects the caller". Finally, the system combines all executable operation instructions and prompts into a complete merge operation instruction set according to the execution order, for subsequent execution layer calls or user reference.

[0111] Here is a specific example:

[0112] In a software development project for an intelligent transportation system, multiple development teams were responsible for upgrading the traffic light control logic and the traffic flow prediction module, respectively. Due to the use of a multi-version parallel development model, a conflict arose between the two branches when they were submitted to the main branch 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 handling priority rules in the multi-version merging strategy, the conflicting content of the two versions was prioritized, determining that the changes to the traffic flow prediction module should be processed first. Next, the system verified the consistency of parameter types and call order for the conflicting content, discovering that the parameter types of the traffic light module had not been updated, causing incompatibility issues; therefore, this part was marked as a conflict to be processed. Finally, the system converted the verified conflicting content into executable operation instructions, generated prompts for the conflict to be processed items, and output a complete merged operation instruction set for developers' reference or automatic system execution. The entire process achieved structured analysis and intelligent processing of complex conflicts, improving merging efficiency and accuracy.

[0113] In summary, steps 201 to 204 realize the structured ordering and automatic verification of the code conflict content by deep utilization of the logical dependency relationship in the version relationship graph, combined with the conflict processing priority rules and the multi-dimensional verification mechanism, and generate executable merging operation instruction set, which significantly improves the code merging efficiency and safety in the multi-version parallel development scenario, reduces the risk brought by human intervention, and enhances the intelligent level of software development collaboration in the cloud environment.

[0114] To further improve the intelligent ordering capability of the code merging process, the scheme classifies the conflict types, version identifiers and submitter information of the conflict content, calculates the ordering weight in combination with the version submission time and submitter permission two dimensions, realizes the scientific ordering of the conflict content, provides a reasonable execution order for the subsequent merging operation, and improves the controllability and automation level of the merging process. In some embodiments, step 202 sorts the conflict content in the code version difference data based on the conflict processing priority rules defined in the multi-version merging strategy, and generates 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 to 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 conflict, variable renaming conflict or interface parameter change conflict, etc. The associated version sequence identifier is an identity tag used to uniquely identify the code branch or version that causes the conflict. The submitter identifier is used to uniquely identify the developer or team identity information that submits the code version. The conflict content attribute set is a structured data set composed of the conflict type, associated version sequence identifier and submitter identifier, which is used to record the basic attribute information of each conflict content.

[0117] In the embodiments of the present application, the system extracts all conflict content code segments from the code version difference data through static analysis and version comparison technology, and collects the conflict type, version sequence identifier of the associated version and identity information of the submitter for each conflict content in each code segment to form the conflict content attribute, which provides input basis for subsequent classification and ordering.

[0118] 302. According to the conflict processing priority rules defined in the multi-version merging strategy, the conflict content in the conflict content attribute set is classified to generate a conflict content classification set;

[0119] In step 302, the conflict processing priority rule is a set of pre-set condition set for guiding how to determine the processing order of the conflict content. The conflict content classification set is a result set obtained by preliminarily grouping the conflict content according to part of the conditions in the conflict processing priority rule.

[0120] In the embodiment of the present application, the system preliminarily classifies the content in the conflict content attribute set according to the conditions set in the conflict processing priority rule, such as the severity of the conflict type and the importance of the version branch. For example, the function-level conflict involving the core function module is classified as a high-priority category, and the conflict involving only the annotation or format adjustment is classified as a low-priority category. This step uses a rule-based classification algorithm to identify and group each conflict content according to the pre-set rule, generates a conflict content classification set, and serves as the basis for the next step of sorting.

[0121] 303、Based on the version submission time condition and the submitter permission condition in the conflict processing priority rule, the sorting weight value of the conflict content in the conflict content classification set is calculated, and the conflict content in the conflict content classification set is sorted according to the sorting weight value, and a conflict content sequence is generated.

[0122] In step 303, the version submission time condition refers to the submission time sequence of the version to which the conflict content belongs, and the submitter permission condition refers to the permission level of the developer who submits the conflict content. The sorting weight value is a value calculated by comprehensively considering the version submission time and the submitter permission, and is used to measure the relative priority of the conflict content to be processed.

[0123] In the embodiment of the present application, the system obtains the submission time of the version to which each conflict content belongs from the version management system, and combines the role permission level of the submitter to give a corresponding initial weight value. For example, the version submitted earlier obtains a higher basic weight, and the content submitted by the core developer obtains an additional score. Then, the system uses a weighted scoring algorithm to fuse the weights of the two dimensions to obtain the final sorting weight value of each conflict content. After the weight calculation of all conflict contents is completed, the system uses a sorting algorithm to arrange the conflict contents in descending order of weight value, and generates a conflict content sequence.

[0124] The following is a specific example:

[0125] In a software development project for an intelligent transportation system, multiple development teams were responsible for upgrading the traffic light control logic and traffic flow prediction modules, respectively. Due to the use of a multi-version parallel development model, two teams modified code on their respective branches, leading to multiple conflicts during the merging process. The system first extracts these conflicting contents, identifying their conflict type, version, and submitter identity, constructing a set of conflict content attributes. Next, based on the type classification criteria in the conflict handling priority rules, conflicts affecting interface calls are classified as high priority, while formatting modifications are classified as low priority. Subsequently, the system calculates a sorting weight value for each conflicting content based on the version submission time and submitter permissions, ultimately generating an ordered sequence of conflicting contents. This sequence guides the generation order of subsequent merging operation instructions, achieving intelligent sorting and efficient processing of complex conflicting contents.

[0126] In summary, steps 301 to 303, through attribute extraction, initial classification, and ranking weight calculation of conflicting content, achieve structured sorting of code conflicting content during multi-version parallel development. This approach not only improves the rationality of the conflict handling order but also enhances the system's understanding of the development context, thereby increasing the automation level and execution efficiency of code merging, reducing the uncertainty caused by manual intervention, and optimizing the overall collaborative development experience in a cloud environment.

[0127] To address the challenge of structurally representing inter-version call relationships during multi-version parallel development, this solution analyzes call records between version branches to identify data flow directions and annotates logical dependencies using interface constraints. Ultimately, it presents the interaction structure between versions in a graph format, providing semantic support for conflict detection and merging strategy matching, and enhancing the system's understanding of code dependencies. In some embodiments, step 102, which involves constructing a version relationship graph reflecting the data flow direction and logical dependencies between versions based on the call relationships between version branches in the code version difference data, includes:

[0128] 401. Extract the call records between each version branch from the code version difference data. The call records include the calling version identifier, the called version identifier, and the call operation type.

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

[0130] In the embodiments of the present application, the system first analyzes the source code structure of each version, identifies the statements involving external version calls through static code analysis technology and version change comparison mechanism; then, in combination with the version submission history, judges whether the calling behavior exists in the current version, and extracts the calling version identification, the called version identification and the calling operation type, to generate complete call records as the basic input for subsequent construction of data flow links.

[0131] 402. Determine the data flow direction between the calling version identification and the called version identification according to the calling operation type in the call record, and establish a data flow link from the called version identification to the calling version identification according to the data flow direction;

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

[0133] In the embodiments of the present application, the system determines the data flow direction according to the calling operation type in the call record. For example, in the function calling scenario, if the calling version calls the function of the called version, the data flows from the called version to the calling version. The system establishes a data flow link from the called version identification to the calling version identification accordingly. This process uses graph structure modeling technology to convert each call record into a directed edge with a direction attribute, and finally generates multiple data flow links for subsequent annotation of logical dependency relationships.

[0134] 403. Mark the corresponding logical dependency relationship on the data flow link based on the interface constraint condition in the called version identification;

[0135] In step 403, the interface constraint condition refers to the restrictive rules defined in the called version, such as interface parameter type, return value format, calling order, etc. The logical dependency relationship refers to the semantic level dependency structure between two versions formed due to interface calling, which affects the compatibility judgment during code merging.

[0136] In the embodiments of the present application, on each data flow link, the system analyzes whether the actual use of the interface by the main calling version meets the interface constraint conditions defined by the called version according to the actual use of the interface by the main calling version. If there is a specific type of dependency, such as a parameter type dependency or a calling sequence dependency, the corresponding logical dependency relationship is marked on the data flow link. This process uses syntax tree parsing and interface contract verification technology to identify specific logical dependency relationships by comparing calling expressions in the source code and interface declarations, and attaches them to the corresponding data flow link, thereby enhancing the semantic expression capability of the inter-version calling relationship and providing a basis for subsequent conflict detection.

[0137] 404. Combining 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 structure model with version identifiers as nodes and data flow links and logical dependency relationships as connection relationships, reflecting the data flow direction and logical dependency strength between versions.

[0139] In the embodiments of the present application, the system first takes all version identifiers as nodes in the graph, and each node represents an independent code version. Then, the system takes the previously generated data flow link as a directed edge connecting the corresponding main calling version node and the called version node. At the same time, the system converts the logical dependency relationship marked on the data flow link into an attribute label on the edge to express the interface dependency type between different versions. Finally, the system integrates all nodes and edges with attributes through graph database technology to build a complete version relationship graph.

[0140] The following is a specific example:

[0141] In the software development project of the intelligent transportation system, multiple development teams are responsible for the upgrade tasks of the signal light control module and the traffic flow prediction module. Due to the use of multi-version parallel development mode, there is an interface calling relationship between the two versions. The system first extracts the calling record from the code version difference data, identifies the function calling behavior between the main calling version and the called version, and determines the calling operation type. Then, the system determines the data flow direction according to the calling type, establishes a data flow link from the called version to the main calling version. Finally, the system integrates all data flow links and logical dependency relationships to build a version relationship graph with version identifiers as nodes and links and dependency relationships as edges.

[0142] In summary, steps 401 to 404 achieve the visual expression of the multi-version code dependency relationship by structuring the extraction and logical dependency modeling of the inter-version call relationship. This method improves the system's understanding of inter-version data flow and semantic dependency, enhances the intelligent level of conflict detection and merging decision, and significantly improves the collaboration efficiency and code management quality of multi-version parallel development in a cloud environment.

[0143] To further improve the rationality and automation level of code conflict processing decision, the scheme analyzes the logical dependency relationship between the main version and the secondary version, identifies the constraint conditions affected by the conflict and calculates the conflict impact value, and then selects the appropriate merging strategy from the strategy library, realizes the dynamic association of strategy selection and conflict severity, and improves the intelligent level of merging decision. In some embodiments, the step 103 of matching the multi-version merging strategy suitable for multi-version software development from the preset strategy library according to the conflict state and the association strength of the logical dependency relationship in the version relationship graph includes:

[0144] 501. Determine the main version identifier and the secondary version identifier of the conflict according to the conflict state marked in the version relationship graph, wherein the main version identifier is the version corresponding to the current main development path;

[0145] In step 501, the conflict state indicates that different versions have made contradictory changes to the same piece of code, resulting in a state that cannot be directly merged. The main version identifier refers to the version identity tag corresponding to the current main development path, which usually represents the core branch or stable branch. The secondary version identifier is the identity tag of the other version that conflicts with the main version.

[0146] In the embodiments 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 with a conflict state, and determines which version node should be identified as the main version using an algorithm based on a branch weight evaluation model. According to the stability, importance and influence of the version in the project development process, a weight score is assigned to each version, and the version with the highest weight is identified as the main version. The remaining versions that conflict with the main version are classified as secondary versions. This process not only considers the topological structure between versions, but also introduces historical submission behavior analysis to ensure the accuracy of the main and secondary division and provide reliable input for subsequent conflict impact assessment.

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

[0148] In step 502, logical dependency refers to the semantic-level dependency structure formed between two versions due to function calls, interface references, or data interactions. The constraint set is a collection of multiple interface parameter type requirements, return value format rules, and call order requirements, used to describe the specific restrictions in the logical dependency. The conflict impact value is a numerical indicator that measures the severity of a conflict, determined by the number of constraints and their corresponding preset weight values.

[0149] In this embodiment, the system uses a subgraph matching algorithm to extract all logical dependencies between major and minor version identifiers from the version relationship graph. Next, it employs syntax tree comparison technology to analyze the interface definition information within these logical dependencies item by item, identifying which interface constraints are affected by conflicting content. For example, if the parameter type, return value format, or calling order of an interface is inconsistent between the two versions, it is included in the constraint set. Subsequently, the system assigns a corresponding weight value to each constraint based on a pre-defined constraint weight table. The weight values ​​are dynamically adjusted according to the interface's importance in the system, its usage frequency, and the scope of its impact. Finally, the system calculates the conflict impact value using a weighted summation method.

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

[0151] In step 503, the preset strategy library is a knowledge base containing various merge strategies, each corresponding to a specific conflict type and priority value. A merge strategy is a set of rules that guides the system on how to handle different types of code conflicts. The priority value indicates the severity level of the conflict to which a particular merge strategy applies.

[0152] In this embodiment, the system employs a rule-matching algorithm and a similarity ranking mechanism to search for a merging strategy that matches the current conflict type from a preset strategy library. First, the system performs pattern matching between the conflict type in the conflict state and the strategy types in the strategy library to filter out a set of candidate strategies. Then, combining the calculated conflict impact value, a linear interpolation method is used to map the conflict impact value to the priority value range in the strategy library to find the most suitable strategy. Finally, the system constructs a mapping table to bind the selected merging strategy with the major version identifier and the minor version identifier, generating a complete multi-version merging strategy.

[0153] Here is a specific example:

[0154] In a software development project of an intelligent transportation system, multiple development teams are responsible for upgrading the signal control module and the traffic flow prediction module. Due to the use of multi-version parallel development mode, the two versions have conflicts in interface parameter definitions. The system first identifies the conflict state from the version relationship graph through a graph traversal algorithm, and combines the version submission time, branch level and data flow direction to determine the main version identification as the current trunk branch and the secondary version identification as the feature branch using a branch weight evaluation model. Then, the system selects an adaptive merging strategy from a pre-set strategy library using a rule matching algorithm and a priority mapping mechanism. Finally, the system associates the strategy with the main version identification and the secondary version identification to generate a complete multi-version merging strategy. The whole process realizes intelligent identification and strategy matching of complex conflicts, improving the merging efficiency and quality.

[0155] In summary, steps 501 to 503 realize intelligent strategy matching of multi-version code conflicts by dividing the conflict state in the version relationship graph into primary and secondary versions, identifying and calculating conflict impact values in combination with constraint conditions in logical dependencies, and then fusing rule matching and priority mapping mechanisms. This method not only improves the automation level of the merging process, but also enhances the system's understanding of semantic dependencies between versions, thereby effectively reducing the uncertainty caused by manual intervention and significantly optimizing the collaboration efficiency and code stability of multi-version parallel development in a cloud environment.

[0156] To further improve the explainability and operability of conflict points in logical dependencies, the scheme determines the constraint effective link based on the interaction behavior records and interface constraint declarations between the primary and secondary versions, and identifies the specific constraint conditions that violate logical dependencies to generate a complete constraint condition set, providing key inputs for conflict impact assessment and strategy matching. In some embodiments, the extraction of logical dependency relationships between the main version identification and the secondary version identification in step 502 includes:

[0157] 601. Extract the logical dependency relationship between the main version identification and the secondary version identification from the version relationship graph, and determine the interaction operation records and interface constraint declarations between the versions according to 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 is the data describing the specific calling behavior between the main 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, calling order, etc.

[0159] In the embodiments of the present application, the system locates all logical dependency relationships between the main version identifier and the secondary version identifier from the version relationship graph through a subgraph matching algorithm, and extracts the actual call paths involved therein. Subsequently, the system traverses these paths using a graph traversal technique to obtain corresponding interactive operation records, including the calling method name, the parameter passing mode, and the 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 interactive operation record, and generate a constraint effective link;

[0161] In step 602, the interaction type refers to the specific form of the calling behavior between different versions, such as function calling, asynchronous callback, or event listening. The interaction behavior direction represents the flow relationship between the calling party and the called party during code execution. The constraint effective link is a path model constructed according to the interaction behavior direction, used to represent the path of interface constraint propagation and action between versions.

[0162] In the embodiments 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 calling behaviors such as synchronous calling and asynchronous calling. Then, the system determines the directionality of each calling behavior based on the call stack analysis technique and the 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 the constraint effective link, propagates the interface constraint along the calling path, and determines which version modification will directly affect the establishment of the interface constraint. This process ensures that the system can accurately understand the propagation path of the interface constraint in the entire calling chain, providing a basis for the next step of conflict identification.

[0163] 603. Based on the constraint effective link and the interface constraint declaration, identify the constraint conditions between the main version identifier and the secondary 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 composed of multiple interface parameter type requirements, return value format rules, and calling order requirements, used to describe the interface restriction conditions that are violated in the logical dependency relationship.

[0165] In the embodiments of the present application, the system compares the constraint effective 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 is inconsistency. For example, if the parameter type of an interface in the main version is integer, and the secondary version changes it to floating point type, this item is included in the constraint condition set; similarly, if the calling order changes, causing the dependency chain to break, it will also be identified as a violation item. The whole identification process combines structured comparison algorithm and semantic analysis technology to ensure that all constraint conditions affected by conflicts can be accurately captured, and finally a clear structure and complete content constraint condition set is generated, providing key input for subsequent conflict impact assessment and strategy matching.

[0166] The following is a specific example:

[0167] In the software development project of intelligent transportation system, multiple development teams are responsible for the upgrade task of signal control module and traffic flow prediction module. Due to the use of multi-version parallel development mode, two groups made code modifications on their respective branches, and found that there is an inconsistency problem in the interface parameter type when merging. The system first extracts the logical dependency relationship between the two versions from the version relationship graph by subgraph matching algorithm, identifies the calling path and interface usage record. Then, the system analyzes the interaction behavior direction, constructs the constraint effective link, and determines the propagation of interface constraint along the calling path. Then, the system compares the interface declaration with the actual calling situation, finds that the signal control module changes the parameter type of an interface in the secondary version, thereby violating the original logical dependency relationship. The abnormal item is added to the constraint condition set. The whole process realizes the accurate identification of the conflict impact range, improves the accuracy and rationality of the merge strategy selection.

[0168] In summary, steps 601 to 603 realize the accurate identification of constraint conditions affected by conflicts by deeply mining the logical dependency relationship between the main version and the secondary version, combining interaction behavior direction analysis and interface declaration comparison. This method not only improves the system's understanding of the dependency structure between versions, but also provides a structured decision basis for subsequent conflict impact assessment and merge strategy matching, significantly enhances the level of automatic conflict processing in the multi-version parallel development environment, reduces the cost of manual intervention, and guarantees the code quality and system stability.

[0169] To further improve the automation capability of the version-merging post-mapping state synchronization update and new version generation, the scheme updates the conflict marker and data flow in the version relationship mapping by analyzing the merging feedback data, extracting the modification content and conflict processing state, and assigning a unique identifier to the newly generated version while synchronously binding the storage location, ensuring the consistency and traceability of the version information and perfecting the entire version lifecycle management process. In some embodiments, the step 105 of updating the conflict state in the version relationship mapping according to the feedback data of the merging operation instruction set and synchronously triggering the data update of the storage location and the reassignment of the version sequence identifier includes:

[0170] 701. Analyzing the feedback data of the merging operation instruction set, extracting the modification content identifier, conflict processing state and conflict content identifier recorded in the feedback data, and 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;

[0171] In step 701, the feedback data of the merging operation instruction set refers to the result information returned by the system after the code merging operation is completed, which includes the modification content identifier, the conflict processing state and the conflict content identifier. The modification content identifier is used to uniquely identify the modified code segment or interface definition. The conflict processing state indicates whether the conflict has been successfully resolved. The storage location is a physical or logical path for saving the code change result.

[0172] In the embodiments of the present application, the system first structures and analyzes the feedback data of the merging operation instruction set by log analysis technology, extracts the modification content identifier, conflict processing state and conflict content identifier recorded therein. Then, the system retrieves the original change content corresponding to these modification content identifiers from the code version difference data, and writes these change contents into 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 landed in the persistent storage, providing data support for subsequent version identifier update.

[0173] 702. According to the conflict processing state, updating the data flow link between the primary version sequence identifier and the secondary version sequence identifier associated with the conflict content identifier in the version relationship mapping, and generating a new version sequence identifier;

[0174] In step 702, the primary version sequence identifier refers to the identity tag of the current main development path corresponding version. The secondary version sequence identifier is the identity tag of the other version that conflicts 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 merging.

[0175] In the embodiments of the present application, the system determines whether the conflict has been completely resolved according to the conflict processing state. If the state is “resolved”, the system deletes the conflict mark between the original main version and the secondary version in the version relationship graph through a graph update algorithm, and reconstructs the data flow link based on the merged code structure. At the same time, the system generates a new version sequence identifier using an incremental naming strategy, which is a combination of the original main 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 and the update of the graph state are completed synchronously, forming a unified version evolution path.

[0176] 703. Bind the new version sequence identifier with the storage location, and synchronously update the connection relationship and conflict state 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 merging. The storage location is the physical or logical path for saving the code change result. The connection relationship refers to the edge structure between nodes in the version relationship graph, representing the calling and dependency relationship between versions. The conflict state indicates whether there is an unresolved code conflict between different versions.

[0178] In the embodiments 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. Then, the system updates the connection relationship between the main version node and other related nodes using a graph reconstruction algorithm, removes the resolved conflict mark, and adds an edge pointing to the new version node to reflect the latest connection relationship and conflict state of the main version sequence identifier node. The 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] The following is a specific example:

[0180] In a software development project of an intelligent transportation system, multiple development teams are responsible for upgrading the signal control module and the traffic flow prediction module. Due to the use of multi-version parallel development mode, the codes submitted by the two teams have conflicts in interface parameter types. After the system performs the merging operation, feedback data is generated, including modification content identifier, conflict processing state and conflict content identifier. The system first parses the feedback data, extracts the modification content and writes it to the specified storage path. Then, the system updates the data flow link in the version relationship graph according to the state of the conflict being solved, and generates a new version sequence identifier. Finally, the system binds the new version identifier with the storage location, updates the connection relationship of the main version node in the graph, removes the conflict mark, and forms a complete version evolution path. The whole process realizes the automatic update of version state and real-time synchronization of graph structure, and improves the intelligent management level of multi-version collaborative development.

[0181] In summary, steps 701 to 703 realize the closed-loop update of the version relationship graph after the multi-version code merging and the state consistency guarantee by parsing and storing the feedback data of the merging operation, dynamically adjusting the data flow link, generating a new version identifier, and synchronously maintaining the graph connection relationship and conflict state. This method not only improves the traceability and visualization of the version evolution process, but also enhances the automation level and stability of the version management system in the cloud environment, significantly optimizing the collaboration efficiency and code quality in the multi-version parallel development scenario.

[0182] Figure 2 A structural diagram of a software development data management system based on cloud services is provided for the embodiments of the present application, as shown in Figure 2 The system comprises:

[0183] The acquisition module 21 acquires the code version difference data generated in the multi-version software development process in the cloud service environment, and distributes the code version difference data according to the version sequence identifier to the storage location corresponding to the version sequence identifier.

[0184] The 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 version branches in the code version difference data.

[0185] The matching module 23 matches a multi-version merging strategy suitable for multi-version software development from a pre-set strategy library according to the conflict state and correlation strength of the logical dependency relationship in the version relationship graph.

[0186] The generation module 24, when detecting that there is a concurrent modification request for the same version sequence identifier code, sorts and logically dependent verifies the conflict content in the code version difference data based on the conflict state of the version relationship graph and the multi-version merging strategy, and generates a merging operation instruction set;

[0187] The update module 25 updates the conflict state in the version relationship graph according to the feedback data of the merging operation instruction set, and synchronously triggers data update of the storage location and reassignment of the version sequence identifier.

[0188] Figure 2 The software development data management system based on cloud services can perform Figure 1 The software development data management method based on cloud services described in the embodiment has the same implementation principles and technical effects as the software development data management system based on cloud services described in the embodiment. The specific operation of each module and unit in the software development data management system based on cloud services described in the embodiment has been described in detail in the embodiment related to the method, and will not be described in detail here.

[0189] In one possible design, Figure 2 The software development data management system based on cloud services described in the embodiment can be implemented as a computing device, such as a server. Figure 3 As shown in the figure, the computing device can 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 configured to perform the above Figure 1 The software development data management method based on cloud services described in the embodiment.

[0192] The processing component 32 can include one or more processors to execute computer instructions to complete all or part of the steps in the above method. Of course, the processing component can also be 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, for executing the above method.

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

[0194] Of course, the computing device can also necessarily include other components, such as an input / output interface, a display component, a communication component, etc.

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

[0196] The communication component is configured to facilitate communication between the computing device and other devices in a wired or wireless manner, etc.

[0197] The computing device can be a physical device or an elastic computing host provided by a cloud computing platform, and the computing device can be a cloud server, and the processing component, the storage component, etc. can be a basic server resource rented or purchased from the cloud computing platform.

[0198] The embodiment of the present application also provides a computer storage medium, which stores a computer program, and the computer program can implement the above-mentioned Figure 1 The embodiment shown in the figure is a software development data management method based on cloud services.

[0199] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working process of the above-mentioned system, device and unit can refer to the corresponding process in the foregoing method embodiment, which will not be described here.

[0200] The device embodiment described above is only schematic, wherein the units described as separate components can or can not be physically separated, and the components displayed as units can or can not be physical units, that is, they can be located in one place, or distributed on multiple network units. Part or all of the modules can be selected according to actual needs to achieve the purpose of the embodiment scheme. Those skilled in the art can understand and implement it without creative labor.

[0201] Those skilled in the art can clearly understand the implementation of the various embodiments by means of software and the necessary general hardware platform from the above description of the embodiments, and of course, the embodiments can also be implemented by hardware. Based on such understanding, the above technical solutions, essentially or in other words, the part of the prior art that contributes to the technical solutions 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 a ROM / RAM, a magnetic disk, an optical disk, and the like, and includes a number of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in the various embodiments or some parts of the methods.

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

Claims

1. A cloud service-based software development data management method, characterized by, The method comprises the following steps: acquiring code version difference data generated in a multi-version software development process in a cloud service environment, and distributing the code version difference data to a storage location corresponding to a version sequence identifier according to the version sequence identifier; constructing a version relationship graph reflecting data flow direction and logical dependency relationship between versions based on the calling relationship between version branches in the code version difference data; matching a multi-version merging strategy suitable for multi-version software development from a preset strategy library according to the conflict state and correlation strength of the logical dependency relationship in the version relationship graph; when a concurrent modification request for the code of the same version sequence identifier is detected, sorting and logically verifying the conflict content in the code version difference data based on the conflict state of the version relationship graph and the multi-version merging strategy, and generating a merging operation instruction set; updating the conflict state in the version relationship graph according to the feedback data of the merging operation instruction set, and synchronously triggering data update of the storage location and re-distribution of the version sequence identifier; wherein, based on the calling relationship between version branches in the code version difference data, a version relationship graph reflecting data flow direction and logical dependency relationship between versions is constructed, which comprises: extracting calling records between version branches from the code version difference data, wherein the calling records contain a main calling version identifier, a called version identifier, and a calling operation type; determining the data flow direction between the main calling version identifier and the called version identifier according to the calling operation type in the calling records, and establishing a data flow link from the called version identifier to the main calling version identifier according to the data flow direction; marking the corresponding logical dependency relationship on the data flow link based on the interface constraint condition in the called version identifier; combining 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 the node and the data flow link and the logical dependency relationship as the connection relationship; wherein, based on the conflict state of the version relationship graph and the multi-version merging strategy, the conflict content in the code version difference data is sorted and logically verified to generate a merging operation instruction set, which comprises: extracting the logical dependency relationship associated with the conflict state from the version relationship graph, wherein the logical dependency relationship contains interface parameter type requirements, return value format rules, and calling sequence requirements; sorting the conflict content in the code version difference data based on the conflict handling priority rules defined in the multi-version merging strategy to generate a conflict content sequence; performing parameter type matching verification and calling sequence consistency verification on each conflict content identifier in the conflict content sequence according to the interface parameter type requirements and the calling sequence requirements in the logical dependency relationship, and marking the conflict content identifier that fails the verification as a conflict to be processed item; Convert the conflict content identifiers verified in the conflict content sequence into executable operation instructions, and generate prompt information for the conflict to-be-processed item, combine the executable operation instructions and the prompt information according to an execution order, and generate a set of merged operation instructions.

2. The method of claim 1, wherein, The conflict content in the code version difference data is sorted according to the conflict processing priority rules defined in the multi-version merging strategy, and a conflict content sequence is generated. The conflict type, associated version sequence identifier and submitter identifier corresponding to each conflict content in the code version difference data are extracted, and a conflict content attribute set is generated. The conflict content in the conflict content attribute set is classified according to the conflict processing priority rules defined in the multi-version merging strategy, and a conflict content classification set is generated. Based on the version submission time condition and the submitter permission condition in the conflict processing priority rules, the sorting weight values of the conflict contents in the conflict content classification set are calculated, and the conflict contents in the conflict content classification set are sorted according to the sorting weight values, and a conflict content sequence is generated.

3. The method of claim 1, wherein, The conflict state and the associated strength of the logical dependency relationship in the version relationship graph are matched with the multi-version merging strategy adapted to the multi-version software development from the preset strategy library, including: According to the conflict state marked in the version relationship graph, the main version identifier and the secondary version identifier of the conflict are determined, and the main version identifier is the version corresponding to the current main development path; Extract the logical dependency relationship between the main version identifier and the secondary version identifier, identify the constraint condition set affected by the conflict from the logical dependency relationship, and calculate the conflict influence value based on the constraint condition number in the constraint condition set and the preset weight value; Select a merging strategy from the preset strategy library that matches the conflict type and the conflict state, and that has a positive correlation between the priority value and the conflict influence value, and associate the merging strategy with the main version identifier and the secondary version identifier to generate a multi-version merging strategy.

4. The method of claim 3, wherein, The logical dependency relationship between the main version identifier and the secondary version identifier is extracted from the version relationship graph, and the constraint condition set affected by the conflict is identified from the logical dependency relationship, including: The logical dependency relationship between the main version identifier and the secondary version identifier is extracted from the version relationship graph, and the interaction operation record and the interface constraint declaration between the versions are determined according to the logical dependency relationship; According to the interaction type of the interaction operation record, the interaction behavior direction in the logical dependency relationship is analyzed, and a constraint effective link is generated; Based on the constraint effective link and the interface constraint declaration, the constraint condition between the main version identifier and the secondary version identifier that violates the logical dependency relationship is identified, and a constraint condition set is generated.

5. The method of claim 1, wherein, According to the feedback data of the set of merged operation instructions, the conflict state in the version relationship graph is updated, and the data update of the storage location and the re-allocation of the version sequence identifier are triggered synchronously, including: The feedback data of the merging operation instruction set is analyzed, the modification content identifier, the conflict processing state and the conflict content identifier recorded in the feedback data are extracted, the modification content corresponding to the modification content identifier is extracted from the code version difference data, and the modification content is stored in the storage location; According to the conflict processing state, the data flow direction link between the main version sequence identifier and the secondary version sequence identifier associated with the conflict content identifier in the version relationship graph is updated, and a new version sequence identifier is generated; The new version sequence identifier is bound to the storage location, and the connection relationship and the conflict state of the main version sequence identifier in the version relationship graph are synchronously updated.

6. A cloud service-based software development data management system applied to the cloud service-based software development data management method of any one of claims 1-5, characterized in that, It includes: An acquisition module acquires code version difference data generated in a multi-version software development process in a cloud service environment, and distributes the code version difference data to a storage location corresponding to a version sequence identifier according to the version sequence identifier; A construction module constructs a version relationship graph reflecting the data flow direction and logical dependency relationship between versions based on the calling relationship between version branches in the code version difference data; A matching module matches a multi-version merging strategy suitable for multi-version software development from a preset strategy library according to the conflict state and the association strength of the logical dependency relationship in the version relationship graph; A generation module, when detecting a concurrent modification request for the same version sequence identifier, sorts and logically verifies the conflict content in the code version difference data based on the conflict state of the version relationship graph and the multi-version merging strategy, and generates a merging operation instruction set; An update module updates the conflict state in the version relationship graph according to the feedback data of the merging operation instruction set, and synchronously triggers data update of the storage location and re-distribution of the version sequence identifier.

7. A computing device, comprising: 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 realize the software development data management method based on cloud service in any one of claims 1-5.

8. A computer storage medium, characterized in that A computer program is stored, and the computer program is executed by a computer to realize the software development data management method based on cloud service in any one of claims 1-5.

Images