Code counting method and device, electronic equipment and storage medium

Abstract

The application provides a code statistics method and device, electronic equipment and storage medium, the method comprises: obtaining project information of a plurality of projects under a plurality of hierarchical groups to be counted; filtering out effective branches through the project information and a preset branch list, and extracting a plurality of code submission records carrying submission hash values from the effective branches; using the submission hash values to deduplicate the plurality of code submission records, filtering out effective code submission records in the deduplicated code submission records, and identifying author names to obtain garbled author names and normal author names; grouping the effective code submission records by email addresses, repairing garbled author names in the groups by using normal author names in the groups. Identify the main author and non-main author names in the group; add the code modification information of the non-main author names in each group to the main author names, and obtain the code statistics contribution of the main author names corresponding to each group, so as to improve the accuracy of code statistics.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a code statistics method, apparatus, electronic device, and storage medium. Background Technology

[0002] With the continuous expansion of software engineering scale and the significant increase in the complexity of development team collaboration, accurate statistics and analysis of developers' code contributions have become a key basis for modern software project management, performance evaluation, and human resource allocation. Code version control platforms, such as GitLab, can provide basic commit record application programming interfaces (APIs) to statistically analyze developers' code contributions.

[0003] However, existing technical solutions have the following drawbacks in practical applications: First, they can only count developers' code contributions in simple scenarios with a single project and branch. In complex scenarios with multiple projects, multi-level groups, and multiple branches, incomplete or duplicate statistics can lead to biased results. Second, large-scale automated code generation, batch imports of third-party libraries, or full library refactoring are often included in contribution statistics, severely interfering with the results, obscuring effective contributions in daily development, and affecting the fairness of performance evaluation and the scientific nature of resource allocation. Third, due to differences in development environment configurations, inconsistent character encodings, or legacy issues from system migrations, the same developer may submit under different names (e.g., Chinese name, English name), or even garbled characters, resulting in contribution data being scattered across multiple virtual authors, making accurate aggregation and attribution impossible. Summary of the Invention

[0004] In view of this, this application aims to propose a code statistics method, device, electronic device, and storage medium to solve the problems of current code statistics in complex scenarios involving multiple projects, multi-level groups, and multiple branches, where incomplete or duplicate statistics can lead to biased results. Furthermore, automatically generated merged commits from Git platforms are often included in contribution statistics, introducing statistical noise. Additionally, garbled fields cause contribution data to be scattered across multiple virtual authors, making accurate aggregation and attribution impossible. The specific technical solution is as follows: According to a first aspect of this application, a code statistics method is provided, the method comprising: Obtain project information for several projects under a multi-level group to be analyzed; The project information and the preset branch list are used to filter the valid branches of several projects, and a number of code commit records carrying commit hash values ​​are extracted from the valid branches. The code commit records include the author's name, email address and code modification information. After deduplicating several code commit records using the commit hash value, the valid code commit records in the deduplicated code commit records are filtered out. The author names of the valid code submission records are identified to obtain garbled author names and normal author names; The valid code submission records are grouped by the email address, and the garbled author names in each group are repaired using the normal author names in each group. At the same time, the main author name and non-main author names in each group are identified. The code modification information under the names of non-main authors and main authors in each group is summed to obtain the code contribution statistics of the main author names for each group.

[0005] Optionally, the step of deduplicating several code commit records using the commit hash value includes: Compare the commit hashes of several code commit records; Group code commit records with the same hash value into a group to obtain several sets of duplicate code commit records; Identify the submission time of each code submission record in the set of duplicate code submission records, and determine the non-first code submission records in the set of duplicate code submission records based on the submission time; Delete non-first code commit records from each set of duplicate code commit records.

[0006] Optionally, the valid code commit records in the filtered deduplicated code commit records include: After deduplication, the total number of lines of code changes corresponding to each code commit is identified and recorded. The total number of lines of code changed is compared with a preset threshold for the number of lines of code. Code commits with a total number of lines of code changes exceeding a preset threshold are deemed invalid. After deduplication, invalid code commit records are deleted to obtain valid code commit records.

[0007] Optionally, the total number of lines of code changes corresponding to each code commit record after deduplication further includes: Detect the number of parent nodes, commit title, and commit message in the parent node identifier list field of each deduplicated code commit record; If the number of parent nodes, the commit title, and the commit message meet the preset conditions, then the commit type of the corresponding code commit record is determined to be a merge commit; If the number of parent nodes, the commit title, and the commit message do not meet the preset conditions, then the commit type of the corresponding code commit record is determined to be a single commit. For the target code commit record in the deduplicated code commit record, if the commit type of the target code commit record is a merge commit, then identify the total number of lines of code changes in each commit branch in the target code commit record; The total number of lines of code changes in each commit branch is summed up to obtain the total number of lines of code changes in the target code commit record. If the commit type of the target code commit record is a single commit, then the total number of lines of code changes in the target code commit record is directly identified.

[0008] Optionally, the step of identifying the author name of the valid code submission record to obtain the garbled author name and the normal author name includes: By using a preset list of garbled characters and a preset regular expression, it is determined whether the author's name of the valid code submission record contains at least one of garbled characters, unconventional characters, or ASCII control characters; If it is included, then the author name of the valid code submission record is determined to be a garbled author name; If not included, the author name of the valid code submission record is determined to be a normal author name.

[0009] Optionally, the step of grouping the valid code submission records by the email address and repairing the garbled author names within each group using the normal author names of each group includes: The valid code submission records containing the same email address are grouped together to obtain a set of valid code submission records; Within each set of valid code commit records, identify the similarity between the garbled author's name and the normal author's name; Filter out target similarities greater than the similarity threshold from the similarity scores; Identify the garbled author names and normal author names corresponding to the target similarity, and modify the corresponding garbled author names to the corresponding normal author names.

[0010] Optionally, identifying the main author name and non-main author names within each group includes: Identify the total number of valid code submission records corresponding to each normal author name within each group; The main author name within each group is determined by identifying the maximum total number of entries; By identifying non-maximum total number of entries, the names of non-primary authors within each group are determined.

[0011] According to a second aspect of this application, a code counting apparatus is provided, the apparatus comprising: The first acquisition module is used to acquire project information of several projects under the multi-level group to be statistically analyzed. The first filtering module is used to filter valid branches in several projects through the project information and the preset branch list, and extract several code commit records carrying commit hash values ​​from the valid branches. The code commit records include author name, email address and code modification information. The deduplication filtering module is used to deduplicate several code commit records using the commit hash value, and then filter out the valid code commit records from the deduplicated code commit records. The author name recognition module is used to identify the author names of the valid code submission records and obtain garbled author names and normal author names; The group repair module is used to group the valid code submission records by the email address, repair the garbled author names in each group using the normal author names in each group, and identify the main author name and non-main author names in each group. The accumulation module is used to accumulate the code modification information under the names of non-main authors and main authors in each group to obtain the code contribution statistics of the main author names for each group.

[0012] According to another aspect of this application, an electronic device is also provided, comprising: processor; Memory used to store the processor's executable instructions; The processor is configured to execute the instructions to implement the code statistics method described above.

[0013] According to another aspect of this application, a computer-readable storage medium is also provided, wherein instructions are stored therein, which, when executed on a computer, cause the computer to implement any of the code statistics methods of the first aspect described above.

[0014] The code statistics method provided in this application firstly addresses the issue of incomplete statistics caused by missing projects or levels in complex scenarios with multiple projects and multiple levels by obtaining project information from several projects under a multi-level group to be counted. It then filters valid branches from several projects using project information and a preset branch list, and extracts several code commit records carrying commit hash values ​​from these valid branches. These commit records contain author names, email addresses, and code modification information. This not only avoids the problem of duplicate statistics caused by the same code appearing in different branches, but also lays a data foundation for subsequent deep cleaning and aggregation by extracting key data such as commit hashes, author names, email addresses, and code modification information from the records. Finally, it uses commit hash values ​​to deduplicate the code commit records, ensuring that the same code change is counted only once, regardless of how many groups, projects, or branches it appears in, thus eliminating duplicate calculations. The method then filters out the valid code commit records after deduplication. It can eliminate interference from non-human code changes, making the statistical results more focused on genuine contributions. It identifies the author names of valid code commit records, obtaining garbled author names and normal author names. Valid code commit records are grouped by email address, and the normal author names of each group are used to correct garbled author names within their respective groups, achieving cleanliness and normalization of author information. This solves the problem of the same developer's contributions being scattered among multiple virtual authors and unable to be accurately aggregated due to garbled characters or inconsistent naming. It identifies the main author name and non-main author names within each group, and accumulates the code modification information under the non-main author names and the main author names in each group to obtain the code contribution statistics of the main author name for each group. It achieves accurate statistics of code contribution in complex environments with multi-level groups and multiple branches, providing reliable and fair data support for performance evaluation and resource allocation, and significantly improving the scientific and fair nature of management decisions.

[0015] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this application more obvious and understandable, specific embodiments of this application are given below. Attached Figure Description

[0016] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings: Figure 1 This is a flowchart of the steps of a code statistics method provided in this application; Figure 2 yes Figure 1The flowchart shown is a step 104 of a code statistics method provided in this application; Figure 3 This is a system architecture diagram of a code statistics method provided in this application; Figure 4 This is a schematic diagram of the structure of a code counting device provided in this application; Figure 5 This is a schematic diagram of the structure of an electronic device provided in this application. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of this application clearer, the various embodiments of this application will be described in detail below with reference to the accompanying drawings. However, those skilled in the art will understand that many technical details have been provided in the various embodiments of this application to facilitate a better understanding of the application. However, the technical solutions claimed in this application can be implemented even without these technical details and with various variations and modifications based on the following embodiments. The division of the various embodiments below is for ease of description and should not constitute any limitation on the specific implementation of this application. The various embodiments can be combined with and referenced by each other without contradiction.

[0018] As software development projects grow in scale and team collaboration becomes increasingly complex, accurately tracking and analyzing developers' code contributions has become crucial for project management, performance evaluation, and resource allocation. Currently, common technical solutions in code statistics include: GitLab platforms provide basic contributor statistics charts, allowing users to view commit records and code change volumes for individual projects; and third-party statistical tools such as GitStats and git-quick-stats analyze developers' code contributions by parsing Git log files. However, these solutions suffer from several problems: First, they are designed for single projects and cannot effectively handle the batch statistical needs of enterprise-level multi-project, multi-level groups. Second, in multi-branch development, the same commit may exist in multiple branches, leading to duplicate calculations in traditional solutions, resulting in severely distorted statistics that fail to accurately reflect the true amount of code contribution. Third, automated tools, third-party library imports, and batch refactoring operations generate numerous non-human code changes that severely distort statistical results and obscure normal development contributions. Subsequently, due to improper Git configuration, character encoding issues, or system migration, author names frequently became garbled, and the same author often used different names, leading to scattered statistical results and inaccurate attribution. Based on these problems, this application proposes a code statistics method. (Refer to...) Figure 1 The diagram illustrates a flowchart of a code statistics method provided in this application, the method including: Step 101: Obtain project information for several projects under the multi-level group to be analyzed.

[0019] This application obtains the group identifier (ID) of the multi-level groups to be analyzed and inputs the group ID into the GitLab Application Programming Interface (GitLab API) code version management platform. The GitLab API first queries a list of all subgroups under the given group. Then, using a recursive or iterative algorithm, it traverses the entire group tree level by level until all levels of subgroups are accessed. During the traversal, for each group (including the root group and all subgroups), the project information of the projects contained within it needs to be read. The project information includes the project name, project ID, project version number, project added tags (such as obsolete tags), branch name, and branch identifier.

[0020] Step 102: Filter several valid branches in the project through project information and preset branch list, and extract several code commit records carrying commit hash values ​​from the valid branches. The code commit records contain author name, email address and code modification information.

[0021] The default branch list in this application is set according to the user's query requirements, and includes branch names entered based on the user's query needs. For example, if a user needs to query the code commit records of the main branch and the develop branch, they can enter the names of the two branches ("main" and "develop") into the default branch list. Then, for each project, each branch name in the project information is compared with the branch names in the default branch list. When the names match, the branch with that name is a valid branch in that project. For each valid branch, the GitLab Commits API is called to retrieve the code commit records contained therein. A branch identifier is added to each code commit record.

[0022] Each code commit record can contain at least one piece of information: the author's name, commit time, file snapshot, parent node identifier list field, commit title, commit message, email address, and code modification information. Based on this information, a commit hash value—a Secure HashAlgorithm Value (SHA)—can be generated for each code commit record. These commit hash values ​​are stored using a hash set structure.

[0023] Step 103: After deduplicating several code commit records using the commit hash value, filter out the valid code commit records from the deduplicated code commit records.

[0024] Each code commit in this application generates a commit hash value. Code commits with the same commit hash value can be considered as the same commit from different branches and need to be deduplicated. Deduplication requires identifying the earliest commit based on its commit time and retaining it. Subsequent commits with the same commit hash value need to be deleted. Therefore, step 103, "Deduplicating several code commits using commit hash values," specifically includes the following sub-steps: Sub-step 1031: Compare the commit hash values ​​of several code commit records.

[0025] Sub-step 1032: Group the code commit records with the same commit hash value into a group to obtain several sets of duplicate code commit records.

[0026] Sub-step 1033: Identify the commit time of each code commit record in the set of duplicate code commit records, and determine the non-first code commit records in the set of duplicate code commit records based on the commit time.

[0027] Sub-step 1034: Delete the non-first code commit records in each set of duplicate code commit records.

[0028] The above steps automatically identify and group duplicate commit records based on the comparison of commit hash values. Then, by comparing the commit times, the non-first commit records in each group are accurately located and deleted. This can effectively eliminate duplicate commit data caused by cross-branch merging, multi-person collaboration, or accidental operation, avoiding the problems of easy omission and low efficiency of manual comparison. It ensures the simplicity and authenticity of the repository history, providing a cleaner and more accurate data foundation for subsequent code analysis, contribution statistics, and traceability issues.

[0029] This application can deduplicate several code commit records and then calculate the total number of remaining commit records after deduplication, as well as the original total number of commit records before deduplication. This comparison facilitates subsequent analysis of duplicate commits. Next, it is necessary to filter code commit records that have undergone large-scale automated generation, batch imports from third-party libraries, or changes due to full library refactoring. This is because, typically, the total number of lines changed in commit records generated in these scenarios (equal to additions + deletions) is very large. Therefore, this application can eliminate invalid code commit records that affect effective contributions by judging the total number of lines changed. A preset line count threshold can be configured for this judgment; the value can be 5000, 6000, or 4500, etc. The value can be set based on the developer's maximum code change volume in the historical records; this application does not specify a particular value. Then, the total number of lines of code changes for each deduplicated code commit is compared with a preset line-of-code threshold. Code commits with a total number of lines of code changes exceeding the preset line-of-code threshold are determined to be invalid code commits. After filtering these, the remaining commits are the valid code commits. Therefore, step 103, "filtering out valid code commits from deduplicated code commits," specifically includes the following sub-steps: Sub-step 1035: Identify the total number of lines of code changes corresponding to each code commit record after deduplication.

[0030] Sub-step 1036: Compare the total number of lines of code changed with the preset line of code threshold.

[0031] Sub-step 1037: Determine the code commit records whose total number of modified lines of code exceeds the preset code line number threshold as invalid code commit records.

[0032] Sub-step 1038: Delete invalid code submission records from the deduplicated code submission records to obtain valid code submission records.

[0033] The above steps effectively resolve the interference caused by large-volume commits resulting from non-human development activities such as large-scale formatting adjustments, automatic code generation, batch file replacement, or configuration migration on statistical and analytical results. This improves the accuracy and fairness of code contribution evaluation, allowing statistical results to more accurately reflect developers' effective work output; enhances the quality and interpretability of repository history, facilitating subsequent code reviews, issue tracing, and project health analysis; and significantly reduces the subjectivity and time cost of manual screening through automated threshold determination and cleanup.

[0034] This application can also mark invalid code commits as large commits. When filtering the deduplicated code commits, it can also count the total number of valid code commits after filtering, as well as the total number of invalid code commits (large commits) that were filtered out, facilitating subsequent analysis of the code commit filtering process.

[0035] When identifying the total number of lines of code changes for each deduplicated code commit record, this application first needs to identify the commit type of the code commit record. If it is a merge commit, it is necessary to identify the total number of lines of code changes for each sub-commit record of each commit branch, and then merge them to calculate the final total number of lines of code changes. If it is a separate commit (normal commit), the total number of lines of code changes for the code commit record can be calculated directly. This application sets up multiple determination methods to determine whether it is a merge commit. One method is to check the parent node identifier list field (parent_ids) in the code commit record and then identify the number of parent nodes under this field. If the number of parent nodes is greater than 1, it is determined to be a merge commit. Another method is to check whether the commit title of the code commit record contains preset keywords such as "Merge". If it does, it is determined to be a merge commit. A third method is to check whether the commit message of the code commit record contains target feature text such as "Merge branch", "Merge pullrequest", or "Merge remote-tracking". If it does, it is determined to be a merge commit. Any of the above determination methods can be used to classify the corresponding code commit record as a merged commit. Therefore, sub-step 1035 specifically includes the following steps: S01, detect the number of parent nodes, commit title, and commit message in the parent node identifier list field of each deduplicated code commit record.

[0036] S02, if the number of parent nodes, commit title, and commit message meet the preset conditions, then the commit type of the corresponding code commit record is determined to be a merge commit.

[0037] S03. If the number of parent nodes, commit title, and commit message do not meet the preset conditions, the commit type of the corresponding code commit record is determined to be a separate commit.

[0038] S04. For the target code commit record in the deduplicated code commit record, if the commit type of the target code commit record is a merge commit, then identify the total number of lines of code changes in each commit branch in the target code commit record.

[0039] S05, sum up the total number of lines of code changes in each commit branch, and use this sum as the total number of lines of code changes in the target commit record.

[0040] S06. If the commit type of the target code commit record is a separate commit, then directly identify the total number of lines of code changes in the target code commit record.

[0041] The above steps effectively solve the problem of inaccurate code change measurement caused by the inability of traditional statistics to identify the number of lines of code changes in each branch of a merged commit. This significantly improves the completeness and accuracy of code contribution statistics, ensuring that the total number of changes in a merged commit containing multiple independent development contents can be fully recorded and aggregated. At the same time, the multi-feature (number of parent nodes, commit title, and message) combination judgment mechanism reduces the reliance on a single feature and the risk of misjudgment, enhancing the reliability and adaptability of automatic code commit type identification. Finally, through differentiated statistical logic design, a more refined and reasonable measurement method for code contribution statistics is provided, which not only respects the actual process of development collaboration, but also lays a scientific data foundation for project auditing, contribution analysis, performance evaluation, and team collaboration management.

[0042] Among them, the number of parent nodes, the submission title, and the submission message meet the preset conditions as follows: the number of parent nodes is greater than 1, or the submission title of the submission record contains preset keywords, or the submission message contains target feature text.

[0043] Step 104: Identify the author names of valid code submission records to obtain garbled author names and normal author names.

[0044] Due to differences in development environment configurations, inconsistent character encodings, or legacy issues from system migrations, author names in valid code commit records may appear as garbled characters, affecting statistical results. Therefore, this application implements multiple detection methods to identify garbled author names. The first detection method involves pre-maintaining a list of garbled characters. This list contains multiple garbled characters. It checks whether the author's name in a valid code commit record contains one or more of these characters. If so, the author's name in that valid code commit record is determined to be a garbled author's name. The garbled character list in the preset list can be updated based on newly appearing garbled characters.

[0045] The second detection method involves pre-setting a regular expression with the pattern: / [^\w\s\u4e00-\u9fa5@.-]{2,} / . This regular expression is then used to determine if the author's name in a valid code submission record contains non-standard characters. If it does, the author's name in the valid code submission record is considered a garbled author's name. In the above regular expression, [^ ... ] is a negative character class, indicating that the regular expression matches any character not listed within the parentheses. {2,} is a quantifier, indicating that the preceding pattern (i.e., "illegal character") must appear at least twice consecutively to be matched. \w represents word characters (e.g., letters, numbers, underscores), \s represents whitespace characters (e.g., spaces, tabs, newlines), \u4e00-\u9fa5 represents Chinese characters (all commonly used Chinese characters), @ is the At symbol, . is the English period, and - is a hyphen. According to the regular expression above, if the author name is Zhang San_test, then there are no matching non-regular characters, so it can be determined as a normal author name. If the author name is abc##def, then because the "##" does not belong to any of the "\w\s\u4e00-\u9fa5@.-" characters and appears twice consecutively, it is determined that there are matching non-regular characters, so it can be determined as a garbled author name.

[0046] The third detection method involves pre-setting a regular expression with the pattern: / [\x00-\x1F\x7F] / . This regular expression is then used to determine if the author's name in a valid code submission record contains ASCII control characters. If it does, the author's name is considered garbled. In the regular expression, \x00-\x1F correspond to ASCII control characters 0-31, including: null character (NUL), newline (LF \n), carriage return (CR \r), tab (TAB \t), backspace (BS), and form feed (FF). \x7F corresponds to the delete character (DEL), ASCII character number 127. If these characters are matched, the author's name is determined to contain ASCII control characters and is therefore considered garbled.

[0047] Based on the above, step 104 specifically includes the following sub-steps, such as... Figure 2 As shown: Sub-step 1041: Using a preset list of garbled characters and a preset regular expression, determine whether the author's name of a valid code submission record contains at least one of garbled characters, unconventional characters, or ASCII control characters.

[0048] Sub-step 1042: If contained, then the author name of the valid code submission record is determined to be a garbled author name.

[0049] Sub-step 1043: If not included, then the author name of the valid code submission record is determined to be a normal author name.

[0050] The above steps, based on a pre-defined list of garbled characters and a regular expression rule mechanism, automatically detect and classify whether the author names in valid commit records contain abnormal content such as garbled characters, non-standard characters, or ASCII control characters. This effectively solves the problem of non-standard author information caused by incorrect development environment configuration, chaotic encoding formats, or legacy issues from tool imports. It ensures the accuracy of developer identification and data consistency, and avoids statistical distortion caused by the same developer being misidentified as multiple different contributors due to garbled names. It also improves the quality and readability of code repository metadata, providing a clean and reliable foundation of author information for project auditing, contribution analysis, performance evaluation, and team collaboration management.

[0051] Step 105: Group the valid code submission records by email address, use the normal author name of each group to fix the garbled author name in each group, and identify the main author name and non-main author name in each group.

[0052] This application assumes that each author uses one email address, but the names they use when developing code may differ. For example, Zhang San might use the names "Zhang San," "Zhang Gong," or "Zhang San 01." Therefore, this application groups valid code submission records by email address to achieve grouping of author names based on email address. Within each group, a mapping (dictionary) set—Map<email address, List<author name>>—is obtained, with email addresses as keys and a list of author names as values. This set contains both garbled and normal author names. The similarity between the garbled author names and each normal author name is calculated. Then, a target similarity score greater than a similarity threshold is selected. A recovery group is generated using the garbled and normal author names corresponding to the target similarity score. The garbled author names are then restored using the normal author names within the recovery group, i.e., the garbled author names within the recovery group are changed to normal author names within the group. Therefore, step 105, "grouping valid code submission records by email address and repairing garbled author names within each group using the normal author names of each group," specifically includes the following sub-steps: Sub-step 1051: Group the valid code submission records containing the same email address into a set of valid code submission records.

[0053] Sub-step 1052: Within each set of valid code commit records, identify the similarity between the garbled author name and the normal author name.

[0054] Sub-step 1053: Screen out the target similarity that is greater than the similarity threshold from the similarities.

[0055] Sub-step 1054: Identify the garbled author name and the normal author name corresponding to the target similarity, and modify the corresponding garbled author name to the corresponding normal author name.

[0056] For example, assume that in the valid code submission records corresponding to the email zhangsan@company.com, the following author names appear: ["张三", "zhangsan", "Zhang San", "??张三??", "?张?三?", "zhang san", "张三(临时账号)"]. Identify that "??张三??" and "?张?三?" are garbled author names, and "张三", "zhangsan", "Zhang San", "zhang san", "张三(临时账号)" are normal author names. The similarities between "??张三??" and the above normal author names are: 95%, 30%, 70%, 80% respectively. If the similarity threshold is 85%, because 95% > 85%, then "??张三??" is repaired to "张三".

[0057] Among them, if there are multiple target similarities greater than the similarity threshold, select the maximum similarity as the target similarity. The similarity threshold can be adjusted according to requirements, and this application does not make specific limitations. When repairing the garbled author name, if a garbled author name does not appear in any valid code submission record set, then this garbled author name is marked as irreparable.

[0058] The above steps implement the normalization processing of submission records grouped by email address. Specifically, by calculating the similarity between the garbled author name and the normal author name and screening out high-similarity pairs, the intelligent correction of the garbled author name is realized. Thus, it effectively solves the problem of contributor identity splitting caused by the same developer submitting code using different names (including abnormal encoding names), realizes the automatic merging and unification of the identities of the same developer's submission records, and significantly improves the accuracy and integrity of developer contribution statistics; through the similarity threshold mechanism, it ensures the reliability and accuracy of name correction, and avoids new errors that may be introduced by blind replacement; it enhances the standardization and consistency of code repository data, and provides a clear and reliable developer identity mapping relationship for project auditing, contribution analysis, performance evaluation, and team collaboration management.

[0059] After fixing the garbled author names, considering that an author may use one email address but different names during code development, to better track author code contributions, it's necessary to identify the main author name and non-main author names within each group of normal author names, and then aggregate their code contributions. Identifying the main author name and non-main author names involves counting the number of valid code commits for each normal author name, obtaining the total number of valid code commits, and identifying the normal author name with the highest total number of commits (most commits) as the main author name, and the rest as non-main author names. Therefore, step 105, "identifying the main author name and non-main author name within each group," specifically includes the following sub-steps: Sub-step 1055: Identify the total number of valid code submission records corresponding to each normal author name within each group.

[0060] Sub-step 1056: By identifying the maximum total number of entries, determine the main author name within each group.

[0061] Sub-step 1057: By identifying the non-maximum total number of entries, determine the non-primary author names within each group.

[0062] In identifying the main author's name, it can also be determined based on the total number of lines of code changes in the valid code commit records corresponding to each normal author's name, and the normal author's name with the largest total number of lines of code changes will be identified as the main author's name.

[0063] The above steps statistically analyze and compare the submission frequency of each normal author name, automatically identifying the main author's identity based on the maximum number of submissions. This effectively solves the technical problem of difficulty in determining the representative identity of a developer when submitting code using multiple standardized names (such as Chinese name, Pinyin, and English name). It achieves automated confirmation of the developer's primary identity, providing a clear and unified identity anchor for contribution aggregation and statistics. This improves the objectivity and accuracy of identifying core contributors in multi-naming scenarios and avoids statistical bias caused by the dilution of contribution values ​​due to name dispersion. Furthermore, by replacing subjective judgment with quantitative frequency comparison, it significantly improves the efficiency and reliability of the identity aggregation process.

[0064] Step 106: Add up the code modification information under the non-main author names and the main author names in each group to obtain the code contribution statistics of the main author names for each group.

[0065] The code modification information in this application includes `additions` (number of lines added), `deletions` (number of lines deleted), `commits` (number of commits), and `total_changes` (total number of lines changed). When accumulating the changes, the code modification information is first calculated from all valid commit records containing names other than the main author's name, resulting in a first accumulated code modification information set, including first accumulated `additions`, first accumulated `deletions`, first accumulated `commits`, and first accumulated `total_changes`. Then, the code modification information is calculated from all valid commit records containing the main author's name, resulting in a second accumulated code modification information set, including second accumulated `additions`, second accumulated `deletions`, second accumulated `commits`, and second accumulated `total_changes`. The code modification information from the first accumulation and the code modification information from the second accumulation are then accumulated again to obtain the code contribution statistics of the main author. The code contribution statistics of the main author include the final accumulated additions (first accumulated additions + second accumulated additions), the final accumulated deletions (first accumulated deletions + second accumulated deletions), the final accumulated commits (first accumulated commits + second accumulated commits), and the final accumulated total_changes (first accumulated total_changes + second accumulated total_changes).

[0066] This application retains merge information for each main author, including mergedFrom: a list of non-author names being merged, totalMergedCommits: the final cumulative number of commits, totalMergedAdditions: the final cumulative number of newly added lines of code, and totalMergedChanges: the final cumulative number of lines of code changes.

[0067] Because existing technologies lack the ability to perform statistical analysis based on time periods such as natural months or quarters, making trend analysis and periodic assessment difficult, this application sets up an algorithm for time-based statistics. Taking statistical analysis based on the time dimension grouped by natural months as an example, the range of months to be analyzed can be set first, such as the starting month January and the ending month October. Then, a month iterator is created, starting from the starting month and increasing by one month with each iteration until the ending month is reached, generating a list of months: [2025-01, 2025-02, ..., 2025-10]. For each month, time boundaries need to be set, with the first day of the month 00:00:00 as the start time and the last day of the month 23:59:59 as the end time. Then, all code commit records within each month are obtained, and after executing the above code statistical method, a monthly data summary is output. The data content can be a hierarchical statistical data structure by month, such as { "2025-01": { contributors: {...}, / / Contributor statistics for this month garbledAuthors: {...}, / / Authors of the garbled text this month mergeDetails: {...}, / / Merge details for this month projects: [...] / / Projects involved this month } After obtaining the monthly data, this application can sort the authors based on the commits (number of commits), additions (number of new lines of code), and total_changes (total number of lines of code changed, including additions and deletions) within the monthly data. The sorting can be either ascending or descending.

[0068] This application can also generate reports in various formats based on the summarized monthly data, such as console text reports, JSON data files, Excel spreadsheets, and hierarchical sheet-structured Excel reports. The hierarchical sheet-structured Excel report can have the following structure: Monthly statistical mode: Sheet 1-N: [Month] Monthly Statistics Column structure: [Author|Email|Commit count|New row|Deleted row|Total changes|Number of branches|Number of projects|Branch list|Status] Sheet N+1: Monthly Summary Column structure: [Month|Total Submissions|New Rows|Deleted Rows|Total Changes|Number of Contributors|Number of Authors with Garbled Text] Sheet N+2: Author Details of the Garbled Text Column structure: [Month|Author of garbled text|Email|Number of commits|New rows|Total changes|Number of projects] Sheet N+3: Mailbox Merge Details Column structure: [Month|Main Author|Number of Authors Merged|Number of Merged Submissions|New Rows Added in Merged|Changes in Merged|List of Authors Merged].

[0069] The system architecture used in the code statistics method of this application is as follows: Figure 3 As shown, it includes a user interface layer, an API interface layer, and a core processing layer. The core processing layer includes a project management module, a submission processing module, an author identification module, a statistical analysis module, a report generation module, and a data storage layer. The data storage layer includes a cache database and file storage. At the user interface layer, users can input group ID, branch name to be queried, time boundary, configure preset line count threshold, etc. The API interface layer can call the GitLab API to obtain raw data and also provide interfaces between various modules of the core processing layer. The project management module is used to recursively obtain all projects and subgroups under the multi-level group to be counted through the GitLab API and obtain project information. The commit processing module is used to deduplicate based on commit hash value, filter invalid code commit records by comparing with preset line count threshold, identify commit type, etc. The author identification module is used to identify garbled author names and normal author names, group authors based on email, calculate name similarity, identify main author name and non-main author name, etc. The statistical analysis module is used to determine the code statistical contribution of the main author name, perform statistics by time dimension, etc. The report generation module is used to generate reports in various formats. The data storage layer is used to cache intermediate data and store generated reports.

[0070] The code statistics method provided in this application firstly addresses the issue of incomplete statistics caused by missing projects or levels in complex scenarios with multiple projects and multiple levels by obtaining project information from several projects under a multi-level group to be counted. It then filters valid branches from several projects using project information and a preset branch list, and extracts several code commit records carrying commit hash values ​​from these valid branches. These commit records contain author names, email addresses, and code modification information. This not only avoids the problem of duplicate statistics caused by the same code appearing in different branches, but also lays a data foundation for subsequent deep cleaning and aggregation by extracting key data such as commit hashes, author names, email addresses, and code modification information from the records. Finally, it uses commit hash values ​​to deduplicate the code commit records, ensuring that the same code change is counted only once, regardless of how many groups, projects, or branches it appears in, thus eliminating duplicate calculations. The method then filters out the valid code commit records after deduplication. It can eliminate interference from non-human code changes, making the statistical results more focused on genuine contributions. It identifies the author names of valid code commit records, obtaining garbled author names and normal author names. Valid code commit records are grouped by email address, and the normal author names of each group are used to correct garbled author names within their respective groups, achieving cleanliness and normalization of author information. This solves the problem of the same developer's contributions being scattered among multiple virtual authors and unable to be accurately aggregated due to garbled characters or inconsistent naming. It identifies the main author name and non-main author names within each group, and accumulates the code modification information under the non-main author names and the main author names in each group to obtain the code contribution statistics of the main author name for each group. It achieves accurate statistics of code contribution in complex environments with multi-level groups and multiple branches, providing reliable and fair data support for performance evaluation and resource allocation, and significantly improving the scientific and fair nature of management decisions.

[0071] Reference Figure 4 The diagram shows a structural schematic of a code counting device provided in this application. The device includes: The first acquisition module 201 is used to acquire project information of several projects under the multi-level group to be counted.

[0072] The first filtering module 202 is used to filter valid branches in several projects based on project information and a preset branch list, and extract several code commit records carrying commit hash values ​​from the valid branches. The code commit records contain author names, email addresses and code modification information.

[0073] The deduplication filtering module 203 is used to deduplicatize several code commit records using the commit hash value, and then filter out the valid code commit records from the deduplicated code commit records.

[0074] The author name recognition module 204 is used to identify the author names of valid code submission records, and obtain garbled author names and normal author names.

[0075] The group repair module 205 is used to group valid code submission records by email address, repair garbled author names in each group using the normal author names in each group, and identify the main author name and non-main author names in each group.

[0076] The accumulation module 206 is used to accumulate the code modification information under the non-main author names and the main author names in each group to obtain the code statistical contribution of the main author names corresponding to each group.

[0077] Optionally, the deduplication filtering module 203 includes: The first comparison submodule is used to compare the commit hash values ​​of several code commit records.

[0078] The first grouping submodule is used to group code commit records with the same commit hash value into a group, resulting in several sets of duplicate code commit records.

[0079] The first identification submodule is used to identify the submission time of each code submission record in the set of duplicate code submission records, and to determine the non-first code submission records in the set of duplicate code submission records based on the submission time.

[0080] The first deletion submodule is used to delete non-first code commit records in each set of duplicate code commit records.

[0081] The second identification submodule is used to identify the total number of lines of code changes corresponding to each code commit record after deduplication.

[0082] The second comparison submodule is used to compare the total number of lines of code changed with a preset line of code threshold.

[0083] The invalid record determination submodule is used to determine code commit records whose total number of modified lines exceeds a preset code line threshold as invalid code commit records.

[0084] The second deletion submodule is used to delete invalid code submission records from the deduplicated code submission records to obtain valid code submission records.

[0085] Optionally, the second identification submodule includes: The detection unit is used to detect the number of parent nodes, the commit title, and the commit message in the parent node identifier list field of each deduplicated code commit record.

[0086] The first determination unit is used to determine that the commit type of the corresponding code commit record is a merge commit if the number of parent nodes, the commit title, and the commit message meet the preset conditions.

[0087] The second determination unit is used to determine that the submission type of the corresponding code submission record is a separate submission if the number of parent nodes, the submission title, and the submission message do not meet the preset conditions.

[0088] The first identification unit is used to identify the total number of lines of code changes in each commit branch of the target code commit record if the commit type of the target code commit record is a merge commit.

[0089] The accumulation unit is used to accumulate the total number of lines of code changes in each commit branch, which is then used as the total number of lines of code changes in the target commit record.

[0090] The second identification unit is used to directly identify the total number of lines of code changes in the target code commit record if the commit type of the target code commit record is a separate commit.

[0091] Optionally, the author name recognition module 204 includes: The judgment submodule is used to determine whether the author name of a valid code submission record contains at least one of the following: garbled characters, unconventional characters, or ASCII control characters, based on a preset list of garbled characters and a preset regular expression.

[0092] The first name determination submodule is used to determine if the author name of a valid code submission record is a garbled author name if it is contained within the specified name.

[0093] The second name determination submodule is used to determine the author name of a valid code submission record as a normal author name if it is not included.

[0094] Optionally, the group repair module 205 includes: The second grouping submodule is used to group valid code submission records containing the same email address into a set of valid code submission records.

[0095] The third identification submodule is used to identify the similarity between the garbled author name and the normal author name within each valid code commit record set.

[0096] The filtering submodule is used to filter out target similarities that are greater than the similarity threshold from the similarity scores.

[0097] The fourth identification submodule is used to identify the garbled author names and normal author names corresponding to the target similarity, and to modify the corresponding garbled author names to the corresponding normal author names.

[0098] The fifth identification submodule is used to identify the total number of valid code submission records corresponding to each normal author name within each group.

[0099] The main author determination submodule is used to determine the main author name within each group by identifying the maximum total number of entries.

[0100] The Non-Primary Author Determination Submodule is used to determine the names of non-primary authors within each group by identifying non-maximum total entries.

[0101] The code statistics device provided in this application first solves the problem of incomplete statistics caused by missing projects or levels in complex scenarios with multiple projects and multiple levels by obtaining project information from several projects under a multi-level group to be counted. It then filters valid branches from several projects using project information and a preset branch list, and extracts several code commit records carrying commit hash values ​​from these valid branches. These commit records contain author names, email addresses, and code modification information. This not only avoids the problem of duplicate statistics caused by the same code appearing in different branches, but also lays a data foundation for subsequent deep cleaning and aggregation by extracting key data such as commit hashes, author names, email addresses, and code modification information from the records. Finally, it uses commit hash values ​​to deduplicate the code commit records, ensuring that the same code change is counted only once, regardless of how many groups, projects, or branches it appears in, thus eliminating duplicate calculations. The device then filters out the valid code commit records from the deduplicated ones. It can eliminate interference from non-human code changes, making the statistical results more focused on genuine contributions. It identifies the author names of valid code commit records, obtaining garbled author names and normal author names. Valid code commit records are grouped by email address, and the normal author names of each group are used to correct garbled author names within their respective groups, achieving cleanliness and normalization of author information. This solves the problem of the same developer's contributions being scattered among multiple virtual authors and unable to be accurately aggregated due to garbled characters or inconsistent naming. It identifies the main author name and non-main author names within each group, and accumulates the code modification information under the non-main author names and the main author names in each group to obtain the code contribution statistics of the main author name for each group. It achieves accurate statistics of code contribution in complex environments with multi-level groups and multiple branches, providing reliable and fair data support for performance evaluation and resource allocation, and significantly improving the scientific and fair nature of management decisions.

[0102] Reference Figure 5 This application also provides an electronic device, such as Figure 5 As shown, it includes a processor 301, a communication interface 302, a memory 303, and a communication bus 304, wherein the processor 301, the communication interface 302, and the memory 303 communicate with each other through the communication bus 304. Processor 301, memory 303 for storing processor-executable instructions; The processor 301 is configured to execute the instructions to implement the code statistics method described above: Obtain project information for several projects under a multi-level group to be analyzed; The project information and the preset branch list are used to filter the valid branches of several projects, and a number of code commit records carrying commit hash values ​​are extracted from the valid branches. The code commit records include the author's name, email address and code modification information. After deduplicating several code commit records using the commit hash value, the valid code commit records in the deduplicated code commit records are filtered out. The author names of the valid code submission records are identified to obtain garbled author names and normal author names; The valid code submission records are grouped by the email address, and the garbled author names in each group are repaired using the normal author names in each group. At the same time, the main author name and non-main author names in each group are identified. The code modification information under the names of non-main authors and main authors in each group is summed to obtain the code contribution statistics of the main author names for each group.

[0103] The communication bus mentioned above can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0104] The communication interface is used for communication between the aforementioned terminal and other devices.

[0105] The memory may include random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0106] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0107] In another embodiment provided in this application, a computer-readable storage medium is also provided, which stores instructions that, when run on a computer, cause the computer to execute any of the code statistics methods described in the above embodiments.

[0108] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., a solid-state drive (SSD)).

[0109] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0110] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0111] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application are included within the scope of protection of this application.

Claims

1. A code statistics method, characterized in that, The method includes: Obtain project information for several projects under a multi-level group to be analyzed; The project information and the preset branch list are used to filter the valid branches of several projects, and a number of code commit records carrying commit hash values ​​are extracted from the valid branches. The code commit records include author name, email address and code modification information. After deduplicating several code commit records using the commit hash value, the valid code commit records in the deduplicated code commit records are filtered out. The author names of the valid code submission records are identified to obtain garbled author names and normal author names; The valid code submission records are grouped by the email address, and the garbled author names in each group are repaired using the normal author names in each group. At the same time, the main author name and non-main author names in each group are identified. The code modification information under the names of non-main authors and main authors in each group is summed to obtain the code contribution statistics of the main author names for each group.

2. The method according to claim 1, characterized in that, The process of deduplicating multiple code commit records using commit hash values ​​includes: Compare the commit hashes of several code commit records; Group code commit records with the same hash value into a group to obtain several sets of duplicate code commit records; Identify the submission time of each code submission record in the set of duplicate code submission records, and determine the non-first code submission records in the set of duplicate code submission records based on the submission time; Delete non-first code commit records from each set of duplicate code commit records.

3. The method according to claim 1, characterized in that, The valid code commit records in the filtered deduplicated code commit records include: After deduplication, the total number of lines of code changes corresponding to each code commit is identified and recorded. The total number of lines of code changed is compared with a preset threshold for the number of lines of code. Code commits with a total number of lines of code changes exceeding a preset threshold are deemed invalid. After deduplication, invalid code commit records are deleted to obtain valid code commit records.

4. The method according to claim 3, characterized in that, The total number of lines of code changes corresponding to each code commit record after deduplication also includes: Detect the number of parent nodes, commit title, and commit message in the parent node identifier list field of each deduplicated code commit record; If the number of parent nodes, the commit title, and the commit message meet the preset conditions, then the commit type of the corresponding code commit record is determined to be a merge commit; If the number of parent nodes, the commit title, and the commit message do not meet the preset conditions, then the commit type of the corresponding code commit record is determined to be a single commit. For the target code commit record in the deduplicated code commit record, if the commit type of the target code commit record is a merge commit, then identify the total number of lines of code changes in each commit branch in the target code commit record; The total number of lines of code changes in each commit branch is summed up to obtain the total number of lines of code changes in the target code commit record. If the commit type of the target code commit record is a single commit, then the total number of lines of code changes in the target code commit record is directly identified.

5. The method according to claim 1, characterized in that, The process of identifying the author names of the valid code submission records yields both garbled author names and normal author names, including: By using a preset list of garbled characters and a preset regular expression, it is determined whether the author's name of the valid code submission record contains at least one of garbled characters, unconventional characters, or ASCII control characters; If it is included, then the author name of the valid code submission record is determined to be a garbled author name; If not included, the author name of the valid code submission record is determined to be a normal author name.

6. The method according to claim 1, characterized in that, The process of grouping the valid code submission records by the email address and then using the normal author names of each group to correct the garbled author names within that group includes: The valid code submission records containing the same email address are grouped together to obtain a set of valid code submission records; Within each set of valid code commit records, identify the similarity between the garbled author's name and the normal author's name; Filter out target similarities greater than the similarity threshold from the similarity scores; Identify the garbled author names and normal author names corresponding to the target similarity, and modify the corresponding garbled author names to the corresponding normal author names.

7. The method according to claim 6, characterized in that, The identification of the main author's name and non-main author's names within each group includes: Identify the total number of valid code submission records corresponding to each normal author name within each group; The main author name within each group is determined by identifying the maximum total number of entries; By identifying non-maximum total number of entries, the names of non-primary authors within each group are determined.

8. A code counting device, characterized in that, The device includes: The first acquisition module is used to acquire project information of several projects under the multi-level group to be statistically analyzed. The first filtering module is used to filter valid branches in several projects through the project information and the preset branch list, and extract several code commit records carrying commit hash values ​​from the valid branches. The code commit records include author name, email address and code modification information. The deduplication filtering module is used to deduplicate several code commit records using the commit hash value, and then filter out the valid code commit records from the deduplicated code commit records. The author name recognition module is used to identify the author names of the valid code submission records and obtain garbled author names and normal author names; The group repair module is used to group the valid code submission records by the email address, repair the garbled author names in each group using the normal author names in each group, and identify the main author name and non-main author names in each group. The accumulation module is used to accumulate the code modification information under the names of non-main authors and main authors in each group to obtain the code contribution statistics of the main author names for each group.

9. An electronic device, characterized in that, include: processor; Memory used to store processor-executable instructions; The processor is configured to execute the instructions to implement the code statistics method as described in any one of claims 1 to 7.

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

Images