Branch control method and device of version control system based on semantic analysis and intranet collaboration

Abstract

Embodiments of the present disclosure disclose a version control system branch control method and device based on semantic analysis and intranet collaboration. A specific embodiment of the method comprises: calling an information query instruction to obtain a uniform resource locator; extracting a set of historical commit records based on the uniform resource locator; filtering and analyzing the set of historical commit records to obtain a target version interval; generating code difference data based on the target version interval; performing defect detection on the code difference data to obtain a first defect record set; performing semantic analysis on the code difference data to obtain a second defect record set; performing hierarchical processing on the first defect record set and the second defect record set to generate a structured analysis report; and performing a code merging access control operation for the target branch based on the structured analysis report. The embodiment achieves the effect of reducing waste of computing resources and avoiding software build failure or system security vulnerabilities.

Description

Technical Field

[0001] The embodiments disclosed herein relate to the field of computer technology, and specifically to a branch control method and apparatus for a version control system based on semantic analysis and intranet collaboration. Background Technology

[0002] In collaborative software development processes using version control systems (such as Subversion), the creation, development, analysis, and merging of code branches are core components. To prevent software build failures, runtime exceptions, or system security vulnerabilities, branch control is typically required before merging a branch into the main branch or other target branches. Currently, the common approach to branch control in version control systems is to integrate static code analysis tools (such as CheckStyle or PMD) to scan the code based on predefined syntax and coding style rules.

[0003] However, when using the above method for branch control in a version control system, the following technical problems often arise: Existing static analysis tools cannot understand the semantics of code changes within a specific version context and project architecture, leading to the underreporting of deep-seated technical risks such as circular dependencies, interface contract violations, and resource leakage patterns. In distributed version control systems, the lack of automated code change impact analysis mechanisms deeply integrated with version history before branch merging results in low-quality or conflict-prone code being merged into the main branch. This problematic code, after merging, triggers frequent build failures, wasting the CPU, memory, and bandwidth resources of the build server, and further leading to specific technical failures such as software build failures, runtime anomalies, or system security vulnerabilities.

[0004] Existing solutions, when applying review results to access control, typically rely solely on a simple count of defects or a mechanical judgment based on the highest severity level. This lacks a comprehensive quantitative assessment of the overall risk of defects, leading to misjudgments or process blockages in the interception rules. Furthermore, this can result in the failure of continuous integration system construction, instability of the testing environment, or even runtime failures. Fixing these problems will consume a significant amount of additional computing, storage, and network resources.

[0005] The information disclosed in this background section is only intended to enhance the understanding of the background of the inventive concept, and therefore may contain information that does not constitute prior art known to those skilled in the art. Summary of the Invention

[0006] The summary portion of this disclosure is intended to provide a brief overview of the concepts, which will be described in detail in the detailed description portion. This summary portion is not intended to identify key or essential features of the claimed technical solutions, nor is it intended to limit the scope of the claimed technical solutions.

[0007] Some embodiments of this disclosure propose a branch control method, apparatus, electronic device, and computer-readable medium for a version control system based on semantic analysis and intranet collaboration to solve one or more of the technical problems mentioned in the background section above.

[0008] In a first aspect, some embodiments of this disclosure provide a branch control method for a version control system based on semantic analysis and intranet collaboration. The method includes: invoking an information query command of the version control system to obtain a Uniform Resource Locator (URL) for a target branch; extracting a historical commit record set of the target branch based on the URL; filtering and analyzing the historical commit record set to obtain a target version range; generating code difference data based on the target version range; performing deterministic defect detection on the code difference data to obtain a first defect record set; performing semantic analysis on the code difference data to obtain a second defect record set; fusing and hierarchically processing the first and second defect record sets to obtain a defect record list; and generating a structured analysis report based on the defect record list; and performing a code merging access control operation for the target branch based on the structured analysis report.

[0009] Secondly, some embodiments of this disclosure provide a branch control device for a version control system based on semantic analysis and intranet collaboration. The device includes: a calling unit configured to call an information query instruction of the version control system to obtain a Uniform Resource Locator (URL) for a target branch; an extraction unit configured to extract a set of historical commit records for the target branch based on the URL; a filtering and analysis unit configured to perform filtering and analysis on the set of historical commit records to obtain a target version range; a generation unit configured to generate code difference data based on the target version range; a detection unit configured to perform deterministic defect detection on the code difference data to obtain a first defect record set; a semantic analysis unit configured to perform semantic analysis on the code difference data to obtain a second defect record set; a processing unit configured to perform fusion and hierarchical processing on the first and second defect record sets to obtain a defect record list, and generate a structured analysis report based on the defect record list; and an execution unit configured to perform a code merging access control operation for the target branch based on the structured analysis report.

[0010] Thirdly, some embodiments of this disclosure provide an electronic device, including: one or more processors; and a storage device having one or more programs stored thereon, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the method described in any implementation of the first aspect above.

[0011] Fourthly, some embodiments of this disclosure provide a computer-readable medium having a computer program stored thereon, wherein the program, when executed by a processor, implements the method described in any of the implementations of the first aspect above.

[0012] The above-described embodiments of this disclosure have the following beneficial effects: Through the version control method of this disclosure based on semantic analysis and intranet collaboration in a version control system, a series of methods are implemented to deeply interact with the version control system, intelligently process and analyze structured data, and ultimately achieve automated process control. This reduces the waste of computing resources and avoids software build failures or system security vulnerabilities. Specifically, the reasons for software build failures or system security vulnerabilities are that existing static analysis tools cannot understand the semantics of code changes in a specific version context and project architecture, leading to the underreporting of deep-seated technical risks such as circular dependency introduction, interface contract violation, and resource leakage patterns. In distributed version control systems, due to the lack of an automated code change impact analysis mechanism deeply associated with version history before branch merging, low-quality or conflict-risk code is merged into the main branch. After the problematic code is merged, subsequent builds frequently fail, wasting the CPU, memory, and bandwidth resources of the build server, further leading to specific technical failures such as software build failures, runtime anomalies, or system security vulnerabilities. Based on this, some embodiments of the version control system branch control method based on semantic analysis and intranet collaboration disclosed herein first invoke the information query command of the version control system to obtain the Uniform Resource Locator (URL) of the target branch. This provides a unique and accurate review target location for all subsequent operations, constructing a standardized review context. Second, based on the aforementioned URL, the historical commit record set of the target branch is extracted. This obtains structured and complete branch evolution history data, providing a data foundation for subsequent intelligent analysis. Then, the historical commit record set is filtered and analyzed to obtain the target version range. This eliminates noise data introduced by synchronous merging commits, solving the technical problem of redundant review scope. Next, based on the aforementioned target version range, code difference data is generated. This generates structured and accurate code change details data, providing high-quality input for subsequent rule detection and semantic depth analysis, avoiding invalid calculations. Then, deterministic defect detection is performed on the code difference data to obtain a first defect record set. This detects all defects in the code that violate preset coding standards and deterministic defect patterns (such as syntax errors and resource leaks). Subsequently, semantic analysis is performed on the code difference data to obtain a second defect record set. Therefore, while ensuring the security of source code data remaining within the internal network, this approach can deeply identify semantic-level issues such as logical contradictions, design flaws, and potential risks in the code, compensating for the shortcomings of rule-based detection. Furthermore, the aforementioned first and second defect record sets are fused and hierarchically processed to obtain a defect record list, and a structured analysis report is generated based on this list. This allows for the collaborative integration of multi-source detection results, generating standardized, clearly defined, and machine-readable review conclusions that can directly drive subsequent automated processes through unified hierarchical classification and conflict resolution.Finally, based on the structured analysis report above, code merging access control operations are performed on the target branches. This automates the execution of code quality access control, creating a complete technical control loop from code review to merging decisions. This implementation reduces wasted computing resources and avoids software build failures or system security vulnerabilities. Attached Figure Description

[0013] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and elements are not necessarily drawn to scale.

[0014] Figure 1 This is a flowchart of some embodiments of the branch control method of the version control system based on semantic analysis and intranet collaboration disclosed herein; Figure 2 This is a schematic diagram of the structure of some embodiments of the branch control device of the version control system based on semantic analysis and intranet collaboration according to the present disclosure; Figure 3 This is a schematic diagram of the structure of an electronic device suitable for implementing some embodiments of the present disclosure. Detailed Implementation

[0015] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0016] It should also be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings. Unless otherwise specified, the embodiments and features described in this disclosure can be combined with each other.

[0017] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are used only to distinguish different devices, modules or units, and are not used to limit the order of functions performed by these devices, modules or units or their interdependencies.

[0018] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0019] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0020] This disclosure will now be described in detail with reference to the accompanying drawings and embodiments.

[0021] Figure 1 A flowchart 100 is shown illustrating some embodiments of a version control system branch control method based on semantic analysis and intranet collaboration according to this disclosure. This version control system branch control method based on semantic analysis and intranet collaboration includes the following steps: Step 101: Invoke the information query command of the version control system to obtain the Uniform Resource Locator (URL) of the target branch.

[0022] In some embodiments, the execution entity (e.g., a server) of the version control system branch control method based on semantic analysis and intranet collaboration can invoke the version control system's information query command to obtain the Uniform Resource Locator (URL) of the target branch. The version control system (VCS) can be a software system used to track and manage the change history of computer files (such as source code files). For example, the version control system can be Subversion (SVN) or Git. The information query command can be a specific command or function call provided by the version control system (through a command-line interface or API) to request and return detailed attribute information of its managed entities (such as repositories, branches, files, etc.). For example, the information query command can be the svn info command of the SVN system. The URL can be an address string within the version control system that uniquely identifies the storage location of the target branch in the entire repository. The URL can be represented as a network path or an address in a specific protocol format. For example: https: / / svn.example.com / repos / project / trunk. The version control system branch can be an isolated code version container created and managed by a computer within the version control system to support parallel code development. The target branch mentioned above can be the version control system branch that this method is targeting and that needs to be analyzed.

[0023] Step 102: Extract the historical commit record set of the target branch based on the Uniform Resource Locator (URL).

[0024] In some embodiments, the executing entity can extract the historical commit record set of the target branch based on the Uniform Resource Locator (URL). In practice, the executing entity can invoke the historical commit record query command of the version control system, using the URL as a parameter, to extract all historical commit records of the target branch from its creation time to the current time (or a specified endpoint, such as a specific time point, 2026 / 1 / 1 12:00), thus obtaining the historical commit record set. These historical commit records can be structured data arranged chronologically and recording code change events. As an example, the historical commit records may include a commit hash (unique ID), committer, commit time, commit description, and changed file groups. As an example, the above historical commit record can be represented as: [Commit hash: a1b2c3d4, Submitter: zhangsan, Commit time: 2026-05-10 14:30:25, Commit description: "Fixed a null pointer exception issue in the user login interface", Changed file groups: src / main / java / com / example / auth / LoginController.java, src / main / webapp / login.html]. The above historical commit record query command can be a command provided by the version control system specifically for querying historical commit records. For example, in the SVN system, the above historical commit record query command can be svn log -v --stop-on-copy.

[0025] Step 103: Filter and analyze the historical commit record set to obtain the target version range.

[0026] In some embodiments, the aforementioned execution entity may perform filtering and analysis on the aforementioned historical commit record set to obtain the target version range.

[0027] In addressing the technical challenges mentioned above, the application scenario—a large-scale monolithic repository or distributed system development scenario in a highly compliant, intranet-isolated environment (e.g., core business system development in the military or highly regulated industries)—often presents the following technical issues: During version control system branch code review, the mixing of synchronous merge commits and feature development commits leads to a waste of computing resources as the computer system processes a large amount of irrelevant change data during code difference comparison and defect detection. Considering the following requirements for this application scenario: efficient utilization of computing resources, standardized and automated interaction with the version control system, and deep semantic analysis capabilities with zero source code leakage, we have decided to adopt the following solution: In some optional implementations of certain embodiments, the aforementioned execution entity may perform filtering and analysis on the aforementioned historical commit record set to obtain the target version range through the following steps: The first step is to parse the aforementioned historical commit record set to obtain a commit message text set and a changed file group set. In practice, the executing entity can read the "commit hash" and "commit message" field values ​​of each historical commit record in the historical commit record set, and merge these values ​​into a commit message text set. Then, the executing entity can read the "commit hash" and "changed file group" field values ​​of each historical commit record in the historical commit record set, and merge these values ​​into a changed file group set.

[0028] The second step is to extract semantic keywords from the aforementioned commit message text set to obtain a semantic keyword set. In practice, the executing entity can use a keyword extraction algorithm to extract semantic keywords from the commit message text set to obtain the semantic keyword set corresponding to each historical commit record. The keyword extraction algorithm can be TF-IDF or TextRank.

[0029] The third step is to generate a semantic feature vector set based on the aforementioned semantic keyword set. In practice, the executing entity can convert the semantic keyword set into a semantic feature vector set by executing the Bag-of-Words (BOW) model algorithm. The semantic feature vector can be a fixed-dimensional numerical array. The Bag-of-Words algorithm can be a method that converts text into numerical vectors by statistically analyzing word frequencies.

[0030] The fourth step is to determine the statistical feature vector set of the aforementioned changed file groups. In practice, for each changed file group in the aforementioned changed file group set, the execution entity can perform the following operations: First, determine the proportion values ​​of different file types (such as .java, .py, .js) in the aforementioned changed file group, as the type proportion value group. Second, determine the number of lines of code added, deleted, or modified in each changed file in the changed file group, as the number of changed lines. Third, determine the number of times each changed file in the changed file group recurs within a preset time period, as the recurrence frequency of the changed file group. Fourth, concatenate the "commit hash" field value of the aforementioned changed file group, the aforementioned type proportion value group, the aforementioned number of changed lines, and the aforementioned recurrence frequency of the aforementioned changed file group to obtain the statistical feature vector of the changed file group. Finally, the statistical feature vectors of each changed file group are determined as the statistical feature vector set. The statistical feature vectors in the aforementioned statistical feature vector set include the type proportion value group, the number of changed lines, and the recurrence frequency of the changed file group.

[0031] The fifth step involves performing a commit type probability analysis on the historical commit record set based on the aforementioned semantic feature vector set and statistical feature vector set, resulting in a set of type probability values. In practice, the executing entity can concatenate semantic feature vectors and statistical feature vectors with the same "commit hash" field value from the aforementioned semantic feature vector set and statistical feature vector set to obtain a concatenated feature vector set for each historical commit record. Then, this concatenated feature vector set is input into a pre-trained commit classification model to generate type probability values ​​for each historical commit record, resulting in a set of type probability values. The type probability values ​​in this set can represent the probability of a branch creation commit, a synchronization merge commit, or a feature development commit. The pre-trained commit classification model can be a pre-trained random forest model. As an example, the executing entity can collect at least one labeled historical commit record from the historical codebase as a training dataset. This labeled historical commit record contains raw data such as commit descriptions and changed file groups, and has been pre-labeled with actual commit type tags (e.g., "branch creation commit," "synchronization merge commit," "feature development commit"). The pre-trained commit classification model can be pre-trained using this training dataset.

[0032] Step 6: Based on the aforementioned type probability value set, assign a dominant type label to each historical commit record in the aforementioned historical commit record set, resulting in a tagged commit record set. In practice, the executing entity can determine the category with the highest probability value among the type probability values ​​corresponding to each historical commit record in the aforementioned historical commit record set as the dominant type label, and add the dominant type label to the historical commit record to obtain the tagged commit record set. The tagged commit record set can be a dataset formed by adding the "dominant type label" metadata attribute to each historical commit record in the aforementioned historical commit record set.

[0033] Step 7: Delete the tag submission records that represent synchronous merging submissions from the above tag submission record set to obtain the denoised tag submission record set.

[0034] Step 8: Extract the target version range corresponding to the aforementioned denoising tag submission record set. In practice, the executing entity can read the "version number" field value of each denoising tag submission record in the aforementioned denoising tag submission record set, and use the smallest "version number" field value as the range start point and the largest "version number" field value as the range end point. The aforementioned range start point and the aforementioned range end point are determined as the target version range. As an example, the aforementioned target version range can be represented as r_start:r_end.

[0035] The first to eighth steps and related content described above, as an inventive point of this disclosure, solve the technical problem that "in version control system branch code review, due to the mixing of synchronous merge commits and feature development commits, the computer system needs to process a large amount of irrelevant change data when performing code difference comparison and defect detection, resulting in a waste of computing resources." Factors leading to this waste of computing resources are often as follows: In version control system branch code review, due to the mixing of synchronous merge commits and feature development commits, the computer system needs to process a large amount of irrelevant change data when performing code difference comparison and defect detection, resulting in a waste of computing resources. Solving these factors can achieve the effects of determining the scope of code review, eliminating synchronous noise interference, and saving computing resources. To achieve this effect, firstly, the aforementioned historical commit record set is parsed to obtain a commit description text set and a change file set. This provides structured, machine-readable raw data input for subsequent feature analysis. Secondly, semantic keywords are extracted from the aforementioned commit description text set to obtain a semantic keyword set. This allows for the automatic extraction of key features that characterize the commit intent (such as "fix," "merge," "add feature") from natural language descriptions, providing a semantic basis for type recognition. Third, based on the aforementioned semantic keyword set, a semantic feature vector set is generated. This converts unstructured text keywords into numerical feature vectors, enabling them to be processed and calculated by subsequent machine learning models. Fourth, the statistical feature vector set of the aforementioned changed file group set is determined. This quantifies the objective characteristics of each commit at the file operation level (such as type proportion value groups), providing a statistical basis for type identification. Fifth, based on the aforementioned semantic feature vector set and statistical feature vector set, a commit type probability analysis is performed on the aforementioned historical commit record set to obtain a type probability value set. This combines semantic and statistical features, allowing machine learning models to intelligently determine the probability that each commit belongs to types such as "branch creation," "synchronous merge," or "feature development," achieving highly accurate automated classification. Sixth, according to the aforementioned type probability value set, a dominant type label is assigned to each historical commit record in the aforementioned historical commit record set, resulting in a tagged commit record set. This assigns a clear type identifier to each commit, clearly structuring the entire branch history according to the commit intent. Seventh, the tagged commit records representing synchronous merge commits are deleted from the aforementioned tagged commit record set, resulting in a denoised tagged commit record set. Therefore, before performing core code review and analysis, noisy commits generated by purely synchronous operations that do not contain new business logic can be automatically filtered out. Eighth, extract the target version range corresponding to the above-mentioned denoised commit record set. Thus, based on the filtered valid commits, the precise version number range requiring in-depth code difference analysis and defect detection can be determined, providing accurate input boundaries for all subsequent analysis steps.Ultimately, this approach achieves the goals of defining the scope of code review, eliminating synchronization noise interference, and saving computing resources.

[0036] Step 104: Generate code difference data based on the target version range.

[0037] In some embodiments, the aforementioned execution entity may generate code difference data based on the aforementioned target version range.

[0038] In some optional implementations of certain embodiments, the aforementioned execution entity may generate code difference data based on the aforementioned target version range through the following steps: The first step is to send a first difference generation command to the version control system to obtain a list of files that have changed within the target version range. This file list includes the paths and types of the changed files. The first difference generation command can be a command or function call provided by the version control system for quickly obtaining a list of files that have changed between two versions. The first difference generation command can take the target version range as input and the file list as output. For example, in SVN, the first difference generation command could be `svndiff -r r_start:r_end –summarize`, where `start:r_end` represents the target version range.

[0039] The second step involves sending a second diff generation command to the version control system based on the aforementioned file list to obtain the code modifications. This second diff generation command can be a specific command or function call provided by the version control system, used to obtain line-level differences in a specified file between two versions. The second diff generation command can take the target version range and the file paths included in the file list as input parameters. The output of the second diff generation command can include line-level changes such as additions, deletions, and modifications to the code. For example, in an SVN system, the second diff generation command could be `svn diff -r r_start:r_end`.<file_path> file_path can represent the file path mentioned above.

[0040] The third step is to associate and merge the aforementioned file list and code modification details to generate code difference data. In practice, the executing entity can create a structured data object (e.g., a JSON object) and populate it with the file paths, change types, and corresponding code modification details from the file list, according to file names. This will yield code difference data including the paths, change types, and corresponding code modification details for each file.

[0041] Step 105: Perform deterministic defect detection on the code difference data to obtain the first defect record set.

[0042] In some embodiments, the execution entity can perform deterministic defect detection on the code difference data to obtain a first defect record set. In practice, the execution entity can read a preset defect detection rule set from storage. Then, the code difference data is compared with the preset defect detection rule set to generate the first defect record set. The preset defect detection rule set can be a pre-defined set of conditions used for automatically scanning code difference data and identifying deterministic defects. For example, the preset defect detection rule set can be the rule base of a static code analysis tool (e.g., SonarQube). The preset defect detection rule set can include a first detection rule, a second detection rule, and a third detection rule. The first detection rule can be a high-priority rule for detecting first defects that directly affect system stability or availability. The first defect can include dead code, unremoved debug logs, syntax errors, undefined references, null pointer exception risks, and unreleased database connections. The second detection rule can be a medium-priority rule for detecting second defects that affect code maintainability, scalability, or performance. The second defect can include duplicate code, missing error handling logic, boundary condition defects, uncleared timers, and uncancelled global subscriptions. The aforementioned third detection rule can be a low-priority rule used to detect third defects that violate coding standards or affect code readability. These third defects may include inconsistent coding styles, non-standard naming, the presence of magic numbers, excessive function length, and missing comments. The first defect record in the aforementioned first defect record set can be a structured data object (such as a JSON object or an XML document). The first defect record in the aforementioned first defect record set may include a defect description, the specific location of the defect in the code, and the severity level of the violated rule. As an example, the aforementioned first defect record could be: {"id":"RC-20260501-001","rule_id":"HIGH_001","description":"Detected an unremoved debug log statement: console.log(debugInfo);","location":{"file_path":" / src / main / service / OrderProcessor.java","start_line":156,"start_column":5,"end_line":156,"end_column":30},"severity":"HIGH"}.

[0043] Step 106: Perform semantic analysis on the code difference data to obtain the second defect record set.

[0044] In some embodiments, the aforementioned executing entity can perform semantic analysis on the aforementioned code difference data to obtain a second set of defect records. The aforementioned local large language model can be a large language model deployed within an enterprise or organization's internal network environment, not directly connected to the public network, and whose model weights and services are internally controlled. As an example, the aforementioned local large language model can be a large language model trained based on the Transformer architecture and independently deployed in an enterprise intranet environment. As an example, the aforementioned local large language model can be an LLaMA-2 model or a ChatGLM-6B model pre-trained on a large-scale public text corpus (such as Common Crawl, Wikipedia, etc.).

[0045] In some optional implementations of certain embodiments, the aforementioned execution entity may perform semantic analysis on the aforementioned code difference data to obtain a second defect record set through the following steps: The first step is to combine the code difference data and the first defect record set mentioned above into structured input data. This structured input data can be a JSON string or an XML document.

[0046] Optionally, the aforementioned execution entity can combine the code difference data and the first defect record set into structured input data through the following sub-steps: Sub-step one involves retrieving the associated code contexts with data relationships from the version control system based on the aforementioned code difference data. In practice, the executing entity can use static code analysis tools to extract the associated code contexts representing data relationships such as function calls, variable references, and class inheritance from the code difference data. These static code analysis tools can be SonarQube, Checkstyle, or PMD.

[0047] Sub-step two involves serializing and combining the aforementioned associated code context and the first defect record set to obtain structured input data. In practice, the executing entity can arrange the aforementioned associated code context and the first defect record set into JSON string format to obtain structured input data.

[0048] The second step involves inputting the structured input data into the local large language model, and requiring the model to output a JSON object conforming to predefined constructive prompts as the initial semantic analysis text set. These predefined constructive prompts can be instruction templates embedded in the input text, used to constrain the model's output format and content structure. For example, the predefined constructive prompts could be: "Please analyze the following code changes and output the analysis results in JSON format. The output must contain an array named 'defects', where each element is an object containing the following fields: 'defect_type' (string, values ​​are 'resource_leak', 'null_pointer', 'logic_error', or 'design_flaw'), 'severity' (string, values ​​are 'HIGH', 'MEDIUM', or 'LOW'), 'location' (string, describing the file and line number where the defect is located), 'description' (string, briefly describing the defect), and 'suggestion' (string, optional, providing a repair suggestion). No other content should be output." The preliminary semantic analysis text in the aforementioned preliminary semantic analysis text set can be a string directly output by the local large language model, containing descriptions of potential logical risks to code modifications, corrections of design defects, and suggestions for improvement. As an example, the aforementioned preliminary semantic analysis text can be represented as: {"defects":[{"defect_type":"resource_leak","severity":"HIGH","location":"DataProcessor.java:45","description":"The close() method of the DataSource object will not be called when getConnection() returns null","suggestion":"Declare the DataSource object in try-with-resources"}]}.

[0049] The third step involves standardizing the format of the initial semantic analysis text set to obtain a second defect record set. In practice, the executing entity can extract the `defects` array from each initial semantic analysis text in the initial semantic analysis text set and map each element in the array to a structured data object (i.e., a JSON object containing fields such as description, location, and severity) with the same format as the first defect record, thus obtaining the second defect record set. The second defect records in the second defect record set can be JSON objects or XML documents. The second defect records in the second defect record set can include a defect description, the specific location of the defect in the code, and the severity level of the violated rule.

[0050] Step 107: Merge and classify the first defect record set and the second defect record set to obtain a defect record list, and generate a structured analysis report based on the defect record list.

[0051] In some embodiments, the execution entity may fuse and classify the first defect record set and the second defect record set to obtain a defect record list, and generate a structured analysis report based on the defect record list.

[0052] In some optional implementations of certain embodiments, the execution entity may perform the following steps to fuse and classify the first defect record set and the second defect record set to obtain a defect record list, and generate a structured analysis report based on the defect record list: The first step involves merging and deduplicating the first and second defect record sets to obtain a deduplicated defect record set. In practice, the executing entity can merge the first and second defect record sets to obtain a merged defect record set. Next, a hash algorithm is used to identify defect records in the merged defect record set that have the same location and the same defect description; these are considered duplicate defect records. Then, all duplicate defect records in the merged defect record set are deleted to obtain the deduplicated defect record set. For example, the hash algorithm used could be SHA-256.

[0053] The second step involves merging the deduplication defect record set using multi-source information to obtain a merged defect record set. In practice, the executing entity can concatenate deduplication defect records pointing to the same file in the aforementioned deduplication defect record set into a single defect record, thus obtaining a merged defect record set. For example, deduplication defect records pointing to the same file in the aforementioned deduplication defect record set could be deduplication defect records with the same "location" field. As an example, the executing entity can extract each deduplication defect record with the same "location" field from the aforementioned deduplication defect record set. Then, the contents of the "description" field of each of the aforementioned deduplication defect records are concatenated, and the contents of the "suggestion" field of each of the aforementioned deduplication defect records are concatenated to obtain a merged defect record set. As an example, deduplication defect record A and deduplication defect record B could be deduplication defect records with the same "location" field. Deduplication defect record A could be {"description": "May have division by zero error", "suggestion": "Add division by non-zero check"}. The deduplication defect record B could be {"description": "Variable 'divisor' comes from user input and is not validated, causing a security risk in the calculation of line 15", "suggestion": "Add input validation and exception handling"}. The merging defect record could be {"description": "Rule detection found: There may be a division by zero error. Furthermore, semantic analysis indicates that variable 'divisor' comes from user input and is not validated, causing a security risk in the calculation of line 15.", "suggestion": ["Add division by non-zero check", "Add input validation and exception handling"]}.

[0054] The third step involves performing a unified hierarchical mapping process on the aforementioned merged defect record set based on a preset cross-source hierarchical mapping rule set, resulting in a categorized record set. In practice, the execution entity can iterate through each merged defect record in the aforementioned merged defect record set and query each merged defect record in the preset cross-source hierarchical mapping rule set to generate categorized record labels for each merged defect record. Then, corresponding categorized record labels are added to each merged defect record in the aforementioned merged defect record set to obtain the categorized record set. The categorized record labels include Blocker, Major, Minor, and Innocent. The preset cross-source hierarchical mapping rule set can be a set of transformation rules that defines how different detection sources and original severity levels correspond to a unified severity system. As an example, the preset cross-source hierarchical mapping rule set may include: Source: rule_engine, Original Severity: CRITICAL, Categorized Record Label: Blocker; Source: rule_engine, Original Severity: HIGH, Categorized Record Label: Major. Source: ai_model, Original level: HIGH, Category record label: Medium anomaly level.

[0055] The fourth step is to add a source identifier to each category record in the above category record set to obtain an identifier record set. For example, the source identifier can be represented as "source":"rule_engine" or "source":"ai_model".

[0056] The fifth step involves generating confidence weight identifiers for each identifier record in the aforementioned identifier record set, and binding each confidence weight identifier to its corresponding identifier record to obtain a weight record set. In practice, the executing entity can generate confidence weight identifiers "confidence_weight" for each identifier record in the aforementioned identifier record set according to preset confidence weight rules, and bind each confidence weight identifier to its corresponding identifier record to obtain a weight record set. As an example, the aforementioned preset confidence weight rules can be represented as: {"rule_engine":0.9, "ai_model":0.6}.

[0057] Step 6: Perform conflict resolution on the aforementioned set of weighted records to obtain a list of defective records. In practice, the executing entity can use preset conflict resolution rules to perform conflict resolution on weighted records in the aforementioned set that have the same "location" field but different "severity" fields, thus obtaining a list of defective records. These preset conflict resolution rules can be a set of conditional judgments and execution logic applied sequentially by a computer program. As an example, the preset conflict resolution rules may include: First, comparing the confidence weight labels of each weighted record and retaining the weighted records with the confidence weight labels. Second, in response to the fact that the classification record label of the weighted record source "rule_engine" is at the blocking level, setting the classification record label of the weighted record as "defective" to the blocking level.

[0058] Step 7: Perform structured processing on the above defect record list to obtain a structured analysis report. In practice, the executing entity can determine the total number of defects and the number of defects at each level in the above defect record list. Then, create a JSON object and populate it with the total number of defects, the number of defects at each level, and the above defect record list to obtain the structured analysis report.

[0059] Step 108: Based on the structured analysis report, perform code merging access control operations for the aforementioned target branch.

[0060] In some embodiments, the aforementioned execution entity may perform code merging access control operations on the aforementioned target branch based on the aforementioned structured analysis report.

[0061] In addressing the technical challenges mentioned above, the application scenario—a large-scale monolithic warehouse or distributed system development scenario in a highly compliant, intranet-isolated environment (e.g., core business system development in the military or highly regulated industries)—often presents the following technical issues: Existing solutions, when applying review results to access control, typically rely solely on a simple count of defects or a mechanical judgment based on the highest severity level, lacking a comprehensive quantitative assessment of the overall risk of defects. This leads to misjudgments or process blockages in the interception rules, potentially causing continuous integration system build failures, test environment instability, or even runtime malfunctions. Repairing these issues consumes significant additional computing, storage, and network resources. Considering the following requirements for this application scenario: numerical and computable risk indicators, adaptive decision-making criteria, and automated cross-system management, we have decided to adopt the following solution: In some optional implementations of certain embodiments, the aforementioned execution entity may perform a code merging access control operation targeting the aforementioned target branch based on the aforementioned structured analysis report through the following steps: The first step is to generate a set of defect information triples based on the structured analysis report described above. In practice, the executing entity can parse the "issues" field value representing the list of defect records in the structured analysis report, and for each defect record included in the "issues" field value, perform the following operations: extract the "severity" field value representing the severity level, the "source" field value representing the source identifier, and the "confidence_weight" field value representing the confidence weight, thus obtaining the defect information triples. The defect information triples for each defect record are then defined as the defect information triple set. The defect information triples in this set can include the severity level, source identifier, and confidence weight.

[0062] The second step involves converting the severity levels included in each defect information triplet in the aforementioned defect information triplet set into severity weight values, resulting in a set of severity weight values. In practice, the executing entity can query a severity weight mapping table for each severity level included in the defect information triplet set to obtain the set of severity weight values. This severity weight mapping table can be a pre-defined key-value data structure used to map severity levels to severity weight values. For example, the severity weight mapping table can be represented as: BLOCKER=10, MAJOR=5, MINOR=2, INFO=0.5.

[0063] The third step involves determining the comprehensive outlier for each defect record based on the aforementioned set of grade weight values ​​and the source identifier and confidence weight included in each defect information triplet in the aforementioned defect information triplet set, thus obtaining a comprehensive outlier set. The comprehensive outlier can be represented as the product of the grade weight value, the confidence weight, and the source correction coefficient. The source correction coefficient can be a preset mapping value for the aforementioned source identifier; for example, the source correction coefficient for the source identifier `rule_engine` is 1.0, and the source correction coefficient for the source identifier `ai_model` is 0.8.

[0064] The fourth step is to determine the overall quality value based on the above-mentioned comprehensive outlier set, the number of defect records in the above-mentioned defect record list, and the number of lines of code changes. The overall quality value can be expressed as: Baseline Score - (Sum of Comprehensive Outliers / (Number of Lines of Code Change / Scaling Factor + Number of Defect Records)). The baseline score can represent the highest quality, for example, it could be 100. The scaling factor can be used to adjust the influence weight of the number of lines of code changes, for example, it could be 10. The sum of comprehensive outliers can be the sum of all comprehensive outliers in the above-mentioned comprehensive outlier set. As an example, comprehensive outlier set = [9.5, 2.8], number of defect records = 2, number of lines of code changes = 150, overall quality value = 100 - ((9.5 + 2.8) / (150 / 10 + 2)) ≈ 100 - 0.72 = 99.28.

[0065] The fifth step is to determine the dynamic quality threshold based on the historical merge data of the target branch. In practice, the executing entity can query the historical merge data of the target branch and determine the average of the overall quality values ​​of the historical merge data as the dynamic quality threshold. As an example, the overall quality values ​​of the historical merge data can be represented as [98.5, 99.0, 97.8, 99.5, 98.2, 96.9, 99.1, 98.7, 97.5, 99.3], and the dynamic quality threshold can be 98.45.

[0066] Step 6: In response to the overall quality score being lower than the dynamic quality threshold, a merge blocking instruction is generated. This merge blocking instruction can be a structured control command data object. It may include the instruction type (BLOCK_MERGE), target branch information, blocking reason (e.g., "Overall quality score 97.5 is below the dynamic threshold 97.69"), and a timestamp. For example, the merge blocking instruction could be represented as: {"action": "BLOCK_MERGE", "branch": "feature / xxx", "reason": "Overall quality score (97.5) isbelow the dynamic threshold (97.69)", "report_id": "REPORT-20231027-001"}.

[0067] Step 7: Send the merge blocking command to the version control system to execute the code merge access control operation for the target branch. In practice, the executing entity can send the merge blocking command to the version control system via an API (such as a REST API) to execute the code merge access control operation for the target branch.

[0068] The aforementioned steps one through seven and related content, as an inventive point of this disclosure, solve the technical problem that "existing solutions, when applying review results to access control, typically rely solely on a simple count of defects or the highest severity level for mechanical judgment, lacking a comprehensive quantitative assessment of the overall risk of defects. This leads to misjudgments in interception rules or process blockages, potentially causing continuous integration system build failures, test environment instability, or even runtime malfunctions. Repairing these problems will consume a significant amount of additional computing, storage, and network resources." Factors leading to resource waste often include: Existing solutions, when applying review results to access control, typically rely solely on a simple count of defects or the highest severity level for mechanical judgment, lacking a comprehensive quantitative assessment of the overall risk of defects. This leads to misjudgments in interception rules or process blockages, potentially causing continuous integration system build failures, test environment instability, or even runtime malfunctions. Repairing these problems will consume a significant amount of additional computing, storage, and network resources. Solving these factors can avoid resource waste. To achieve this, firstly, based on the aforementioned structured analysis report, a defect information triplet set is generated. Therefore, the core decision attributes (severity level, source identifier, and confidence weight) of each defect record can be automatically extracted from the structured report and encapsulated into a unified, machine-processable data unit, providing standardized input for subsequent quantitative calculations and decisions. Second, the severity levels included in the aforementioned defect information triplets are quantified into level weight values, resulting in a set of level weight values. This allows qualitative descriptions such as "blocking level" and "high anomaly level" to be converted into specific numerical weights, enabling mathematical comparison and weighted calculation of defects of different severity levels, laying the foundation for building a quantitative assessment model. Third, based on the aforementioned level weight value set, the source identifier, and confidence weight included in the aforementioned defect information triplets, the comprehensive anomaly value of each defect record is determined, resulting in a comprehensive anomaly value set. Therefore, a composite risk score can be generated for each defect using a calculation formula that integrates defect severity, detection source credibility, and individual confidence level. This score more comprehensively and accurately reflects the potential technical risks posed by a single defect to the overall assessment. Fourth, based on the aforementioned comprehensive anomaly value set, the number of defect records in the aforementioned defect record list, and the number of lines of code changes, the overall quality value is determined. Therefore, the risks of all defects can be aggregated and normalized by combining them with the scale of this change (measured in lines of code), to calculate a single, comparable quantitative score characterizing the overall quality of this code change. This score comprehensively reflects the density and severity of defects. Fifth, based on the historical merged data of the aforementioned target branches, a dynamic quality threshold is determined. This allows the quality threshold to adaptively adjust based on the past quality performance of that branch or similar branches, rather than remaining fixed. This makes the access control standard more reasonable and fair, and can adapt to quality fluctuations at different stages of the project.Sixth, in response to the overall quality value falling below the dynamic quality threshold, a merge blocking instruction is generated. This allows for the automatic generation of structured control instructions containing clear decision-making criteria (such as quality scores and thresholds) when the quantitative evaluation model determines that the current code change quality is substandard, transforming the quality judgment into an executable action. Seventh, the merge blocking instruction is sent to the version control system to execute code merge access control operations for the target branch. This achieves automated technology integration between the review system and the version control system, directly and automatically changing the status of the target merge request (e.g., setting it to "blocked") through inter-system instruction calls, thus completing a full technical loop from intelligent analysis to process control without manual intervention. Ultimately, this avoids resource waste.

[0069] The above-described embodiments of this disclosure have the following beneficial effects: Through the version control method of this disclosure based on semantic analysis and intranet collaboration in a version control system, a series of methods are implemented to deeply interact with the version control system, intelligently process and analyze structured data, and ultimately achieve automated process control. This reduces the waste of computing resources and avoids software build failures or system security vulnerabilities. Specifically, the reasons for software build failures or system security vulnerabilities are that existing static analysis tools cannot understand the semantics of code changes in a specific version context and project architecture, leading to the underreporting of deep-seated technical risks such as circular dependency introduction, interface contract violation, and resource leakage patterns. In distributed version control systems, due to the lack of an automated code change impact analysis mechanism deeply associated with version history before branch merging, low-quality or conflict-risk code is merged into the main branch. After the problematic code is merged, subsequent builds frequently fail, wasting the CPU, memory, and bandwidth resources of the build server, further leading to specific technical failures such as software build failures, runtime anomalies, or system security vulnerabilities. Based on this, some embodiments of the version control system branch control method based on semantic analysis and intranet collaboration disclosed herein first invoke the information query command of the version control system to obtain the Uniform Resource Locator (URL) of the target branch. This provides a unique and accurate review target location for all subsequent operations, constructing a standardized review context. Second, based on the aforementioned URL, the historical commit record set of the target branch is extracted. This obtains structured and complete branch evolution history data, providing a data foundation for subsequent intelligent analysis. Then, the historical commit record set is filtered and analyzed to obtain the target version range. This eliminates noise data introduced by synchronous merging commits, solving the technical problem of redundant review scope. Next, based on the aforementioned target version range, code difference data is generated. This generates structured and accurate code change details data, providing high-quality input for subsequent rule detection and semantic depth analysis, avoiding invalid calculations. Then, deterministic defect detection is performed on the code difference data to obtain a first defect record set. This detects all defects in the code that violate preset coding standards and deterministic defect patterns (such as syntax errors and resource leaks). Subsequently, semantic analysis is performed on the code difference data to obtain a second defect record set. Therefore, while ensuring the security of source code data remaining within the internal network, this approach can deeply identify semantic-level issues such as logical contradictions, design flaws, and potential risks in the code, compensating for the shortcomings of rule-based detection. Furthermore, the aforementioned first and second defect record sets are fused and hierarchically processed to obtain a defect record list, and a structured analysis report is generated based on this list. This allows for the collaborative integration of multi-source detection results, generating standardized, clearly defined, and machine-readable review conclusions that can directly drive subsequent automated processes through unified hierarchical classification and conflict resolution.Finally, based on the structured analysis report above, code merging access control operations are performed on the target branches. This automates the execution of code quality access control, creating a complete technical control loop from code review to merging decisions. This implementation reduces wasted computing resources and avoids software build failures or system security vulnerabilities.

[0070] Continue to refer to Figure 2 As a response to the above Figure 1 The implementation of the method shown in this disclosure provides some embodiments of a branch control device for a version control system based on semantic analysis and intranet collaboration. These device embodiments are similar to... Figure 1 Corresponding to the method embodiments shown, the device can be specifically applied to various electronic devices.

[0071] like Figure 2 As shown, a branch control device 200 of a version control system based on semantic analysis and intranet collaboration in some embodiments includes: a calling unit 201, an extraction unit 202, a filtering and analysis unit 203, a generation unit 204, a detection unit 205, a semantic analysis unit 206, a processing unit 207, and an execution unit 208. Specifically, the calling unit 201 is configured to invoke the information query command of the version control system to obtain the Uniform Resource Locator (URL) of the target branch; the extraction unit 202 is configured to extract the historical commit record set of the target branch based on the URL; the filtering and analysis unit 203 is configured to perform filtering and analysis on the historical commit record set to obtain the target version range; the generation unit 204 is configured to generate code difference data based on the target version range; the detection unit 205 is configured to perform deterministic defect detection on the code difference data to obtain a first defect record set; the semantic analysis unit 206 is configured to perform semantic analysis on the code difference data to obtain a second defect record set; the processing unit 207 is configured to perform fusion and hierarchical processing on the first and second defect record sets to obtain a defect record list, and generate a structured analysis report based on the defect record list; and the execution unit 208 is configured to perform code merging access control operations on the target branch based on the structured analysis report.

[0072] It is understandable that the units described in the device 200 are related to the reference. Figure 1 The steps in the described method correspond to each other. Therefore, the operations, features, and beneficial effects described above for the method also apply to the device 200 and the units contained therein, and will not be repeated here.

[0073] The following is for reference. Figure 3 It shows a schematic diagram of the structure of an electronic device 300 suitable for implementing some embodiments of the present disclosure. Figure 3The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments of this disclosure.

[0074] like Figure 3 As shown, the electronic device 300 may include a processing unit (e.g., a central processing unit, a graphics processing unit, etc.) 301, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 302 or a program loaded from a storage device 308 into a random access memory (RAM) 303. The RAM 303 also stores various programs and data required for the operation of the electronic device 300. The processing unit 301, ROM 302, and RAM 303 are interconnected via a bus 304. An input / output (I / O) interface 305 is also connected to the bus 304.

[0075] Typically, the following devices can be connected to I / O interface 305: input devices 306 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 307 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 308 including, for example, magnetic tapes, hard disks, etc.; and communication devices 309. Communication device 309 allows electronic device 300 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 3 An electronic device 300 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively. Figure 3 Each box shown can represent a device or multiple devices as needed.

[0076] In particular, according to some embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, some embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication device 309, or installed from storage device 308, or installed from ROM 302. When the computer program is executed by processing device 301, it performs the functions defined in the methods of some embodiments of this disclosure.

[0077] It should be noted that, in some embodiments of this disclosure, the computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium may be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In some embodiments of this disclosure, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In some embodiments of this disclosure, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0078] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet of Things), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future-developed networks.

[0079] The aforementioned computer-readable medium may be included within the aforementioned electronic device; or it may exist independently without being assembled into the electronic device. The aforementioned computer-readable medium carries one or more programs that, when executed by the electronic device, cause the electronic device to: invoke information query instructions of the version control system to obtain the Uniform Resource Locator (URL) of the target branch; extract the historical commit record set of the target branch based on the URL; perform filtering analysis on the historical commit record set to obtain a target version range; generate code difference data based on the target version range; perform deterministic defect detection on the code difference data to obtain a first defect record set; perform semantic analysis on the code difference data to obtain a second defect record set; perform fusion and hierarchical processing on the first and second defect record sets to obtain a defect record list, and generate a structured analysis report based on the defect record list; and perform code merging access control operations for the target branch based on the structured analysis report.

[0080] Computer program code for performing operations of some embodiments of this disclosure can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0081] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0082] The units described in some embodiments of this disclosure can be implemented in software or hardware. The described units can also be housed in a processor; for example, a processor can be described as including a calling unit, an extraction unit, a filtering and analysis unit, a generation unit, a detection unit, a semantic analysis unit, a processing unit, and an execution unit. The names of these units do not necessarily limit the unit itself; for example, a calling unit can also be described as "a unit that calls information query instructions from a version control system to obtain the Uniform Resource Locator (URL) of a target branch."

[0083] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), and so on.

[0084] The above description is merely a selection of preferred embodiments of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in the embodiments of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described inventive concept. For example, technical solutions formed by substituting the above-described features with (but not limited to) technical features with similar functions disclosed in the embodiments of this disclosure.

Claims

1. A branch control method for a version control system based on semantic analysis and intranet collaboration, characterized in that, include: Use the version control system's information query command to obtain the Uniform Resource Locator (URL) for the target branch; Based on the Uniform Resource Locator (URL), extract the historical commit record set of the target branch; The target version range is obtained by filtering and analyzing the historical commit record set. Based on the target version range, generate code difference data; Deterministic defect detection is performed on the code difference data to obtain a first defect record set; Semantic analysis is performed on the code difference data to obtain a second set of defect records; The first defect record set and the second defect record set are fused and classified to obtain a defect record list, and a structured analysis report is generated based on the defect record list; Based on the structured analysis report, a code merging access control operation is performed on the target branch.

2. The method according to claim 1, characterized in that, The step of generating code difference data based on the target version range includes: Send a first difference generation instruction to the version control system to obtain a list of files that have changed within the target version range, wherein the list of files includes the changed file paths and change types; Based on the file list, a second difference generation instruction is sent to the version control system to obtain the code modification content; The file list and the code modification content are associated and merged to generate code difference data.

3. The method according to claim 1, characterized in that, The semantic analysis of the code difference data yields a second set of defect records, including: The code difference data and the first defect record set are combined into structured input data; The structured input data is input into the local large language model to obtain a preliminary semantic analysis text set; The format standardization operation is performed on the preliminary semantic analysis text set to obtain the second defect record set.

4. The method according to claim 3, characterized in that, The step of combining the code difference data and the first defect record set into structured input data includes: Based on the code difference data, obtain the associated code contexts with data relationships from the version control system; The associated code context and the first defect record set are serialized and combined to obtain structured input data.

5. The method according to claim 1, characterized in that, The process of fusing and classifying the first defect record set and the second defect record set to obtain a defect record list, and generating a structured analysis report based on the defect record list, includes: The first defect record set and the second defect record set are merged and deduplicated to obtain a deduplicated defect record set. Perform a multi-source information merging operation on the deduplicated defect record set to obtain a merged defect record set; Based on a preset cross-source hierarchical mapping rule set, the merged defect record set is subjected to unified hierarchical mapping processing to obtain a classified record set; Add a source identifier to each category record in the category record set to obtain an identifier record set; A confidence weight identifier is generated for each identifier record in the identifier record set, and each confidence weight identifier is bound to the corresponding identifier record to obtain a weight record set; Perform conflict resolution on the weighted record set to obtain a list of defect records; The defect record list is structured to obtain a structured analysis report.

6. A branch control device for a version control system based on semantic analysis and intranet collaboration, characterized in that, include: The calling unit is configured to invoke the version control system's information query command to obtain the Uniform Resource Locator (URL) for the target branch; The extraction unit is configured to extract the historical commit record set of the target branch based on the Uniform Resource Locator; The filtering and analysis unit is configured to perform filtering and analysis on the set of historical submission records to obtain the target version range; The generation unit is configured to generate code difference data based on the target version range; The detection unit is configured to perform deterministic defect detection on the code difference data to obtain a first defect record set; A semantic analysis unit is configured to perform semantic analysis on the code difference data to obtain a second defect record set; The processing unit is configured to perform fusion and hierarchical processing on the first defect record set and the second defect record set to obtain a defect record list, and generate a structured analysis report based on the defect record list; The execution unit is configured to perform a code merging access control operation on the target branch based on the structured analysis report.

7. An electronic device, characterized in that, include: One or more processors; A storage device on which one or more programs are stored; When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1 to 5.

8. A computer-readable medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1 to 5.

Images