Software technical debt identification and quantification method and system based on version control log

Abstract

The present application relates to the technical field of computer software development and version control, and particularly relates to a software technical debt identification and quantification method and system based on version control logs. The method obtains version control logs containing commit records, commit parent node relationships, branch reference records, merge commit records, merge conflict records, code difference records, file renaming records and version tag records, constructs a merge propagation graph anchored by version tags and a code entity identity chain; generates a merge influence unit for a merge commit node within a version tag interval, identifies source branch introduction segments, conflict resolution segments, target branch coverage segments and pre-tag re-introduction segments on the same code entity identity chain; when the above segments are connected in the order of merge propagation edges and commit topologies, a version propagation closed loop technical debt event is generated and a technical debt quantification record is formed.

Description

Technical Field

[0001] This invention relates to the field of computer software development and version control technology, and in particular to a method and system for identifying and quantifying software technical debt based on version control logs. Background Technology

[0002] In application software development, version control systems are typically used to record the changes to software code across different commits, branches, merges, and release nodes. Common version control logs generally include commit records, commit parent-child relationships, branch reference records, merge commit records, merge conflict records, code difference records, file renaming records, and version tag records. By parsing version control logs, we can obtain historical changes to code files, merging information between branches, and records corresponding to release nodes. Therefore, version control logs are an important data source for code evolution analysis and software maintenance analysis in application software development.

[0003] Existing technologies utilize version control logs, code difference records, merge conflict records, or code comments to identify technical debt information that may exist during software code evolution. For example, the existing paper "Technical Debt of Software Projects Based on Merge Code Comments" discloses a technical solution for analyzing technical debt in software projects based on merge code comments. This solution primarily analyzes task-related comments appearing in the code after merge conflict resolution to determine whether there is information related to technical debt in the merge conflict resolution results. Such solutions typically use the text content in the merge conflict resolution results as the analysis object to extract clues related to technical debt from code comments.

[0004] However, in application software development scenarios involving multi-branch parallel development, frequent merging, and continuous releases, the changes in software code are often distributed across multiple commit nodes, branches, and release intervals. Analyzing solely based on code comments, single code differences, or local merge conflict records within a single commit node is insufficient to reflect the continuous changes in related code content across different branches and release stages. Especially when code file paths change, code content undergoes multiple adjustments before and after a merge, or related changes span different release nodes, existing analysis methods easily fragment the relevant historical record into multiple local events, thus affecting the continuous identification of technical debt.

[0005] Furthermore, existing version control log analysis methods typically focus on commit counts, file-level difference comparisons, merge conflict counts, or code comment content identification. Their processing targets are mostly concentrated on local changes within a single file, a single commit, or between adjacent commits. For the continuous evolutionary state formed by multiple commits, branch merging, conflict resolution, and version releases in application software development, existing methods still suffer from inconsistent identification granularity and insufficient correlation of historical records, making it difficult to reliably reflect the changes in the same related code content before and after cross-branch merging and version releases.

[0006] Therefore, existing technologies still have the following technical problems: how to identify and quantify the continuous evolution state of software code near the boundaries of cross-branch merging and version release based on version control logs generated during application software development. Summary of the Invention

[0007] To overcome the aforementioned technical deficiencies, the present invention aims to provide a method and system for identifying and quantifying software technical debt based on version control logs. This invention analyzes the version control logs of application software development projects, constructs a merge propagation graph anchored to version tags and a code entity identity chain, and identifies the continuous change relationships of merge conflict-related code segments within cross-branch merges and version tag intervals. This solves the problem of difficulty in identifying and quantifying technical debt events near cross-branch merges and version release boundaries.

[0008] This invention discloses a method for identifying and quantifying software technical debt based on version control logs for application software development, including:

[0009] Obtain the version control logs of the application software development project. The version control logs include commit records, commit parent node relationships, branch reference records, merge commit records, merge conflict records, code difference records, file renaming records, and version tag records. Among them, the commit records include the commit identifier and commit timestamp; the commit parent node relationships include the child commit identifier and the parent commit identifier; the branch reference records include the branch identifier and the commit identifier pointed to by the branch; the merge commit records include the merge commit identifier, the first parent commit identifier, and the second parent commit identifier; the merge conflict records include the conflict file path, the conflict block location, and the conflict resolution commit identifier; the code difference records include the code entity name, the code entity boundary location, the difference context, and the difference fragment; the file renaming records include the path before renaming and the path after renaming; and the version tag records include the version tag identifier and the tag anchor commit identifier.

[0010] Based on commit records, commit parent node relationships, branch reference records, merge commit records, and version tag records, a merge propagation graph anchored by version tags is constructed. The merge propagation graph includes commit nodes, merge commit nodes, branch nodes, version tag nodes, parent-child commit edges, branch pointing edges, tag anchoring edges, merge propagation edges, commit paths, and version tag intervals. The commit path is formed by connecting parent-child commit edges, and the commit topology order is determined by the parent-child commit edges. The version tag interval includes the starting version tag node and the ending version tag node.

[0011] Construct a code entity identity chain based on code difference records and file renaming records, and configure corresponding identifiers for commit nodes, branch nodes, version tag nodes, version tag ranges, merge propagation edges, and the code entity identity chain;

[0012] For merge commit nodes within the version tag range, determine the source branch, target branch, source branch parent commit node, target branch parent commit node, and merge result commit node based on the merge propagation edge, and determine the nearest common ancestor commit node of the source branch parent commit node and the target branch parent commit node to generate merge impact units;

[0013] Extract source branch introduction fragments and conflict resolution fragments from the same code entity identity chain within the merged impact unit;

[0014] On the commit path consisting of parent and child commit edges and located between the parent commit node of the target branch and the terminating version tag node in the version tag interval, identify the target branch covered fragment on the same code entity identity chain and the fragment introduced before the tag after the target branch covered fragment.

[0015] When the source branch introduces a fragment, the conflict resolution fragment, the target branch covers a fragment, and the fragment introduced before the tag is connected in the order of merge propagation edges and commit topology, a version propagation closed-loop technical debt event is generated, and a technical debt quantification record is generated based on the version propagation closed-loop technical debt event.

[0016] Preferably, constructing the merge propagation graph includes: generating commit identifiers from commit records as commit nodes; connecting the commit nodes corresponding to the parent commit identifiers in the commit parent node relationship with the commit nodes corresponding to the child commit identifiers in the commit parent node relationship to generate parent-child commit edges; generating branch identifiers from branch reference records as branch nodes; connecting the commit nodes corresponding to the branch-pointing commit identifiers with the branch nodes to generate branch-pointing edges; generating version tag identifiers from version tag records as version tag nodes; connecting the commit nodes corresponding to the tag-anchoring commit identifiers with the version tag nodes to generate tag-anchoring edges; and determining the set of commit nodes between two adjacent version tag nodes according to the commit topology as the version tag interval.

[0017] Preferably, generating a merge propagation edge includes: marking the commit node corresponding to the merge commit identifier in the merge commit record as the merge commit node; when the merge commit node has a first parent commit node corresponding to the first parent commit identifier and a second parent commit node corresponding to the second parent commit identifier, the first parent commit node is used as the target branch parent commit node, the second parent commit node is used as the source branch parent commit node, the target branch and the source branch are determined according to the branch nodes corresponding to the target branch parent commit node and the source branch parent commit node, and a merge propagation edge is generated from the source branch through the merge commit node to the target branch.

[0018] Preferably, constructing a code entity identity chain includes: generating path inheritance anchors based on the pre-rename path and post-rename path in the file renaming record; generating difference context anchors based on the difference context in the code difference record; generating code entity boundary anchors based on the code entity name and code entity boundary position in the code difference record; and connecting code entities whose path inheritance anchors, difference context anchors, and code entity boundary anchors all match into the same code entity identity chain.

[0019] Preferably, when constructing the code entity identity chain, if the renamed path in the same file renaming record corresponds to multiple candidate code entities, and the candidate code entities are code entities located in the renamed path, then the continuous matching segments between the difference context anchors of each candidate code entity and the difference context anchors of the code entities in the original path in the file renaming record are determined, and the candidate code entities whose continuous matching segments contain code entity boundary anchors are connected to the code entity identity chain where the code entities in the original path are located.

[0020] Preferably, generating the merge impact unit includes: taking the most recent common ancestor commit node as the benchmark, extracting the source branch difference set of the source branch parent commit node relative to the most recent common ancestor commit node, the target branch difference set of the target branch parent commit node relative to the most recent common ancestor commit node, and the merge result difference set of the merge result commit node relative to the source branch parent commit node and the target branch parent commit node, and mapping the source branch difference set, the target branch difference set, and the merge result difference set to the corresponding code entity identity chain.

[0021] Preferably, extracting the source branch introduction fragment includes: selecting the difference fragment associated with the code entity identity chain in the source branch difference set, excluding the difference fragment that also exists in the target branch difference set, and determining the retained difference fragment as the source branch introduction fragment.

[0022] Preferably, extracting conflict resolution fragments includes: generating a conflict fragment index based on the conflict file path, conflict block location, and conflict resolution commit identifier in the merge conflict record; selecting a difference fragment from the merge result difference set that matches the conflict fragment index and belongs to the same code entity identity chain as the fragment introduced by the source branch; and identifying the difference fragment as the conflict resolution fragment.

[0023] Preferably, identifying the target branch covered fragment includes: within the commit nodes located after the merge result commit node along the commit path of the target branch, searching for subsequent difference fragments that belong to the same code entity identity chain as the conflict resolution fragment; when the subsequent difference fragment replaces the code entity boundary anchor in the conflict resolution fragment with the corresponding code entity boundary anchor in the nearest common ancestor commit node or the target branch parent commit node that belongs to the same code entity identity chain as the conflict resolution fragment, the subsequent difference fragment is determined as the target branch covered fragment.

[0024] Preferably, identifying the pre-label re-introduced fragment includes: after the commit node corresponding to the target branch covered fragment and before the commit node corresponding to the terminating version tag node in the version tag interval, searching for a reproduced difference fragment that belongs to the same code entity identity chain as the source branch introduced fragment; when the reproduced difference fragment contains the code entity boundary anchor point in the source branch introduced fragment, the reproduced difference fragment is identified as the pre-label re-introduced fragment.

[0025] Preferably, generating a version propagation closed-loop technical debt event includes: binding the source branch introduction fragment, conflict resolution fragment, target branch coverage fragment, and tag-pre-introduction fragment to their respective commit nodes; determining the commit node corresponding to the target branch coverage fragment as the target branch coverage commit node; determining the commit node corresponding to the tag-pre-introduction fragment as the tag-pre-introduction commit node; and generating a version propagation closed-loop technical debt event when the commit nodes corresponding to the source branch introduction fragment, conflict resolution fragment, target branch coverage fragment, and tag-pre-introduction fragment are located in the same version tag range, belong to the same code entity identity chain, and the source branch parent commit node, merge result commit node, target branch coverage commit node, and tag-pre-introduction commit node are arranged in the commit topology order.

[0026] Preferably, the generation of a version propagation closed-loop technical debt event further includes: generating multi-anchor consistency check codes for the source branch introduction fragment, conflict resolution fragment, target branch coverage fragment, and tag-pre-introduction fragment respectively; the multi-anchor consistency check code is obtained by concatenating the version tag range identifier, code entity identity chain identifier, path inheritance anchor point digest, difference context anchor point digest, code entity boundary anchor point digest, and conflict fragment index and then hashing it using a preset hash function; when the multi-anchor consistency check codes corresponding to the source branch introduction fragment, conflict resolution fragment, target branch coverage fragment, and tag-pre-introduction fragment satisfy the consistency condition, and the conflict fragment index corresponding to the conflict resolution fragment is associated with the code entity identity chain where the source branch introduction fragment is located, the generation of a version propagation closed-loop technical debt event is confirmed.

[0027] In view of this, the present invention also provides a software technical debt identification and quantification system based on version control logs, comprising:

[0028] The log acquisition module is configured to acquire version control logs for the application software development project. Version control logs include commit records, commit parent-node relationships, branch reference records, merge commit records, merge conflict records, code difference records, file renaming records, and version tag records. Specifically, commit records include a commit identifier and commit timestamp; commit parent-node relationships include child commit identifiers and parent commit identifiers; branch reference records include a branch identifier and the commit identifier the branch points to; merge commit records include a merge commit identifier, first parent commit identifier, and second parent commit identifier; merge conflict records include the conflicting file path, conflict block location, and conflict resolution commit identifier; code difference records include code entity name, code entity boundary location, difference context, and difference fragment; file renaming records include the path before renaming and the path after renaming; and version tag records include version tag identifiers and tag-anchored commit identifiers.

[0029] The merge propagation graph construction module is configured to construct a merge propagation graph anchored by version tags based on commit records, commit parent node relationships, branch reference records, merge commit records, and version tag records. The merge propagation graph includes commit nodes, merge commit nodes, branch nodes, version tag nodes, parent-child commit edges, branch pointing edges, tag anchoring edges, merge propagation edges, commit paths, and version tag intervals. The commit path is formed by connecting parent-child commit edges, and the commit topology order is determined by the parent-child commit edges. The version tag interval includes the starting version tag node and the ending version tag node.

[0030] The code entity identity chain construction module is configured to build a code entity identity chain based on code difference records and file renaming records, and to configure corresponding identifiers for commit nodes, branch nodes, version tag nodes, version tag ranges, merge propagation edges and code entity identity chains.

[0031] The merge impact unit generation module is configured to determine the source branch, target branch, source branch parent commit node, target branch parent commit node, and merge result commit node based on the merge propagation edge for merge commit nodes within the version tag range, and to determine the nearest common ancestor commit node of the source branch parent commit node and the target branch parent commit node to generate merge impact units; the fragment identification module is configured to extract the source branch introduced fragment and conflict resolution fragment on the same code entity identity chain in the merge impact unit, and on the commit path formed by parent and child commit edges and located between the target branch parent commit node and the terminating version tag node in the version tag range, identify the target branch covered fragment and the tag-pre-introduced fragment located after the target branch covered fragment on the same code entity identity chain;

[0032] The closed-loop event generation module is configured to generate version propagation closed-loop technical debt events when fragments are introduced in the source branch, conflict resolution fragments, target branch overriding fragments, and tags are connected in the order of merge propagation edges and commit topology.

[0033] The quantitative record generation module is configured to generate quantitative records of technical debt based on version propagation closed-loop technical debt events.

[0034] Compared with existing technologies, the above technical solution has the following advantages:

[0035] 1. This invention constructs a merge propagation graph anchored by version tags by jointly analyzing commit records, commit parent node relationships, branch reference records, merge commit records, merge conflict records, code difference records, file renaming records, and version tag records generated during application software development. This enables the technical debt identification process to move beyond being limited to a single commit node, a single file difference, or code comment content. Instead, it can identify the continuous evolution status across branch merges and within version tag intervals based on the commit topology, branch merge relationships, and version release boundaries in the version control log, thereby improving the structure and traceability of software technical debt identification.

[0036] 2. This invention constructs a code entity identity chain and combines path inheritance anchors, difference context anchors, and code entity boundary anchors to continuously associate the corresponding relationships of the same code entity after file renaming, line number offset, code position movement, and multiple commit changes. This can reduce the problem of mismatched code entities caused by changes in file paths or code boundaries, and is conducive to improving the accuracy of code entity tracking in the cross-version control log analysis process.

[0037] 3. By generating merge impact units and identifying source branch introduction fragments, conflict resolution fragments, target branch overriding fragments, and tag-pre-introduction fragments on the same code entity identity chain, this invention can organize the change process of merge conflict-related code content within the source branch, target branch, merge commit node, and version tag range into a version propagation closed-loop technical debt event. This transforms the originally scattered local change records in multiple commit nodes into computable events with temporal and propagation relationships, thereby improving the completeness of technical debt event identification. Attached Figure Description

[0039] Figure 1 A schematic diagram of the overall process of the software technical debt identification and quantification method based on version control logs provided in an embodiment of the present invention;

[0040] Figure 2 A schematic diagram of the topology of the merge propagation graph for version tag anchoring provided in an embodiment of the present invention;

[0041] Figure 3 This is a schematic diagram of the state transition of the code entity identity chain provided in an embodiment of the present invention;

[0042] Figure 4 This is a schematic diagram of the merging influence unit and the difference fragment extraction process provided in an embodiment of the present invention;

[0043] Figure 5 A schematic diagram illustrating the temporal evolution of a version propagation closed-loop technical debt event provided for an embodiment of the present invention;

[0044] Figure 6 A schematic diagram of the functional modules of a software technical debt identification and quantification system based on version control logs provided in an embodiment of the present invention;

[0045] Figure 7 A schematic diagram of the hardware structure of an electronic device provided in an embodiment of the present invention;

[0046] Figure 8 This is a schematic diagram of the multi-anchor consistency check code generation process provided in an embodiment of the present invention;

[0047] Figure 9 This is a schematic diagram of the state transition of a dual-window closed-loop candidate state machine provided in an embodiment of the present invention. Detailed Implementation

[0049] The technical solution will be further described below with reference to the accompanying drawings and specific embodiments. The following embodiments are only for illustrating specific implementation methods and are not intended to limit the scope of protection. Where there is no conflict, the technical features in the following embodiments can be combined with each other.

[0050] This embodiment provides a method for identifying and quantifying software technical debt based on version control logs, applicable to application software development. (Refer to...) Figure 1 The method in this embodiment takes the version control log generated by the application software development project in the version control system as input. By constructing a merge propagation graph anchored by version tags, a code entity identity chain, and a merge impact unit, it identifies the continuous evolution state formed near the cross-branch merge and version release boundary, and generates a version propagation closed-loop technical debt event and technical debt quantitative record.

[0051] In this embodiment, the version control system can be a Git-based version control system, or any other version control system capable of recording commits, branches, merges, conflicts, code differences, file renaming, and version tags. The following explanation uses a Git-based version control system as an example; this example does not constitute a limitation on the type of version control system.

[0052] In this embodiment, the version control log includes commit records, commit parent node relationships, branch reference records, merge commit records, merge conflict records, code difference records, file renaming records, and version tag records. Specifically, commit records include a commit identifier and a commit timestamp; commit parent node relationships include child commit identifiers and parent commit identifiers; branch reference records include a branch identifier and a commit identifier pointed to by the branch; merge commit records include a merge commit identifier, a first parent commit identifier, and a second parent commit identifier; merge conflict records include the conflicting file path, the conflicting block location, and the conflict resolution commit identifier; code difference records include the code entity name, code entity boundary location, difference context, and difference fragment; file renaming records include the path before renaming and the path after renaming; and version tag records include a version tag identifier and a tag-anchored commit identifier.

[0053] In one specific implementation, the version control log can be represented using the data segments shown in Table 1 below.

[0054] Table 1 Example of Version Control Log

[0055] Submission Records Submission ID, Submission Timestamp c001, 2026-05-10T10:00:00Z Submit parent node relationship Child commit identifier, parent commit identifier c002, c001 Branch reference record Branch identifier, branch pointing to commit identifier feature-A, c104 Merge commit records Merge commit identifier, first parent commit identifier, second parent commit identifier M201, C150, C104 Merge conflict records Conflicting file path, conflict block location, conflict resolution commit identifier src / service / calc.py, line 45-62, m201 Code Difference Record Code entity name, code entity boundary location, difference context, difference fragment func_A, line 45-62, context_01, diff_01 File renaming records Path before renaming, path after renaming src / utils / old_calc.py, src / service / calc.py Version tag record Version tag identifier, tag anchored submission identifier Tag v2.0, c260

[0056] In this embodiment, a merge propagation graph anchored by version tags is first constructed based on commit records, commit parent node relationships, branch reference records, merge commit records, and version tag records. (Refer to...) Figure 2 The merge propagation graph includes commit nodes, merge commit nodes, branch nodes, version label nodes, parent-child commit edges, branch pointing edges, label anchoring edges, merge propagation edges, commit paths, and version label intervals. Commit paths are formed by connecting parent-child commit edges, and the commit topology order is determined by these edges. Version label intervals include the starting version label node and the ending version label node.

[0057] Specifically, commit identifiers in the commit records are generated as commit nodes. For example, commit identifiers c001, c002, c104, c150, m201, and c260 are each generated as commit nodes. Parent-child commit edges are generated by connecting the commit nodes corresponding to the parent commit identifiers and the child commit identifiers in the commit parent-child node relationship. For example, when the parent-child node relationship is child commit identifier c002 and parent commit identifier c001, the commit nodes corresponding to c001 and c002 are connected to generate parent-child commit edges. Branch identifiers in the branch reference records are generated as branch nodes, such as generating feature-A and main branch nodes; the commit nodes corresponding to the branch-pointing commit identifiers are connected to the branch nodes to generate branch-pointing edges. Version tag identifiers in the version tag records are generated as version tag nodes, and the commit nodes corresponding to the tag-anchoring commit identifiers are connected to the version tag nodes to generate tag-anchoring edges. For example, the commit node corresponding to Tag v1.0 is taken as the starting version tag node, the commit node corresponding to Tag v2.0 is taken as the ending version tag node, and the set of commit nodes arranged in the commit topology order between the two version tag nodes is determined as the version tag interval.

[0058] In this embodiment, for the merge commit identifier in the merge commit record, the commit node corresponding to the merge commit identifier is marked as the merge commit node. If the merge commit node m201 has a first parent commit identifier c150 and a second parent commit identifier c104, then the commit node corresponding to the first parent commit identifier c150 is taken as the target branch parent commit node, and the commit node corresponding to the second parent commit identifier c104 is taken as the source branch parent commit node. Based on the branch nodes corresponding to the target branch parent commit node and the source branch parent commit node, the target branch main and the source branch feature-A are determined respectively, and a merge propagation edge is generated from the source branch feature-A through the merge commit node m201 to the target branch main.

[0059] In this embodiment, a code entity identity chain is also constructed based on code difference records and file renaming records. (Refer to...) Figure 3 A code entity identity chain represents the continuous correspondence of the same code entity across different commit nodes, file paths, and code boundary locations. A code entity can be a file, function, class, or interface. The following explanation uses the function `func_A` as a code entity.

[0060] Specifically, path inheritance anchors are generated based on the pre-rename and post-rename paths in the file renaming record. A path inheritance anchor must include at least the pre-rename path, the post-rename path, and their corresponding commit nodes. Difference context anchors are generated based on the difference context in the code difference record. A difference context can consist of two lines of unchanged code text before and after the difference fragment; if there are fewer than two lines of unchanged code text before or after the difference fragment, the difference context is generated using the actual available unchanged code text. Code entity boundary anchors are generated based on the code entity name and code entity boundary position in the code difference record. A code entity boundary anchor must include at least the code entity name, code entity type, path, start line, and end line. Then, code entities with matching path inheritance anchors, difference context anchors, and code entity boundary anchors are connected into a single code entity identity chain.

[0061] In one specific implementation, the file renaming record shows that the file containing the function `func_A` has changed from `src / utils / old_calc.py` to `src / service / calc.py`. The system generates path inheritance anchors using the paths before and after the renaming, generates difference context anchors using the unchanged lines of code before and after the renaming of the function `func_A`, and generates code entity boundary anchors using the function name `func_A` and the start and end lines obtained from the abstract syntax tree parsing. If the function `func_A` was located between lines 45 and 62 before the renaming, and subsequently moved to lines 55 to 72 due to the insertion of new code, the system does not directly rely on the original line numbers, but instead combines the function name, the abstract syntax tree boundary, and the difference context anchors to redetermine its boundary position. Thus, the `func_A` before and after the renaming are connected into the same code entity identity chain, for example, identified as `chain_func_A_001`.

[0062] Table 2 Example of Code Entity Identity Chain Construction

[0063] File path src / utils / old_calc.py src / service / calc.py Path inheritance anchor Code Entity Name func_A func_A Code entity boundary anchors Code entity boundary position lines 45-62 line 55-72 Abstract Syntax Tree Boundary Difference Context context_before_01 / context_after_01 context_before_01 / context_after_01 Difference context anchor Code Entity Identity Chain chain_func_A_001 chain_func_A_001 All three types of anchor points are matched.

[0064] When multiple candidate code entities correspond to the renamed path in the same file renaming record, this embodiment determines the continuous matching segments between the difference context anchors of each candidate code entity and the difference context anchors of the code entities in the original path. Candidate code entities whose continuous matching segments contain code entity boundary anchors are then added to the code entity identity chain of the code entities in the original path. For example, if the renamed path src / service / calc.py contains both functions func_A and func_A_helper, and if both the preceding and following contexts of func_A match the func_A in the original path, and the continuous matching segment contains the code entity boundary anchor of func_A, then func_A in the renamed path is added to chain_func_A_001. If func_A_helper only has a similar name but its difference context anchors do not match, then it is not added to the code entity identity chain.

[0065] In a further embodiment, reference is made to... Figure 8 To mitigate the risk of mismatched code entities during file renaming, code movement, and conflict resolution, a multi-anchor consistency checksum can be generated for code entity identity chains within the same version tag range after the code entity identity chain is constructed. The multi-anchor consistency checksum is generated jointly by the version tag range identifier, code entity identity chain identifier, path inheritance anchor, difference context anchor, code entity boundary anchor, and conflict fragment index. It is used to verify whether source branch-introduced fragments, conflict-resolved fragments, target branch-overridden fragments, and tag-pre-introduced fragments are in the same verifiable continuous evolution chain.

[0066] Specifically, the multi-anchor consistency check code can be generated according to the following formula:

[0067]

[0068] in, This represents a multi-anchor consistency check code; Indicates the preset hash function; This indicates a field concatenation operation; Indicates the version tag range identifier; Indicates the identity chain identifier of the code entity; This represents a summary of the path inheritance anchor points; This represents a summary of the difference context anchors; Represents a summary of code entity boundary anchor points; Indicates the index of the conflicting fragment.

[0069] When generating a path inheritance anchor summary, the path before renaming, the path after renaming, and the corresponding commit node identifier can be concatenated and then input into a preset hash function; when generating a difference context anchor summary, the unchanged code text before and after the difference fragment can be normalized and then input into a preset hash function; when generating a code entity boundary anchor summary, the code entity name, code entity type, path, start line, and end line can be concatenated and then input into a preset hash function; when generating a conflict fragment index, the conflict file path, conflict block start line, conflict block end line, and conflict resolution commit identifier can be concatenated.

[0070] During the specific verification process, the system generates corresponding multi-anchor consistency check codes for the source branch import fragment, conflict resolution fragment, target branch overlay fragment, and tag-pre-introduced fragment. When the version tag range identifier, code entity identity chain identifier, path inheritance anchor point digest, and code entity boundary anchor point digest in the multi-anchor consistency check codes for the four types of fragments all meet the consistency condition, and the conflict fragment index corresponding to the conflict resolution fragment can be associated with the code entity identity chain where the source branch import fragment is located, the system confirms that these four types of fragments belong to the candidate link of the same version propagation closed-loop technical debt event. If the version tag range identifier or code entity identity chain identifier of any fragment is inconsistent, or the code entity boundary anchor point digest cannot correspond to the same code entity identity chain, the system will not include that fragment in the current candidate link.

[0071] Table 3. Example table of multi-anchor consistency check code fields.

[0072] Version tag range identifier Tag_v1.0_to_Tag_v2.0 Used to limit the version release range of the candidate link. Code Entity Identity Chain Identifier chain_func_A_001 Used to limit the code entity to which the candidate link belongs. Path Inheritance Anchor Summary path_hash_001 Generated from the original path and the renamed path Difference Context Anchor Summary context_hash_001 Generated from unchanged code text before and after the difference segment Code Entity Boundary Anchor Summary boundary_hash_001 Generated from code entity name, type, path, and boundary location. Conflict Fragment Index conflict_index_001 Generated from conflict file path, conflict block location and conflict resolution commit identifier Multi-anchor consistency check code anchor_code_001 The above fields are concatenated and then processed by a preset hash function to obtain the result.

[0073] In this embodiment, refer to Figure 4 For merge commit nodes within the version tag range, merge impact units are generated. Specifically, based on the merge propagation edge, the source branch, target branch, source branch parent commit node, target branch parent commit node, and merge result commit node are determined, and the nearest common ancestor commit node of the source branch parent commit node and the target branch parent commit node is determined. Taking the nearest common ancestor commit node c080 as the benchmark, the source branch difference set of the source branch parent commit node c104 relative to the nearest common ancestor commit node c080, the target branch difference set of the target branch parent commit node c150 relative to the nearest common ancestor commit node c080, and the merge result difference set of the merge result commit node m201 relative to the source branch parent commit node c104 and the target branch parent commit node c150 are extracted respectively. The source branch difference set, target branch difference set, and merge result difference set are then mapped to the corresponding code entity identity chain.

[0074] In this embodiment, the source branch difference set is denoted as source_diff_set_001, the target branch difference set is denoted as target_diff_set_001, and the merge result difference set is denoted as merge_result_diff_set_001. The source branch difference set includes the difference fragment diff_func_A_add of the function func_A introduced in the source branch feature-A; the target branch difference set includes the difference fragment diff_main_adjacent of other functions in the same file in the main branch; and the merge result difference set includes the difference fragment diff_func_A_resolved after conflict resolution in the merge commit node m201. All of the above difference sets are mapped to the code entity identity chain chain_func_A_001.

[0075] When extracting source branch introductory fragments, the difference fragments associated with the code entity identity chain are selected from the source branch difference set, and difference fragments that also exist in the target branch difference set are excluded. The retained difference fragments are then identified as source branch introductory fragments. For example, diff_func_A_add exists in source_diff_set_001 but not in target_diff_set_001, and is associated with chain_func_A_001; therefore, diff_func_A_add is identified as a source branch introductory fragment.

[0076] When extracting conflict resolution fragments, a conflict fragment index is generated based on the conflict file path, conflict block location, and conflict resolution commit identifier in the merge conflict record. Then, from the merge result difference set, the difference fragment that matches the conflict fragment index and belongs to the same code entity identity chain as the fragment introduced in the source branch is selected and identified as the conflict resolution fragment. The conflict fragment index can consist of the conflict file path, the start line of the conflict block, the end line of the conflict block, and the conflict resolution commit identifier.

[0077] Specifically, merging conflict records can include the following conflict text fragments:

[0078] <<<<<<< HEAD

[0079] return legacy_calculate(input_value)

[0080] =======

[0081] return func_A(input_value, safety_check=True)

[0082] >>>>>>> Feature-A

[0083] When parsing the above conflict markers, the system identifies the code between "<<<<<<< HEAD" and "=======" as the target branch code area, and the code between "=======" and ">>>>>>> feature-A" as the source branch code area. It then combines the conflict file path src / service / calc.py, the conflict block start line (line 45), the conflict block end line (line 62), and the conflict resolution commit identifier m201 to generate a conflict fragment index conflict_index_001. If diff_func_A_resolved in the merge result difference set matches conflict_index_001, and both diff_func_A_add (introduced from the source branch) belong to chain_func_A_001, then diff_func_A_resolved is determined as the conflict resolution fragment.

[0084] In this embodiment, within the commit nodes following the merge result commit node m201 along the commit path of the target branch main, subsequent difference fragments belonging to the same code entity identity chain as the conflict resolution fragment are searched. When a subsequent difference fragment replaces the code entity boundary anchor in the conflict resolution fragment with the corresponding code entity boundary anchor in the nearest common ancestor commit node or the target branch parent commit node, which belongs to the same code entity identity chain as the conflict resolution fragment, the subsequent difference fragment is determined as the target branch coverage fragment. For example, in commit node c230, if the function func_A is modified and restored to the processing logic at the corresponding function boundary in the target branch parent commit node c150, then the difference fragment diff_func_A_cover in commit node c230 is determined as the target branch coverage fragment.

[0085] When re-introducing fragments before being labeled, after the commit node corresponding to the fragment covered by the target branch and before the commit node corresponding to the terminating version label node in the version label range, a reproducible difference fragment belonging to the same code entity identity chain as the fragment introduced from the source branch is searched. If the reproducible difference fragment contains a code entity boundary anchor point from the fragment introduced from the source branch, it is identified as a re-introduced fragment before being labeled. For example, in commit node c250, if the developer re-adds the `func_A` processing logic from the source branch `feature-A` to the target branch `main`, and this difference fragment contains a code entity boundary anchor point from the fragment introduced from the source branch, then `diff_func_A_readd` in commit node c250 is identified as a re-introduced fragment before being labeled.

[0086] Reference Figure 5In this embodiment, the source branch introduction fragment, conflict resolution fragment, target branch coverage fragment, and tag-pre-introduction fragment are each bound to their corresponding commit nodes. The commit node corresponding to the target branch coverage fragment is determined as the target branch coverage commit node, and the commit node corresponding to the tag-pre-introduction fragment is determined as the tag-pre-introduction commit node. If the commit nodes corresponding to the source branch introduction fragment, conflict resolution fragment, target branch coverage fragment, and tag-pre-introduction fragment are located in the same version tag range, belong to the same code entity identity chain, and the source branch parent commit node, merge result commit node, target branch coverage commit node, and tag-pre-introduction commit node are arranged in the commit topology order, then a version propagation closed-loop technical debt event is generated.

[0087] Table 4 shows an example of how a closed-loop technical debt event can be generated:

[0088] Table 4: Examples of Version Propagation Closed-Loop Technology Debt Event Generation

[0089] Source branch introduction diff_func_A_add c104 feature-A chain_func_A_001 Conflict resolution diff_func_A_resolved m201 main chain_func_A_001 Target branch coverage diff_func_A_cover c230 main chain_func_A_001 Re-introducing before the tag diff_func_A_readd c250 main chain_func_A_001 Termination version tag node Tag v2.0 c260 main —

[0090] In another specific implementation, refer to Figure 9 A tag-freeze snapshot can be constructed within the version tag range, and a dual-window closed-loop candidate state machine can be driven based on the tag-freeze snapshot to further limit the confirmation process of version propagation closed-loop technical debt events. The tag-freeze snapshot is generated when the version tag range is determined and includes at least the version tag range identifier, the starting version tag node identifier, the ending version tag node identifier, a summary of the commit node set within that version tag range, a summary of the merge propagation edge set, and a summary of the code entity identity chain set. The tag-freeze snapshot is used to limit the scanning scope of closed-loop candidate events, ensuring that the transition of candidate states only occurs within the corresponding version tag range.

[0091] Tag-freezing snapshots can be generated using the following formula:

[0092]

[0093] in, This indicates that the tag is frozen in a snapshot; Indicates the preset hash function; This indicates a field concatenation operation; Indicates the version tag range identifier; Indicates the starting version tag node identifier; Indicates the termination version tag node identifier; This represents a summary of the set of commit nodes within the version tag range; This represents a summary of the set of merged propagation edges within the version label range; This represents a summary of the code entity identity chain set within the version tag interval. The dual-window closed-loop candidate state machine includes a reverse verification window and a forward scanning window. The reverse verification window traces back from the merge result commit node along the parent-child commit edge to the nearest common ancestor commit node, used to verify whether the source branch introduced fragments and conflict resolution fragments have a common code entity identity chain and multi-anchor consistency check code; the forward scanning window extends from the merge result commit node along the target branch commit path to the terminating version tag node of the version tag interval, used to sequentially find the target branch covered fragments and the fragments introduced before the tag. The candidate states of the dual-window closed-loop candidate state machine include the initial candidate state, the identified conflict resolution fragment state, the identified target branch covered fragment state, the identified fragment introduced before the tag state, and the closed-loop confirmation state.

[0094] In its implementation, after identifying the source branch introduced fragment and generating the merged impact unit, the system sets the corresponding candidate event to the initial candidate state. When the conflict resolution fragment and the source branch introduced fragment are confirmed to belong to the same code entity identity chain in the reverse verification window, and their multi-anchor consistency check codes meet the consistency condition, the candidate event is transferred to the identified conflict resolution fragment state. When the target branch covered fragment is identified in the forward scanning window, the candidate event is transferred to the identified target branch covered fragment state. When a tag-pre-introduced fragment is further identified in the forward scanning window, and the tag-pre-introduced fragment and the source branch introduced fragment meet the code entity boundary anchor point consistency condition, the candidate event is transferred to the identified tag-pre-introduced fragment state. When all four types of fragments are located within the version tag range defined by the tag freeze snapshot and are arranged according to the commit topology order, the candidate event is transferred to the closed-loop confirmation state, and a version propagation closed-loop technical debt event is generated.

[0095] Table 5 Examples of dual-window closed-loop candidate state machine transitions

[0096] Initial candidate state Identify the source branch introduced fragments and generate merged impact units. Conflict resolution fragment status identified Conflict resolution fragment status identified The conflict resolution fragment and the fragment introduced by the source branch belong to the same code entity identity chain, and the multi-anchor consistency checksum satisfies the consistency condition. Identified target branch coverage fragment status Identified target branch coverage fragment status Target branch coverage fragment identified within the forward scan window Introduce fragment state before identifying tags Introduce fragment state before identifying tags The fragment is introduced before the tag is detected in the forward scanning window and is within the range of the tag freeze snapshot. Closed-loop confirmation status Any candidate state The fragment exceeds the scope of the tag-frozen snapshot, or the code entity identity chain is inconsistent. Candidate termination status

[0097] When incremental changes occur in the version control log, the system can first compare the tag-frozen snapshot corresponding to the version tag range where the new record is located. If the new commit record, merge commit record, merge conflict record, code difference record, or file renaming record does not change the commit node set summary, merge propagation edge set summary, or code entity identity chain set summary in the tag-frozen snapshot, then there is no need to rescan the entire version tag range; if the above summaries change, only the dual-window closed-loop candidate state machine within the corresponding version tag range is redriven. Through this processing method, the update scope of version propagation closed-loop technical debt events is limited to the corresponding tag-frozen snapshot and the dual-window scope.

[0098] In another specific implementation, the source branch's introduced fragment does not propagate to the target branch solely through a single merge commit node, but rather through multiple intermediate branches. For example, the source branch feature-A is first merged into the integration branch, and then merged from the integration branch into the main branch. In this case, when the source branch's introduced fragment propagates to the target branch via at least two merge commit nodes, the system sequentially determines the intermediate branch nodes and intermediate merge commit nodes along the merge propagation edge, and associates the intermediate branch nodes, intermediate merge commit nodes, and version propagation closed-loop technical debt events. Thus, the technical debt quantification record can simultaneously store the propagation links of the source branch, target branch, and intermediate branches, where the set of intermediate branch identifiers can be recorded as {integration}.

[0099] In this embodiment, the technical debt quantification record includes the source branch identifier, target branch identifier, intermediate branch identifier set, merge result commit node identifier, target branch overriding commit node identifier, re-introduced commit node identifier before the tag, version tag range identifier, code entity identity chain identifier, number of closed-loop segments included in the version propagation closed-loop technical debt event, and number of merge propagation edges. Specific examples are shown in Table 6.

[0100] Table 6. Example of Quantitative Records of Technology Debt

[0101] Technology debt quantification record identifier debt_record_001 Source branch identifier feature-A Target branch identifier main intermediate branch identifier set {integration} Merge result submission node identifier m201 Target branch overwrite commit node identifier c230 Introduce the submission node identifier before the tag c250 Version tag range identifier Tag_v1.0_to_Tag_v2.0 Code Entity Identity Chain Identifier chain_func_A_001 Multi-anchor consistency check code anchor_code_001 Tag freeze snapshot identifier snapshot_Tag_v1.0_to_Tag_v2.0 State transition sequence Initial candidate state → Identified conflict resolution fragment state → Identified target branch overlay fragment state → Fragment state with identified label before introduction → Closed-loop confirmation state Number of closed-loop segments 4 Merge propagation edge count 2 Event type field Closed-loop propagation events

[0102] In this embodiment, the quantitative value of technical debt can be calculated using the following formula:

[0103]

[0104] in, This represents the quantitative value of technical debt, expressed in cents. Indicates the weight of the proportion of lines of code in the closed-loop segment; This represents the normalized value of the number of lines of code in a closed-loop segment. This indicates the weight of the proportion of edges in the merged propagation process; This represents the normalized value of the number of edges in the merge propagation process. Indicates the proportional weight of the duration of the closed-loop event; This represents the normalized value of the closed-loop event duration; Indicates the weight of the proportion of participants in the merge conflict status; This represents the normalized value of the merged conflict participation state.

[0105] The normalized value of the number of lines of code in a closed-loop segment can be calculated using the following formula:

[0106]

[0107] in, This indicates the number of lines of code in the closed-loop code segment included in the version propagation closed-loop technical debt event, in lines. This represents the preset normalized upper limit for the number of lines of code, in lines. The normalized value for the number of merged propagation edges can be calculated using the following formula:

[0108]

[0109] in, This indicates the number of merged propagation edges associated with the closed-loop technical debt event in the version propagation, expressed in units of edges. This represents the normalized upper limit of the preset number of merged propagation edges, in units of edges. The normalized value of the closed-loop event duration can be calculated using the following formula:

[0110]

[0111] in, This indicates the time span between the commit node corresponding to the segment introduced from the source branch and the commit node corresponding to the segment introduced before the tag, in days; This represents the preset time span normalization upper limit, in days. The merge conflict participation status normalization value can be 1 or 0; when the version propagation closed-loop technical debt event includes a conflict resolution fragment, the merge conflict participation status normalization value is 1, otherwise it is 0. The preset code line count normalization upper limit, the preset merge propagation edge count normalization upper limit, and the preset time span normalization upper limit can be determined based on the statistical results of historical version control logs, or can be preset by the system configuration file.

[0112] In a specific calculation example, the closed-loop code segment has 42 lines of code, with a preset normalized upper limit of 50 lines; the number of merged propagation edges is 2, with a preset normalized upper limit of 3; the closed-loop event duration is 18 days, with a preset normalized upper limit of 30 days; and the event includes a conflict resolution segment. Taking the weights of the closed-loop code segment's lines of code as 0.35, the number of merged propagation edges as 0.25, the closed-loop event duration as 0.20, and the merged conflict participation state as 0.20, then:

[0113]

[0114]

[0115]

[0116]

[0117]

[0118] Therefore, the technical debt quantification record can be output as follows: debt_record_001, code entity identity chain identifier chain_func_A_001, technical debt quantification value 78.15, source branch feature-A, target branch main, merge result commit node m201, target branch overwrite commit node c230, tag pre-introduction commit node c250, version tag range Tag_v1.0_to_Tag_v2.0, multi-anchor consistency check code anchor_code_001, and tag freeze snapshot identifier snapshot_Tag_v1.0_to_Tag_v2.0.

[0119] To verify the differences between this embodiment and existing methods based on merged code comment analysis in terms of the identified objects, a test project containing 320 commit nodes, 100 merge commit nodes, 34 merge conflict records, 18 file renaming records, and 12 version tag ranges was used for comparison. The control scheme only identifies technical debt clues based on code comments after merge conflict resolution, while this embodiment identifies version propagation closed-loop technical debt events based on commit topology, merge propagation relationships, code entity identity chains, and version tag ranges in the version control log. The comparison results are shown in Table 7.

[0120] Table 7 Comparison Test Results

[0121] Number of merge commit nodes that can be processed 100 100 Number of identifiable technical debt clues 16 27 Number of identifiable cross-renaming code entity events 0 8 Number of identifiable cross-version tag range related events 0 11 It can output the number of events in the propagation path from the source branch to the target branch. 0 19 Number of events identified that have closed-loop changes but no annotations 0 9 Number of mismatch events caused by changes in path or line number 6 1 Number of version tag ranges that need to be rescanned during incremental updates 12 3

[0122] Therefore, under the same version control log data conditions, it is difficult to identify continuous change events without task-type comments when analyzing only merge code comments. This embodiment transforms the continuous change process of relevant code content near the boundaries of cross-branch merges and version releases into calculable version propagation closed-loop technical debt events by using merge propagation graphs anchored by version tags, code entity identity chains, and merge impact units. This allows for the output of quantitative records of technical debt containing source branches, target branches, commit nodes, version tag ranges, and code entity identity chains. Furthermore, by using multi-anchor consistency check codes to jointly verify path inheritance anchors, difference context anchors, code entity boundary anchors, and conflict fragment indices, false matches caused by cross-path or cross-line number changes can be reduced. By using tag-freezing snapshots and dual-window closed-loop candidate state machines to limit the update range, the number of version tag ranges that need to be rescanned during incremental updates can be reduced.

[0123] This embodiment also supports incremental updates. When adding commit records, merge commit records, merge conflict records, code difference records, file renaming records, or version tag records to the version control log, the system determines the version tag range of the newly added commit node or the existing commit node affected by the newly added record, determines the ancestor commit path obtained by backtracking along the parent-child commit edges from the newly added or existing commit node, determines the branch nodes connected to the newly added or existing commit node with merge propagation edge relationships, and determines the code entity identity chain associated with the newly added or existing commit node. Afterwards, the system only updates the version propagation closed-loop technical debt events and technical debt quantification records corresponding to the determined version tag range, ancestor commit path, branch node, and code entity identity chain. Through this method, new log entries can be processed within the relevant version tag range, ancestor commit path, branch node, and code entity identity chain. When using a tag-frozen snapshot and a dual-window closed-loop candidate state machine, the system can first compare the tag-frozen snapshots of the version tag range where the new record is located, and when the commit node set summary, merge propagation edge set summary, or code entity identity chain set summary corresponding to the tag-frozen snapshot changes, it only re-drives the dual-window closed-loop candidate state machine within the corresponding version tag range.

[0124] This embodiment provides a software technical debt identification and quantification system based on version control logs. (Refer to...) Figure 6 The system includes a log acquisition module, a merge propagation graph construction module, a code entity identity chain construction module, a merge impact unit generation module, a fragment recognition module, a closed-loop event generation module, and a quantized record generation module. These modules can be deployed on the same electronic device or in a computing environment consisting of multiple servers. (See reference...) Figure 7 The electronic device may include a processor, a memory, a communication interface, a version control log input interface, a technical debt quantification record output interface, and a bus. The memory stores a computer program, and when the processor executes this computer program, it can implement the processing procedures of each module in this embodiment.

[0125] The log acquisition module is used to obtain version control logs for application software development projects and output these logs to the merge propagation graph construction module and the code entity identity chain construction module. The log acquisition module can read log data through the version control system interface, code hosting platform interface, or local repository parser. Version control logs include commit records, commit parent node relationships, branch reference records, merge commit records, merge conflict records, code difference records, file renaming records, and version tag records. Specifically, commit records include a commit identifier and commit timestamp; commit parent node relationships include child commit identifiers and parent commit identifiers; branch reference records include a branch identifier and the commit identifier the branch points to; merge commit records include a merge commit identifier, first parent commit identifier, and second parent commit identifier; merge conflict records include the conflicting file path, conflict block location, and conflict resolution commit identifier; code difference records include code entity name, code entity boundary location, difference context, and difference fragment; file renaming records include the path before renaming and the path after renaming; and version tag records include version tag identifiers and tag-anchored commit identifiers.

[0126] The merge propagation graph construction module constructs a merge propagation graph anchored by version tags based on commit records, commit parent node relationships, branch reference records, merge commit records, and version tag records. This merge propagation graph is then output to the merge impact unit generation module, fragment identification module, and closed-loop event generation module. The merge propagation graph includes commit nodes, merge commit nodes, branch nodes, version tag nodes, parent-child commit edges, branch pointing edges, tag anchoring edges, merge propagation edges, commit paths, and version tag intervals. Commit paths are formed by connecting parent-child commit edges, and the commit topology order is determined by these edges. Version tag intervals include the starting version tag node and the ending version tag node.

[0127] In the merge propagation graph construction module, commit identifiers in commit records are generated as commit nodes. In the commit parent node relationship, the commit node corresponding to the parent commit identifier is connected to the commit node corresponding to the child commit identifier to generate a parent-child commit edge. In the branch reference record, branch identifiers are generated as branch nodes. The commit node corresponding to the branch pointing commit identifier is connected to the branch node to generate a branch pointing edge. In the version tag record, version tag identifiers are generated as version tag nodes. The commit node corresponding to the tag anchor commit identifier is connected to the version tag node to generate a tag anchor edge. Furthermore, the set of commit nodes between two adjacent version tag nodes according to the commit topology order is determined as the version tag interval. For merge commit records, the merge propagation graph construction module marks the commit node corresponding to the merge commit identifier as the merge commit node. When the merge commit node has a first parent commit node corresponding to the first parent commit identifier and a second parent commit node corresponding to the second parent commit identifier, the first parent commit node is designated as the target branch parent commit node, and the second parent commit node is designated as the source branch parent commit node. The target branch and source branch are determined based on the branch nodes corresponding to the target branch parent commit node and the source branch parent commit node, respectively, and a merge propagation edge is generated pointing from the source branch through the merge commit node to the target branch.

[0128] The code entity identity chain construction module is used to construct code entity identity chains based on code diff records and file renaming records, and configures corresponding identifiers for commit nodes, branch nodes, version tag nodes, version tag ranges, merge propagation edges, and code entity identity chains. This module outputs the code entity identity chains to the merge impact unit generation module, fragment recognition module, closed-loop event generation module, and quantization record generation module. The module generates path inheritance anchors based on the pre-rename and post-rename paths in the file renaming records, generates difference context anchors based on the difference context in the code diff records, and generates code entity boundary anchors based on the code entity names and code entity boundary positions in the code diff records. Code entities with matching path inheritance anchors, difference context anchors, and code entity boundary anchors are connected into the same code entity identity chain.

[0129] In its implementation, the code entity identity chain construction module can invoke an abstract syntax tree parser to parse code files, identifying the names and boundary positions of functions, classes, or interfaces. For Python source code, function boundaries can be determined by parsing `def` statements and indentation ranges; for Java source code, method declaration nodes and the end position of method bodies can be determined by the abstract syntax tree node types. If multiple candidate code entities correspond to the renamed path in the same file renaming record, the code entity identity chain construction module determines the continuous matching segments between the difference context anchors of each candidate code entity and the difference context anchors of the code entities in the original path, and adds the candidate code entities whose continuous matching segments contain code entity boundary anchors to the code entity identity chain of the code entities in the original path.

[0130] The code entity identity chain construction module can also generate multi-anchor consistency check codes for code entity identity chains within the same version tag range. Specifically, the module concatenates the version tag range identifier, code entity identity chain identifier, path inheritance anchor digest, difference context anchor digest, code entity boundary anchor digest, and conflict fragment index, and inputs a preset hash function to generate a multi-anchor consistency check code. The module outputs the multi-anchor consistency check code to the fragment recognition module and the closed-loop event generation module to verify whether source branch introduced fragments, conflict resolution fragments, target branch overriding fragments, and tag-pre-introduced fragments belong to the same verifiable continuous evolution chain.

[0131] The merge impact unit generation module receives the merge propagation graph and code entity identity chain. For merge commit nodes within the version tag range, it determines the source branch, target branch, source branch parent commit node, target branch parent commit node, and merge result commit node based on the merge propagation edges. It also determines the nearest common ancestor commit node between the source branch parent commit node and the target branch parent commit node, generating merge impact units. This module outputs the merge impact units to the fragment recognition module. Using the nearest common ancestor commit node as a reference, the merge impact unit generation module extracts the source branch difference set relative to the nearest common ancestor commit node, the target branch difference set relative to the nearest common ancestor commit node, and the merge result difference set relative to the source branch parent commit node and the target branch parent commit node. It then maps the source branch difference set, target branch difference set, and merge result difference set to the corresponding code entity identity chain.

[0132] The fragment identification module receives merge impact units, merge propagation graphs, and code entity identity chains. Within the merge impact units, it extracts source branch introduction fragments and conflict resolution fragments from the same code entity identity chain. On the commit path formed by parent-child commit edges and located between the target branch's parent commit node and the terminating version tag node within the version tag interval, it identifies target branch overlay fragments and tag-pre-introduced fragments following the target branch overlay fragments. The fragment identification module outputs the source branch introduction fragments, conflict resolution fragments, target branch overlay fragments, and tag-pre-introduced fragments to the closed-loop event generation module. The fragment identification module selects difference fragments associated with the code entity identity chain from the source branch difference set, excluding those also present in the target branch difference set, and identifies the retained difference fragments as source branch introduction fragments. The fragment identification module also generates a conflict fragment index based on the conflict file path, conflict block location, and conflict resolution commit identifier in the merge conflict record. It then selects difference fragments from the merge result difference set that match the conflict fragment index and belong to the same code entity identity chain as the source branch introduction fragment, identifying these as conflict resolution fragments.

[0133] When identifying target branch covered segments, the segment identification module searches for subsequent difference segments belonging to the same code entity identity chain as the conflict resolution segment within commit nodes located after the merge result commit node along the commit path of the target branch. When a subsequent difference segment replaces the code entity boundary anchor in the conflict resolution segment with the corresponding code entity boundary anchor in the nearest common ancestor commit node or the target branch's parent commit node, belonging to the same code entity identity chain as the conflict resolution segment, the segment identification module identifies this subsequent difference segment as a target branch covered segment. When identifying segments introduced before the tag, the segment identification module searches for reproduced difference segments belonging to the same code entity identity chain as the source branch introduced segment, after the commit node corresponding to the target branch covered segment and before the commit node corresponding to the terminating version tag node in the version tag range. When a reproduced difference segment contains a code entity boundary anchor in the source branch introduced segment, the segment identification module identifies the reproduced difference segment as a segment introduced before the tag.

[0134] The closed-loop event generation module receives source branch introduction fragments, conflict resolution fragments, target branch coverage fragments, tag-pre-introduction fragments, merge propagation graphs, and code entity identity chains. When these four types of fragments are connected according to the merge propagation edges and commit topology order, a version propagation closed-loop technical debt event is generated. Specifically, the closed-loop event generation module binds the source branch introduction fragment, conflict resolution fragment, target branch coverage fragment, and tag-pre-introduction fragment to their corresponding commit nodes. It identifies the commit node corresponding to the target branch coverage fragment as the target branch coverage commit node, and the commit node corresponding to the tag-pre-introduction fragment as the tag-pre-introduction commit node. A version propagation closed-loop technical debt event is generated when the commit nodes corresponding to the four types of fragments are located in the same version tag range, belong to the same code entity identity chain, and the source branch parent commit node, merge result commit node, target branch coverage commit node, and tag-pre-introduction commit node are arranged according to the commit topology order. When a fragment introduced from the source branch propagates to the target branch via at least two merge commit nodes, the closed-loop event generation module sequentially determines the intermediate branch node and the intermediate merge commit node along the merge propagation edge, and associates the intermediate branch node, the intermediate merge commit node, and the version propagation closed-loop technical debt event.

[0135] The closed-loop event generation module can also construct a tag-freeze snapshot and drive a dual-window closed-loop candidate state machine based on this snapshot. When the version tag range is determined, the module generates a tag-freeze snapshot, which includes the version tag range identifier, the starting version tag node identifier, the ending version tag node identifier, a summary of the commit node set, a summary of the merge propagation edge set, and a summary of the code entity identity chain set. The module verifies the consistency of the code entity identity chain and the consistency of the multi-anchor consistency checksum between the source branch-introduced fragment and the conflict resolution fragment using a reverse verification window, and searches for the target branch-overriding fragment and the fragment introduced before the tag is added using a forward scanning window. When the candidate states sequentially transition to the closed-loop confirmation state, the module generates a version propagation closed-loop technical debt event.

[0136] The quantification record generation module receives version propagation closed-loop technical debt events and generates technical debt quantification records based on these events. The module identifies the commit node corresponding to the target branch covered segment as the target branch covered commit node, and the commit node corresponding to the tag-pre-introduced segment as the tag-pre-introduced commit node. It extracts the source branch identifier, target branch identifier, intermediate branch identifier set, merge result commit node identifier, target branch covered commit node identifier, tag-pre-introduced commit node identifier, version tag range identifier, and code entity identity chain identifier from the identifiers corresponding to the source branch, target branch, intermediate branch identifier set, merge result commit node identifier, target branch covered commit node identifier, tag-pre-introduced commit node identifier, version tag range identifier, and code entity identity chain identifier. These identifiers, along with the number of closed-loop segments and merge propagation edges included in the version propagation closed-loop technical debt event, are written into the same technical debt quantification record. The quantification record generation module can also write multi-anchor consistency check codes, tag freeze snapshot identifiers, and state transition sequences into the technical debt quantification record. The quantitative record generation module can also perform weighted calculations based on dimensions such as the number of lines of code in the closed-loop segment, the number of merge propagation edges, the duration of the closed-loop event, and the participation status of the merge conflict, and write the resulting quantitative value of technical debt into the quantitative record of technical debt.

[0137] In one specific deployment method, the log acquisition module synchronizes new logs from the version control system via a scheduled task. If a new commit record, merge commit record, merge conflict record, code difference record, file renaming record, or version tag record is added to the version control log, the merge propagation graph construction module and the code entity identity chain construction module determine the version tag range of the new commit node or the existing commit node affected by the new record, and determine the ancestor commit path obtained by backtracking along the parent-child commit edge from the new commit node or the existing commit node, the branch nodes connected to the new commit node or the existing commit node by the merge propagation edge, and the code entity identity chain associated with the new commit node or the existing commit node. Subsequently, the closed-loop event generation module and the quantified record generation module update the version propagation closed-loop technical debt events and technical debt quantified records corresponding to the determined version tag range, ancestor commit path, branch nodes, and code entity identity chain.

[0138] When using a tag-frozen snapshot and a dual-window closed-loop candidate state machine, the closed-loop event generation module first compares the tag-frozen snapshots of the version tag range where the new record is located. If the new record does not change the commit node set summary, merge propagation edge set summary, or code entity identity chain set summary in the corresponding tag-frozen snapshot, the dual-window closed-loop candidate state machine in that version tag range is not re-driven. If the new record changes the commit node set summary, merge propagation edge set summary, or code entity identity chain set summary in the corresponding tag-frozen snapshot, the dual-window closed-loop candidate state machine in that version tag range is re-driven, and the corresponding version propagation closed-loop technical debt event and technical debt quantification record are updated.

[0139] The system in this embodiment uses commit records, commit parent node relationships, branch reference records, merge commit records, merge conflict records, code difference records, file renaming records, and version tag records from the version control log as its processing foundation. Its core data processing revolves around commits, branches, merges, conflicts, differences, renaming, and version tags within the version control system. Therefore, the system in this embodiment belongs to the field of version control log analysis and software configuration management, and is suitable for identifying and quantifying software technical debt based on version control logs during application software development.

[0140] It should be noted that the embodiments of the present invention have better implementability and are not intended to limit the present invention in any way. Any person skilled in the art may use the above-disclosed technical content to change or modify it into equivalent effective embodiments. However, any modifications or equivalent changes and modifications made to the above embodiments based on the technical essence of the present invention without departing from the content of the technical solution of the present invention shall still fall within the scope of the technical solution of the present invention.

Claims

1. A method for identifying and quantifying software technical debt based on version control logs in application software development, characterized in that, include: Obtain the version control log of the application software development project. The version control log includes commit records, commit parent node relationships, branch reference records, merge commit records, merge conflict records, code difference records, file renaming records, and version tag records. Specifically, the commit records include a commit identifier and a commit timestamp; the commit parent node relationships include child commit identifiers and parent commit identifiers; the branch reference records include a branch identifier and a branch-pointing commit identifier; the merge commit records include a merge commit identifier, a first parent commit identifier, and a second parent commit identifier; the merge conflict records include the conflicting file path, the conflict block location, and the conflict resolution commit identifier; the code difference records include the code entity name, code entity boundary location, difference context, and difference fragment; the file renaming records include the path before renaming and the path after renaming; and the version tag records include a version tag identifier and a tag-anchored commit identifier. Based on the commit records, the commit parent node relationships, the branch reference records, the merge commit records, and the version tag records, a merge propagation graph anchored by version tags is constructed. The merge propagation graph includes commit nodes, merge commit nodes, branch nodes, version tag nodes, parent-child commit edges, branch pointing edges, tag anchoring edges, merge propagation edges, commit paths, and version tag intervals. The commit paths are formed by connecting the parent-child commit edges, and the commit topology order is determined by the parent-child commit edges. The version tag intervals include the starting version tag node and the ending version tag node. A code entity identity chain is constructed based on the code difference record and the file renaming record, and corresponding identifiers are configured for the commit node, the branch node, the version tag node, the version tag range, the merge propagation edge, and the code entity identity chain; For the merge commit nodes within the version tag range, the source branch, target branch, source branch parent commit node, target branch parent commit node, and merge result commit node are determined based on the merge propagation edge. The nearest common ancestor commit node of the source branch parent commit node and the target branch parent commit node is determined, and a merge impact unit is generated. Extract the source branch introduction fragment and conflict resolution fragment from the same code entity identity chain in the merged impact unit; On the commit path formed by the parent and child commit edges and located between the target branch parent commit node and the terminating version tag node in the version tag interval, identify the target branch coverage fragment on the same code entity identity chain and the fragment introduced before the tag after the target branch coverage fragment. When the source branch introduced fragment, the conflict resolution fragment, the target branch overridden fragment, and the tag-pre-introduced fragment are connected in the order of the merge propagation edge and the commit topology, a version propagation closed-loop technical debt event is generated, and a technical debt quantification record is generated based on the version propagation closed-loop technical debt event.

2. The method for identifying and quantifying software technical debt based on version control logs according to claim 1, characterized in that, Constructing the merge propagation graph includes: generating commit identifiers from the commit records as commit nodes; connecting the commit nodes corresponding to the parent commit identifiers in the commit parent node relationship with the commit nodes corresponding to the child commit identifiers in the commit parent node relationship to generate parent-child commit edges; generating branch identifiers from the branch reference records as branch nodes; connecting the commit nodes corresponding to the branch-pointing commit identifiers with the branch nodes to generate branch-pointing edges; generating version tag identifiers from the version tag records as version tag nodes; connecting the commit nodes corresponding to the tag-anchored commit identifiers with the version tag nodes to generate tag-anchoring edges; and determining the set of commit nodes between two adjacent version tag nodes according to the commit topology as version tag intervals.

3. The method for identifying and quantifying software technical debt based on version control logs according to claim 1, characterized in that, Generating the merge propagation edge includes: marking the commit node corresponding to the merge commit identifier in the merge commit record as the merge commit node; when the merge commit node has a first parent commit node corresponding to the first parent commit identifier and a second parent commit node corresponding to the second parent commit identifier, the first parent commit node is used as the target branch parent commit node, the second parent commit node is used as the source branch parent commit node, the target branch and the source branch are determined according to the branch nodes corresponding to the target branch parent commit node and the source branch parent commit node, and a merge propagation edge is generated from the source branch through the merge commit node to the target branch.

4. The method for identifying and quantifying software technical debt based on version control logs according to claim 1, characterized in that, Constructing the code entity identity chain includes: generating path inheritance anchors based on the pre-rename path and post-rename path in the file renaming record; generating difference context anchors based on the difference context in the code difference record; generating code entity boundary anchors based on the code entity name and code entity boundary position in the code difference record; and connecting code entities whose path inheritance anchors, difference context anchors, and code entity boundary anchors all match into the same code entity identity chain.

5. The method for identifying and quantifying software technical debt based on version control logs according to claim 4, characterized in that, When constructing the code entity identity chain, if the renamed path in the same file renaming record corresponds to multiple candidate code entities, and the candidate code entities are code entities located in the renamed path, then the continuous matching segments between the difference context anchors of each candidate code entity and the difference context anchors of the code entities in the original path in the file renaming record are determined respectively, and the candidate code entities whose continuous matching segments contain the code entity boundary anchors are connected to the code entity identity chain where the code entities in the original path are located.

6. The method for identifying and quantifying software technical debt based on version control logs according to claim 1, characterized in that, Generating the merge impact unit includes: taking the nearest common ancestor commit node as a reference, extracting the source branch difference set of the source branch parent commit node relative to the nearest common ancestor commit node, the target branch difference set of the target branch parent commit node relative to the nearest common ancestor commit node, and the merge result difference set of the merge result commit node relative to the source branch parent commit node and the target branch parent commit node, and mapping the source branch difference set, the target branch difference set, and the merge result difference set to the corresponding code entity identity chain.

7. The method for identifying and quantifying software technical debt based on version control logs according to claim 6, characterized in that, Extracting the source branch introduction fragment includes: selecting the difference fragment associated with the code entity identity chain from the source branch difference set, excluding the difference fragments that also exist in the target branch difference set, and determining the retained difference fragment as the source branch introduction fragment.

8. The method for identifying and quantifying software technical debt based on version control logs according to claim 6, characterized in that, Extracting the conflict resolution fragment includes: generating a conflict fragment index based on the conflict file path, conflict block location, and conflict resolution commit identifier in the merge conflict record; selecting a difference fragment from the merge result difference set that matches the conflict fragment index and belongs to the same code entity identity chain as the fragment introduced by the source branch; and identifying the difference fragment as the conflict resolution fragment.

9. The method for identifying and quantifying software technical debt based on version control logs according to claim 4, characterized in that, Identifying the target branch coverage fragment includes: within the commit nodes located after the merge result commit node along the commit path of the target branch, searching for subsequent difference fragments that belong to the same code entity identity chain as the conflict resolution fragment; when the subsequent difference fragment replaces the code entity boundary anchor in the conflict resolution fragment with the corresponding code entity boundary anchor in the nearest common ancestor commit node or the target branch parent commit node that belongs to the same code entity identity chain as the conflict resolution fragment, the subsequent difference fragment is determined as the target branch coverage fragment.

10. A software technical debt identification and quantification system based on version control logs, characterized in that, include: The log acquisition module is configured to acquire version control logs of the application software development project. These logs include commit records, commit parent node relationships, branch reference records, merge commit records, merge conflict records, code difference records, file renaming records, and version tag records. Specifically, the commit records include a commit identifier and a commit timestamp; the commit parent node relationships include child commit identifiers and parent commit identifiers; the branch reference records include a branch identifier and a branch-pointing commit identifier; the merge commit records include a merge commit identifier, a first parent commit identifier, and a second parent commit identifier; the merge conflict records include the conflicting file path, the conflict block location, and the conflict resolution commit identifier; the code difference records include the code entity name, code entity boundary location, difference context, and difference fragment; the file renaming records include the path before renaming and the path after renaming; and the version tag records include a version tag identifier and a tag-anchored commit identifier. The merge propagation graph construction module is configured to construct a merge propagation graph anchored by version tags based on the commit records, the commit parent node relationships, the branch reference records, the merge commit records, and the version tag records. The merge propagation graph includes commit nodes, merge commit nodes, branch nodes, version tag nodes, parent-child commit edges, branch pointing edges, tag anchoring edges, merge propagation edges, commit paths, and version tag intervals. The commit paths are formed by connecting the parent-child commit edges, and the commit topology order is determined by the parent-child commit edges. The version tag intervals include a start version tag node and an end version tag node. The code entity identity chain construction module is configured to construct a code entity identity chain based on the code difference record and the file renaming record, and to configure corresponding identifiers for the commit node, the branch node, the version tag node, the version tag range, the merge propagation edge and the code entity identity chain; The merge impact unit generation module is configured to, for merge commit nodes within the version tag range, determine the source branch, target branch, source branch parent commit node, target branch parent commit node, and merge result commit node based on the merge propagation edge, and determine the nearest common ancestor commit node of the source branch parent commit node and the target branch parent commit node to generate merge impact units; the fragment identification module is configured to extract source branch introduction fragments and conflict resolution fragments on the same code entity identity chain in the merge impact units, and on the commit path formed by the parent-child commit edge and located between the target branch parent commit node and the terminating version tag node of the version tag range, identify target branch overlay fragments and tag pre-introduction fragments located after the target branch overlay fragments on the same code entity identity chain; The closed-loop event generation module is configured to generate a version propagation closed-loop technical debt event when the source branch introduction fragment, the conflict resolution fragment, the target branch coverage fragment, and the tag pre-introduction fragment are connected in the order of the merge propagation edge and the commit topology. The quantitative record generation module is configured to generate quantitative records of technical debt based on the version propagation closed-loop technical debt event.

Images