Git multi-warehouse branch batch statistics and automatic management method and device

Abstract

The invention belongs to the field of distributed version control, and relates to a Git multi-warehouse branch batch statistics and automatic management method and device, computer equipment and a storage medium, and the method comprises the steps: deploying a Shell warehouse branch management script at a terminal, and providing a consistent interaction interface for a user; obtaining a terminal warehouse path and a directory to be scanned under the warehouse path; traversing all Git warehouses under the catalogue to be scanned, acquiring a target branch and a reference branch in each Git warehouse, and comparing whether the target branch is merged with the reference branch or not; displaying the merging state of each warehouse and each target branch, classifying and listing Git warehouses with unmerged branches, and outputting a Git warehouse state statistical result; obtaining Git warehouse branches needing to be merged, configuring a merging strategy, and generating a merging plan; and executing a merging operation, and pushing a merging result to a remote warehouse. And the management efficiency of multi-Git warehouse branch merging can be greatly improved.

Description

Technical Field

[0001] This invention relates to the field of distributed version control technology, and in particular to a method, apparatus, computer equipment, and storage medium for batch statistics and automated management of Git multi-repository branches. Background Technology

[0002] With the ever-expanding scale of software development projects and the widespread adoption of the distributed version control system Git, modern software development teams often need to manage dozens or even hundreds of Git repositories. Each repository contains multiple branches for different purposes such as parallel development, functional testing, and version release. In large-scale project management, development teams frequently face the following challenges:

[0003] The number of branches has increased dramatically: As the project iterates, the number of branches in each repository grows rapidly, including the main branch, development branches, iteration branches, and fix branches, resulting in an exponential increase in management complexity.

[0004] Branch status is difficult to track: Developers have difficulty keeping up with the latest status of branches in various repositories, including key information such as branch creation relationships, merge status, and whether they have been deprecated.

[0005] Serious waste of resources: A large number of branches that have been developed or have not been maintained for a long time still exist in the repository, occupying storage space and bandwidth resources, and affecting repository performance.

[0006] Inefficient batch management: Existing Git tools are mainly designed for single repository operations and lack an effective batch processing mechanism, resulting in inefficiency when managing a large number of repository branches. Summary of the Invention

[0007] To address the aforementioned technical problems, this invention provides a method for batch statistics and automated management of multiple Git repository branches, employing the following technical solution:

[0008] Deploy the Shell repository branch management script in the terminal to provide users with a consistent interactive interface;

[0009] Obtain the terminal repository path and the directories to be scanned under the repository path;

[0010] Iterate through all Git repositories in the directory to be scanned, obtain the target branch and reference branch in each Git repository, and compare whether the target branch has merged the reference branch.

[0011] Displays the merge status of each repository and each target branch, lists the Git repositories with unmerged branches by category, and outputs Git repository status statistics.

[0012] Based on the Git repository status statistics, obtain the Git repository branches that need to be merged, configure the merge strategy, and generate a merge plan;

[0013] Perform the merge operation according to the merge plan and push the merge results to the remote repository.

[0014] Preferably, the step of deploying the Shell repository branch management script on the terminal to provide users with a consistent interactive interface specifically includes:

[0015] Obtain the number of warehouses to be monitored, branch types, statistical indicators, and automated management tasks;

[0016] Based on the number of repositories to be monitored, branch types, statistical metrics, and automated management tasks obtained, create a shell script for batch statistics and management of Git repository branches;

[0017] The created shell script is deployed to the user's terminal to provide a consistent interactive interface.

[0018] Preferably, the step of obtaining the terminal repository path and the directory to be scanned under the repository path specifically includes:

[0019] Obtain the terminal repository path;

[0020] Obtain the directories to be scanned under the specified repository path.

[0021] Preferably, the step of traversing all Git repositories in the directory to be scanned, obtaining the target branch and reference branch in each Git repository, and comparing whether the target branch has merged with the reference branch specifically includes:

[0022] Iterate through all Git repositories in the directory to be scanned;

[0023] Get the target branch and reference branch in each Git repository;

[0024] Compare whether the target branch has been merged with the reference branch.

[0025] Preferably, the steps of displaying the merge status of each repository and each target branch, classifying and listing Git repositories with unmerged branches, and outputting Git repository status statistics specifically include:

[0026] Displays the merge status of each repository and each target branch;

[0027] The list categorizes and lists Git repositories with unmerged branches;

[0028] Output the Git repository status statistics.

[0029] Preferably, the steps of obtaining the Git repository branches to be merged based on the Git repository status statistics, configuring the merge strategy, and generating the merge plan specifically include:

[0030] Based on the Git repository status statistics, obtain the Git repository branches that need to be merged;

[0031] Configure the merge strategy according to the Git repository branches to be merged;

[0032] Generate a merger plan based on the merger strategy.

[0033] Preferably, the step of performing the merge operation according to the merge plan and pushing the merge result to the remote repository specifically includes the following steps:

[0034] The merger process will be carried out step by step in accordance with the merger plan;

[0035] Monitor conflicts during the merge process;

[0036] Push the merge results to the remote repository.

[0037] To address the aforementioned technical problems, this invention also provides a Git multi-repository branch batch statistics and automated management device, which employs the following technical solution, including:

[0038] The deployment module is used to deploy Shell repository branch management scripts to the terminal, providing users with a consistent interactive interface.

[0039] The acquisition module is used to acquire the terminal repository path and the directories to be scanned under the repository path;

[0040] The traversal module is used to traverse all Git repositories in the directory to be scanned, obtain the target branch and reference branch in each Git repository, and compare whether the target branch has merged the reference branch.

[0041] The output module is used to display the merge status of each repository and each target branch, categorize and list Git repositories with unmerged branches, and output Git repository status statistics.

[0042] The generation module is used to obtain the Git repository branches that need to be merged based on the Git repository status statistics, configure the merge strategy, and generate a merge plan;

[0043] The push module is used to execute merge operations according to the merge plan and push the merge results to the remote repository.

[0044] To address the aforementioned technical problems, the present invention also provides a computer device that employs the technical solution described below, comprising a memory and a processor. The memory stores computer-readable instructions, and the processor executes the computer-readable instructions to implement the steps of the aforementioned Git multi-repository branch batch statistics and automated management method.

[0045] To address the aforementioned technical problems, the present invention also provides a computer-readable storage medium, which employs the technical solution described below. The computer-readable storage medium stores computer-readable instructions, which, when executed by a processor, implement the steps of the aforementioned Git multi-repository branch batch statistics and automated management method.

[0046] Compared with existing technologies, this invention has the following main advantages: By running a Shell script in the terminal, it scans multiple Git repositories under a specified directory and counts the merging status of each target branch relative to the reference branch in each repository; it automatically determines whether each branch exists and whether it should be merged; when an unmerged branch is found, it prompts the user whether to perform automatic merging and provides a choice of batch or individual repository merging strategies; it executes the merging operation sequentially according to the user-confirmed merging plan; after the merging is completed, it selects whether to push the merging results to their respective remote repositories based on the configuration; finally, it outputs detailed merging and push results and prompts possible errors (such as remote repository access failure); it can significantly improve the management efficiency of merging branches of multiple Git repositories; it reduces the error rate of manual branch merging; the automated operation reduces operational complexity and improves the consistency of the overall continuous integration process; it achieves unified statistics and transparency of the status of each repository branch, facilitating project management; and it supports flexible merging and push strategies to adapt to different project processes. Attached Figure Description

[0047] To more clearly illustrate the solutions in this invention, the accompanying drawings used in the description of the embodiments of this invention will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0048] Figure 1 This is a flowchart of an embodiment of the Git multi-repository branch batch statistics and automated management method of the present invention;

[0049] Figure 2 This is a schematic diagram of an embodiment of the Git multi-repository branch batch statistics and automated management device of the present invention;

[0050] Figure 3 This is a schematic diagram of the structure of one embodiment of the computer device of the present invention. Detailed Implementation

[0051] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains; the terminology used herein in the specification is for the purpose of describing particular embodiments only and is not intended to limit the invention; the terms "comprising" and "having," and any variations thereof, in the specification, claims, and foregoing drawings are intended to cover non-exclusive inclusion. The terms "first," "second," etc., in the specification, claims, or foregoing drawings are used to distinguish different objects and not to describe a particular order.

[0052] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0053] To enable those skilled in the art to better understand the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings.

[0054] It should be noted that the Git multi-repository branch batch statistics and automated management method provided in the embodiments of the present invention is generally executed by a server / terminal device, and correspondingly, the Git multi-repository branch batch statistics and automated management device is generally set in the server / terminal device.

[0055] Git, short for Git version control system, uses a distributed version control approach, allowing developers to manage code versions locally, including operations such as committing, branching, and merging, and then synchronize changes to a remote repository. Git is characterized by its efficiency, stability, and flexibility. With Git, teams can collaborate more efficiently, track every code change, and ensure the smooth progress of projects.

[0056] It should be understood that the number of terminal devices, networks, and servers is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be used.

[0057] Example 1

[0058] Please refer to Figure 1 The flowchart illustrates an embodiment of the Git multi-repository branch batch statistics and automated management method of the present invention. The Git multi-repository branch batch statistics and automated management method includes the following steps:

[0059] Step S1: Deploy the Shell repository branch management script on the terminal to provide users with a consistent interactive interface.

[0060] In this embodiment, the electronic device (e.g., server / terminal device) on which the Git multi-repository branch batch statistics and automated management method runs can receive Git multi-repository branch batch statistics and automated management requests via wired or wireless connection. It should be noted that the aforementioned wireless connection methods may include, but are not limited to, 3G / 4G / 5G connections, WiFi connections, Bluetooth connections, WiMAXX connections, Zigbee connections, UWB (ultra wideband) connections, and other currently known or future known wireless connection methods.

[0061] Shell repository branch management scripts are tools written in the Shell scripting language used to automate the management of branches in a code repository. These scripts integrate with version control systems (such as Git) and can perform operations such as creating, switching, merging, and deleting branches. Through Shell scripts, developers can manage project branches efficiently and accurately, reducing errors from manual operations and improving development efficiency. Furthermore, these scripts can be used in conjunction with continuous integration / continuous deployment (CI / CD) processes to automate code testing, building, and deployment, thereby further ensuring code quality and project delivery speed.

[0062] In this embodiment, step S1, deploying the Shell repository branch management script on the terminal to provide users with a consistent interactive interface, may specifically include the following steps:

[0063] S11 retrieves the number of warehouses to be monitored, branch types, statistical metrics, and automated management tasks.

[0064] The user interface can be used to collect users' specific needs for Git repository branch management, clarify the monitoring scope, and determine the number of Git repositories that need to be monitored, including private and public repositories.

[0065] Then define the branch types. Based on the user's business needs, clarify the types of branches that need to be monitored, such as the main branch, feature branches, and release branches.

[0066] Set statistical indicators and determine the indicators that need to be statistically analyzed, such as branch activity, merge conflict rate, code commit frequency, etc.

[0067] Plan automated management tasks based on the user's actual needs, such as automatically merging branches, deleting expired branches, and alerting users to branch merge conflicts.

[0068] S12 creates a shell script for batch statistics and management of Git repository branches based on the number of repositories to be monitored, branch types, statistical indicators, and automated management tasks obtained.

[0069] Design the script, and design the overall architecture of the script according to the requirements, including variable definition, function implementation, flow control, etc.

[0070] Integrate Git commands into scripts, such as `git clone`, `git fetch`, `git branch`, and `git merge`, to enable batch branch operations.

[0071] Implement statistical functions, utilizing the text processing capabilities of Shell scripts to calculate and display statistical indicators, such as extracting and analyzing Git logs using tools like `grep`, `awk`, and `sed`.

[0072] To automate management, write corresponding script logic based on the planned automated management tasks, such as periodically checking branch status and automatically performing merge or delete operations.

[0073] Implement error handling and logging: Add error handling and logging functionality to the script to improve its robustness and maintainability.

[0074] S13 deploys the created Shell script to the user's terminal, providing the user with a consistent interactive interface.

[0075] Script packaging and distribution: Package Shell scripts into an executable binary file or compressed package and distribute them to users via email, cloud storage, or internal file servers.

[0076] Deploy the created Shell script in the terminal, guide the user to unzip or install the script on the terminal, and set the necessary execution permissions.

[0077] Design the user interface to provide a clear and concise interface for users, including menu options, command prompts, and output results. This can be achieved by adding `echo` statements, `read` commands, and `case` statements to the script.

[0078] Furthermore, the Shell scripts can be continuously updated and maintained based on user feedback and changes in needs, ensuring that they always meet the actual needs of users.

[0079] Step S2: Obtain the terminal repository path and the directories to be scanned under the repository path.

[0080] In this embodiment, step S2, obtaining the terminal repository path and the directory to be scanned under the repository path, may specifically include the following steps:

[0081] S21, Get the terminal repository path.

[0082] The terminal repository path can be obtained by the user through either a command-line interface (CLI) or a graphical user interface (GUI), which is simple and direct. Different implementations adapt to different use cases, providing a flexible path acquisition mechanism.

[0083] Alternatively, the terminal repository path can be obtained by reading a configuration file. A configuration file containing repository path information can be preset in the application or script. When the program runs, it automatically reads the configuration file to obtain the path. This method reduces the need for manual input by the user and increases the level of automation.

[0084] The terminal repository path can also be obtained through environment variables. By setting the repository path as a system or user-level environment variable, the program retrieves the path by reading these environment variables. This method is suitable for scenarios where multiple programs or scripts share the same repository path. A proper path acquisition mechanism can avoid potential security risks, such as path traversal attacks.

[0085] The terminal repository path can also be obtained through a default path setting. If the repository is usually located in a fixed location, the program can preset a default path and prompt the user for input or perform other actions if the path does not exist. A unified path management method facilitates later maintenance and path updates, resulting in strong maintainability.

[0086] S22, obtain the directory to be scanned under the repository path.

[0087] The user can obtain the explicitly specified directory name or relative path to be scanned via a command-line interface (CLI) or a graphical user interface (GUI). This method is simple and straightforward, but requires the user to know the exact directory to be scanned. Different implementations can precisely locate the directory to be scanned according to requirements, avoiding unnecessary scanning and accidental operations.

[0088] You can also use pattern matching to retrieve the directories to be scanned under the repository path. Provide a pattern for the directory names (such as a regular expression or wildcard), and the program will automatically match and retrieve directories that meet the criteria. This method is suitable when directory names follow a certain pattern. By using pattern matching or configuration file queries, you can quickly obtain a list of directories to be scanned, improving scanning efficiency.

[0089] Alternatively, recursive scanning can be used to obtain the directories to be scanned under the repository path. Starting from the repository path, all subdirectories are scanned recursively, and the required directories are filtered based on conditions (such as file type, directory name, etc.). This method can provide comprehensive coverage, but may consume more resources.

[0090] The directories to be scanned under the repository path can also be obtained through configuration files or database queries. Information about the directories to be scanned is recorded in the configuration file or database, and the program retrieves the directories by querying these records. This method is suitable for scenarios with complex or frequently changing directory structures. For large repositories or constantly changing directory structures, recording the scanned directories through configuration files or databases offers good scalability.

[0091] Users can flexibly customize the scanned catalog according to their own needs to meet different scanning requirements.

[0092] Step S3: Traverse all Git repositories in the directory to be scanned, obtain the target branch and reference branch in each Git repository, and compare whether the target branch has merged the reference branch.

[0093] In this embodiment, step S3, which involves traversing all Git repositories in the directory to be scanned, obtaining the target branch and reference branch in each Git repository, and comparing whether the target branch has merged with the reference branch, may specifically include the following steps:

[0094] S31, iterate through all Git repositories in the directory to be scanned.

[0095] First, traverse the directory: Use the directory traversal functionality provided by the programming language (such as Python, Bash, etc.) to recursively access all subdirectories under the specified directory. This can be achieved through APIs provided by the operating system or third-party libraries. For example, in Python, you can use the `os.walk()` function from the `os` module, while in Bash, you can use the `find` command.

[0096] Git repository identification: During the traversal, check each directory for identifying files that identify a Git repository (such as the `.git / ` directory). If such a directory is found, it can be confirmed that the directory is a Git repository.

[0097] Record repository path: Record the identified Git repository path for later processing.

[0098] In some optional implementations of this embodiment, the following Python example code is used:

[0099] Python

[0100] import os

[0101] def find_git_repos(root_dir):

[0102] git_repos=[]

[0103] for dirpath,dirnames,filenames in os.walk(root_dir):

[0104] if.gitin filenames:

[0105] git_repos.append(dirpath)

[0106] return git_repos

[0107] root_directory= / path / to / scan

[0108] git_repositories=find_git_repos(root_directory)

[0109] for repo in git_repositories:

[0110] print(fFound Git repository:{repo})

[0111] Here is an example of Bash code:

[0112] bash

[0113] ! / bin / bash

[0114] root_directory= / path / to / scan

[0115] find$root_directory-type d-name.git-exec dirname{};|sort-u

[0116] The benefits of step S1 are:

[0117] (1) High degree of automation: Through automated scripts, a large number of directories can be quickly traversed and all Git repositories can be identified, greatly saving the time of manual searching.

[0118] (2) High scalability: The logic of directory traversal and Git repository identification is independent and can be easily modified or extended to adapt to different directory structures or identification conditions.

[0119] (3) Reduces errors: Automation reduces the possibility of human error and ensures that all relevant warehouses are correctly identified and processed.

[0120] (4) High flexibility: Implemented using programming and scripting languages, it can be easily integrated into larger automated processes or continuous integration / continuous deployment (CI / CD) pipelines as needed.

[0121] S32 retrieves the target branch and reference branch for each Git repository.

[0122] Cloning or opening a Git repository: For each identified Git repository, you can choose to clone the repository (if it's not already on your local machine) or use the local repository path. In Python, you can use the `GitPython` library to manipulate Git repositories.

[0123] Get a list of branches: Use Git commands or library functions to list all local branches. In the Git command line, you can use the `git branch` command, while in `GitPython`, you can access them through the `repo.branches` property.

[0124] Identify target branches (such as master, develop, feature / 202506, etc.) and reference branches (such as feature / 202505): Identify target branches and reference branches from the branch list according to predefined branch naming rules or configuration files.

[0125] In some optional implementations of this embodiment, Python is used, and the GitPython example code is as follows:

[0126] Python

[0127] from git import Repo

[0128] def get_branches(repo_path,target_branch_name,reference_branch_name):

[0129] repo = Repo(repo_path)

[0130] branches={branch.name for branch in repo.branches}

[0131] target_branch=branches.get(target_branch_name)

[0132] reference_branch=branches.get(reference_branch_name)

[0133] return target_branch,reference_branch

[0134] for repo in git_repositories:

[0135] target_branch,reference_branch=get_branches(repo,feature-branch,main)

[0136] print(fIn repository{repo}:)

[0137] print(fTarget branch:{target_branch})

[0138] print(fReference branch:{reference_branch})

[0139] The advantage of step S32 is:

[0140] (1) High accuracy: By directly accessing the metadata of the Git repository, branch information can be accurately obtained, avoiding the uncertainty that may be brought about by indirect methods based on file content or logs.

[0141] (2) High flexibility: It can handle different branch naming conventions, and only the recognition logic needs to be adjusted.

[0142] (3) High efficiency: For cloned or opened repositories, the operation of obtaining branch information is usually fast and will not become a performance bottleneck.

[0143] (4) Strong integration: Using libraries like GitPython, branch management functionality can be easily integrated into larger applications or scripts.

[0144] (5) Error handling is possible: It can easily handle the case where the branch does not exist by returning `None` or throwing an exception to notify the caller.

[0145] S33 compares whether the target branch has been merged with the reference branch.

[0146] Determine branch information: Ensure you have obtained the accurate names of the target branch and reference branch from the Git repository. These branch names can be obtained through command-line arguments, configuration files, or user input.

[0147] Using Git commands for comparison: Git provides a rich set of commands to check the relationships between branches. To determine if a target branch has merged a reference branch, you can use the `git merge-base` command to find the most recent common ancestor commit of the two branches. Then, by comparing the latest commit of the target branch with this common ancestor commit, you can determine whether the changes in the reference branch have been included.

[0148] Additionally, the `git branch --merged` command can be used to list all branches that have been merged into the current branch. If the reference branch appears in this list, it means that it has been merged into the target branch.

[0149] Automating checks through scripts: To improve efficiency, scripts or programs can be written to automate the execution of the Git commands mentioned above. These scripts can iterate through each Git repository, automatically retrieve branch information, and perform comparison operations. Based on the comparison results, the scripts can generate reports or notifications so that developers or management teams can quickly understand the merge status of branches.

[0150] Exception Handling: During the comparison process, some exceptions may be encountered, such as non-existent branches, corrupted Git repositories, or network problems. To achieve a robust comparison process, exception handling logic needs to be added to the script to provide clear error messages or take appropriate remedial measures when problems occur.

[0151] The benefits of step S33 are:

[0152] (1) Improved code quality: By automatically checking the merge status of branches, it can ensure that no important changes are missed during the code integration process. This helps reduce potential defects and errors, thereby improving the overall quality of the code.

[0153] (2) Improved Development Efficiency: Manually checking the merge status of each branch is a tedious and error-prone task. By automating this process, developers can save a significant amount of time and focus on more core development work. At the same time, automated checks can provide feedback more quickly, helping the team respond to changes and adjust plans more rapidly.

[0154] (3) Enhance teamwork: In a project with multiple people collaborating, different developers may be working on different branches simultaneously. By regularly checking and reporting the merge status of branches, communication and collaboration among team members can be enhanced. Everyone can clearly understand the progress of others' work and which changes are ready to be integrated into the main branch.

[0155] (4) Optimize the release process: When preparing for software release, it is crucial to ensure that all relevant changes have been merged into the release branch. Through automated branch merge checks, the pre-release verification process can be simplified, reducing delays or risks caused by missed merges.

[0156] (5) Enhance the traceability of version control:

[0157] By recording the results and relevant information of each branch merge check, the traceability of version control can be enhanced. This helps quickly identify the cause when problems occur and roll back to a previous stable state if necessary.

[0158] Step S4: Display the merge status of each repository and each target branch, classify and list the Git repositories with unmerged branches, and output the statistical results of the Git repository status.

[0159] In this embodiment, step S4: Display the merge status of each repository and each target branch, classify and list the Git repositories with unmerged branches, and output the statistical results of the Git repository status can specifically include the steps:

[0160] S41: Display the merge status of each repository and each target branch.

[0161] Traverse repositories: Write a script or use existing Git tools to traverse all Git repositories that need to be checked. This can be achieved by accessing all repositories on a Git hosting platform (such as GitHub, GitLab, etc.), or if it is a local environment, traverse the specified local directory.

[0162] Get branch information: For each repository, use the `git branch` or `git for-each-ref` command to obtain a list of all branches. At the same time, the latest commit hash value of each branch can be obtained through the `git show-ref` command.

[0163] Check merge status: To check the merge status of a specific branch (such as target branches like main, `master`, `develop`, etc.), you can use `git branch --merged <target-branch` to list all branches that have been merged into the target branch. On the contrary, `git branch --no-merged

[0164] <The `target-branch` will display the branches that have not been merged into the target branch.

[0165] Formatted output: The obtained information will be output in a clear format, for example, listing the name of each repository, the target branch, and the merge status of that branch (list of merged / unmerged branches).

[0166] The benefits of step S41 are as follows:

[0167] (1) High clarity: By centrally displaying the merge status of all repositories and target branches, team members can clearly understand the branch management situation of the entire project at a glance.

[0168] (2) Improved development efficiency: The automated script reduces the time required to manually check each repository and branch, improving development efficiency.

[0169] (3) High accuracy: Using Git commands to directly obtain the branch status ensures the accuracy of the information and reduces the possibility of human errors.

[0170] S42. Classify and list the Git repositories with unmerged branches.

[0171] Filter unmerged branches: Based on the information obtained in step S41, by checking whether the list of unmerged branches of each repository is empty, filter out the Git repositories with unmerged branches.

[0172] Classify and list: Classify the filtered repositories according to certain criteria, such as the activity of the repository, the number of unmerged branches, the last commit time, etc. Then, output the list of these classified repositories.

[0173] The benefits of step S42 are as follows:

[0174] (1) Highlight key points: By specifically listing the repositories with unmerged branches, team members can more easily identify the key areas that need attention and processing.

[0175] (2) Can be prioritized: Classifying and listing the repositories helps the team arrange the priority of the merge work according to urgency and importance.

[0176] (3) Can conduct risk management: Timely discovering and handling unmerged branches helps reduce code conflicts and potential project risks.

[0177] S43. Output the statistical results of the Git repository status.

[0178] Data summary: Based on steps S41 and S42, summarize the merge status data of all warehouses, including the number of merged branches, the number of unmerged branches, and the branch activity status of each warehouse.

[0179] Statistical analysis: Perform statistical analysis on this data, such as calculating the average lifespan of unmerged branches, identifying the most active repositories or branches, etc.

[0180] Results Output: Output the statistical results in the form of charts or reports for easy viewing and understanding by team members. The output format can be customized according to the team's specific needs, such as HTML pages, PDF documents, or direct display in the command line.

[0181] The benefits of step S43 are:

[0182] (1) Decision support: Through statistical results, team management can better understand the code management status of the entire organization and make more informed decisions.

[0183] (2) Performance optimization is possible: Analyzing the statistics of branch activities can help to discover potential performance bottlenecks or areas for improvement, such as identifying merge processes or branch strategies that need to be optimized.

[0184] (3) Facilitates team collaboration: Transparent statistical results can promote collaboration and communication among team members, ensuring that everyone is involved in the project.

[0185] Step S5: Based on the Git repository status statistics, obtain the Git repository branches that need to be merged, configure the merge strategy, and generate a merge plan.

[0186] In practice, the merging strategy can be customized by the customer. For example, the user can confirm whether to merge automatically, or whether to support batch mode (all warehouses adopt a unified merging strategy) or individual mode (each warehouse is configured independently).

[0187] In this embodiment, step S5, obtaining the Git repository branches that need to be merged based on the Git repository status statistics, configuring the merge strategy, and generating the merge plan may specifically include the following steps:

[0188] S51, based on the Git repository status statistics, obtain the Git repository branches that need to be merged.

[0189] Analyze repository status: Use Git commands (such as `git status`, `git branch`, etc.) or graphical tools (such as GitKraken, SourceTree, etc.) to view the current repository status, including a list of all branches, the commit history of each branch, and the relative relationships between branches.

[0190] Determine the merging requirements: Based on the actual situation of project development, identify which branches need to be merged.

[0191] Select target branches: Select branches from all branches that meet the merge criteria. These criteria include branch stability, verification through tests, and completion of code reviews.

[0192] The benefits of step S51 are:

[0193] (1) High clarity: By systematically analyzing the status of the warehouse, team members can have a clearer understanding of the overall progress of the project and the status of each branch.

[0194] (2) High accuracy: Based on clear criteria, branches that need to be merged are selected, reducing human error and unnecessary merging operations.

[0195] (3) High development efficiency: Targeted selection of merging targets avoids waste of resources and improves development efficiency.

[0196] S52, configure the merge strategy according to the Git repository branch information to be merged.

[0197] Git provides merge strategies such as `merge` (a regular merge that preserves the complete commit history).

[0198] `rebase` (rebase merge, rewrites commit history to maintain linearity), `squash` (squash merge, compresses multiple commits into one), etc.

[0199] Choose a merge strategy: Based on the specific needs of the project and the team's preferences, select an appropriate merge strategy for each branch that needs to be merged. For example, for long-maintained main branches, a `merge` strategy might be preferred to maintain historical integrity; while for short-term feature branches, a different strategy might be chosen.

[0200] Use `rebase` or `squash` to simplify the history.

[0201] Configure merge options: Before performing the merge operation, configure the relevant merge options according to the selected strategy. This may include setting the conflict resolution method during the merge, specifying the message format for merge commit, etc.

[0202] The benefits of step S52 are:

[0203] (1) High flexibility: Different merging strategies can be selected according to different situations, which can better meet the diverse needs of the project.

[0204] (2) High controllability: By pre-configuring merge options, the behavior and results of the merge process can be predicted and controlled to a certain extent.

[0205] (3) High consistency: Unifying the merging strategy and configuration within the team helps improve the consistency and maintainability of the codebase.

[0206] S53, Generate a merger plan based on the merger strategy.

[0207] Determine the merge order: Based on the dependencies between branches and the complexity of the merge strategy, determine the merge order of the branches. Generally, branches that have less impact on other branches or are more stable will be merged first.

[0208] Assign merge tasks: Assign merge tasks to specific developers or merge managers. This ensures that the merge work is executed in a timely and effective manner.

[0209] Set a timeline: Set expected completion times and milestones for each merged task to track progress and adjust the plan as needed.

[0210] Compile a merger plan document: Organize the above information into a detailed merger plan document for team members to refer to and implement.

[0211] For example, for each target branch, select the source branch to merge. Then generate a merge plan, for example: master←feature / 202505, develop←master, feature / 202506←

[0212] develop.

[0213] Benefits of step S53:

[0214] (1) It is orderly: By establishing a clear merger order and task allocation, it can be ensured that the merger work is carried out in an orderly manner.

[0215] (2) Traceability: Setting timelines and milestones helps to track the progress of the merger in real time, making it easier to identify problems and make adjustments in a timely manner.

[0216] (3) Collaborative: A clear merge plan document can promote effective communication and collaboration among team members and improve overall development efficiency.

[0217] Step S6: Perform the merge operation according to the merge plan and push the merge results to the remote repository.

[0218] In this embodiment, step S6, executing the merge operation according to the merge plan and pushing the merge result to the remote repository, may specifically include the following steps:

[0219] S61, the merger operation will be carried out step by step in accordance with the merger plan.

[0220] Merge plans are typically developed by project managers or team leaders, detailing which branches need to be merged, the order of merging, the expected merge timeline, and the personnel responsible for the merge.

[0221] Preparing the merge environment: Ensure your local repository is up-to-date and all necessary dependencies are installed. You can use the `git pull` command to pull the latest code from the remote repository, ensuring your local branch is synchronized with the remote branch.

[0222] Execute the merge command: Based on the merge plan, use the `git merge` command to merge the specified branch into the current branch. For example, if the plan is to merge `feature-branch` into the `main` branch, you can execute `git merge feature-branch` on the `main` branch.

[0223] Verify the merge result: After merging, verify the merge result by compiling the code and running unit tests to ensure that no new problems have been introduced into the code.

[0224] The benefit of step S61 is:

[0225] (1) Orderliness: Executing the merge operation according to the merge plan can ensure the orderliness of the merge process and avoid code conflicts and integration problems caused by arbitrary merging.

[0226] (2) Traceability: The merger plan records the history and decision-making process of the merger, which makes it easy to trace and investigate when problems occur.

[0227] S62 monitors conflicts during the merge process.

[0228] Automatic conflict detection: During the merge process, Git automatically detects code conflicts. Conflicts typically occur when two branches make different changes to the same line of code. Git flags these conflicts and notifies the user in the merge result.

[0229] When a conflict is detected, the merger opens the conflicting file, examines it, and decides how to merge the different changes. Git uses special markers (such as `<<<<<<<`, `========`, and `= ...

[0230] `>>>>>>>`) is used to indicate the location of the conflict.

[0231] After resolving the conflicts, you need to remove the conflict markers added by Git and save the file. Then, use the `git add` command to mark the resolved file as resolved.

[0232] Continue merging: If all conflicts have been resolved, you can continue the merge operation (if it was interrupted by conflicts). Use the `git commit` command to complete the merge commit.

[0233] The advantage of step S62 is:

[0234] Problems can be detected in a timely manner: Monitoring conflicts during the merging process can help identify potential problems in a timely manner, avoiding them from being discovered only during the integration testing phase after the merge, thus saving time and resources.

[0235] S63 pushes the merge results to the remote repository.

[0236] Check your local repository for uncommitted changes: Before pushing the merge results, ensure your local repository has no uncommitted changes. You can check this using the `git status` command.

[0237] Push the merge result: Use the `git push` command to push the merged branch to the remote repository. For example, to push the `main` branch to the remote repository, you can execute `git push origin main`.

[0238] It should be noted that, in practice, users choose a push strategy: for example, push all, selective push, or no push.

[0239] Verify the push result: After the push, you can verify the push result on the web interface of the remote repository to ensure that the merged code has been successfully uploaded to the remote repository.

[0240] The benefit of step S63 is:

[0241] (1) Code synchronization is possible: Pushing the merge results to a remote repository ensures that all team members can access the latest code and keep the codebase synchronized.

[0242] (2) Continuous integration: After pushing the merge results, the continuous integration process can be triggered to automatically run build, test and deployment tasks, improving development efficiency and quality.

[0243] (3) Version control is possible: Pushing the merge results to a remote repository can preserve the merge history, which is convenient for subsequent code auditing and problem tracing.

[0244] In some optional implementations, step S7 can also be executed after step S6 to output the push execution results, display the success and failure status of each repository merge and push, as well as error messages (such as remote library access errors), which helps to track the push results.

[0245] The beneficial effects of implementing this embodiment are as follows: By running a shell script in the terminal, multiple Git repositories under a specified directory are scanned, and the merging status of each target branch relative to the reference branch in each repository is statistically analyzed; the existence and merging status of each branch are automatically determined; when an unmerged branch is found, the user is prompted whether to perform an automatic merge, and a batch or individual repository merge strategy is provided; the merge operation is executed sequentially according to the merge plan confirmed by the user; after the merge is completed, the merge result is pushed to the respective remote repositories according to the configuration; finally, detailed merge and push results are output, and possible errors (such as remote repository access failure) are indicated; the management efficiency of merging branches of multiple Git repositories can be greatly improved; the error rate of manual branch merging is reduced; automated operation reduces operational complexity and improves consistency in the overall continuous integration process; unified statistics and transparency of the status of each repository branch are achieved, facilitating project management; and flexible merge and push strategies are supported to adapt to different project processes.

[0246] This invention can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This invention can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This invention can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0247] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by instructing related hardware with computer-readable instructions. These computer-readable instructions can be stored in a computer-readable storage medium. When executed, the program can include the processes of the embodiments of the above methods. The aforementioned storage medium can be a non-volatile storage medium such as a magnetic disk, optical disk, or read-only memory (ROM), or random access memory (RAM).

[0248] It should be understood that although the steps in the flowcharts of the accompanying figures are shown sequentially as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the accompanying figures may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0249] Example 2

[0250] Further reference Figure 2 As a response to the above Figure 1 The present invention provides an embodiment of a Git multi-repository branch batch statistics and automated management device, which, according to the implementation of the method shown, provides an embodiment of such a device. Figure 1 Corresponding to the method embodiments shown, this device can be specifically applied to various electronic devices.

[0251] like Figure 2 As shown, the Git multi-repository branch batch statistics and automated management device 70 in this embodiment includes: a deployment module 71, an acquisition module 72, a traversal module 73, an output module 74, a generation module 75, and a push module 76. Wherein:

[0252] Deployment module 71 is used to deploy Shell repository branch management scripts to the terminal, providing users with a consistent interactive interface;

[0253] The acquisition module 72 is used to acquire the terminal repository path and the directories to be scanned under the repository path;

[0254] The traversal module 73 is used to traverse all Git repositories in the directory to be scanned, obtain the target branch and reference branch in each Git repository, and compare whether the target branch has merged the reference branch.

[0255] Output module 74 is used to display the merge status of each repository and each target branch, categorize and list Git repositories with unmerged branches, and output Git repository status statistics.

[0256] The generation module 75 is used to obtain the Git repository branches that need to be merged based on the Git repository status statistics, configure the merge strategy, and generate a merge plan.

[0257] The push module 76 is used to execute the merge operation according to the merge plan and push the merge results to the remote repository.

[0258] The beneficial effects of implementing this embodiment are as follows: By running a shell script in the terminal, multiple Git repositories under a specified directory are scanned, and the merging status of each target branch relative to the reference branch in each repository is statistically analyzed; the existence and merging status of each branch are automatically determined; when an unmerged branch is found, the user is prompted whether to perform an automatic merge, and a batch or individual repository merge strategy is provided; the merge operation is executed sequentially according to the merge plan confirmed by the user; after the merge is completed, the merge result is pushed to the respective remote repositories according to the configuration; finally, detailed merge and push results are output, and possible errors (such as remote repository access failure) are indicated; the management efficiency of merging branches of multiple Git repositories can be greatly improved; the error rate of manual branch merging is reduced; automated operation reduces operational complexity and improves consistency in the overall continuous integration process; unified statistics and transparency of the status of each repository branch are achieved, facilitating project management; and flexible merge and push strategies are supported to adapt to different project processes.

[0259] Example 3

[0260] To address the aforementioned technical problems, embodiments of the present invention also provide a computer device. Please refer to [link / reference needed]. Figure 3 , Figure 3 This is a basic structural block diagram of the computer device in this embodiment.

[0261] The aforementioned computer device 8 includes a memory 81, a processor 82, and a network interface 83 that are interconnected via a system bus. It should be noted that only the computer device 8 with components 81, 82, and 83 is shown in the figure; however, it should be understood that it is not required to implement all the shown components, and more or fewer components can be implemented alternatively. Those skilled in the art will understand that the computer device described herein is a device capable of automatically performing numerical calculations and / or information processing according to pre-set or stored instructions, and its hardware includes, but is not limited to, microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), embedded devices, etc.

[0262] The aforementioned computer devices can be desktop computers, laptops, handheld computers, and cloud servers, among other computing devices. These devices can facilitate human-computer interaction with users through keyboards, mice, remote controls, touchpads, or voice-activated devices.

[0263] The aforementioned memory 81 includes at least one type of readable storage medium, including flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the aforementioned memory 81 may be an internal storage unit of the aforementioned computer device 8, such as the hard disk or memory of the computer device 8. In other embodiments, the aforementioned memory 81 may also be an external storage device of the aforementioned computer device 8, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 8. Of course, the aforementioned memory 81 may also include both the internal storage unit and its external storage device of the aforementioned computer device 8. In this embodiment, the aforementioned memory 81 is typically used to store the operating system and various application software installed on the aforementioned computer device 8, such as computer-readable instructions for Git multi-repository branch batch statistics and automated management methods. In addition, the aforementioned memory 81 can also be used to temporarily store various types of data that have been output or will be output.

[0264] In some embodiments, the processor 82 described above may be a central processing unit (CPU), a controller, a microcontroller, a microprocessor, or other data processing chip. The processor 82 is typically used to control the overall operation of the computer device 8. In this embodiment, the processor 82 is used to execute computer-readable instructions stored in the memory 81 or to process data, for example, to execute computer-readable instructions for the Git multi-repository branch batch statistics and automated management method described above.

[0265] The network interface 83 may include a wireless network interface or a wired network interface, which is typically used to establish a communication connection between the computer device 8 and other electronic devices.

[0266] The beneficial effects of implementing this embodiment are as follows: By running a shell script in the terminal, multiple Git repositories under a specified directory are scanned, and the merging status of each target branch relative to the reference branch in each repository is statistically analyzed; the existence and merging status of each branch are automatically determined; when an unmerged branch is found, the user is prompted whether to perform an automatic merge, and a batch or individual repository merge strategy is provided; the merge operation is executed sequentially according to the merge plan confirmed by the user; after the merge is completed, the merge result is pushed to the respective remote repositories according to the configuration; finally, detailed merge and push results are output, and possible errors (such as remote repository access failure) are indicated; the management efficiency of merging branches of multiple Git repositories can be greatly improved; the error rate of manual branch merging is reduced; automated operation reduces operational complexity and improves consistency in the overall continuous integration process; unified statistics and transparency of the status of each repository branch are achieved, facilitating project management; and flexible merge and push strategies are supported to adapt to different project processes.

[0267] Example 4

[0268] The present invention also provides another embodiment, namely, a computer-readable storage medium storing computer-readable instructions that can be executed by at least one processor to cause the at least one processor to perform the steps of the Git multi-repository branch batch statistics and automated management method described above.

[0269] The beneficial effects of implementing this embodiment are as follows: By running a shell script in the terminal, multiple Git repositories under a specified directory are scanned, and the merging status of each target branch relative to the reference branch in each repository is statistically analyzed; the existence and merging status of each branch are automatically determined; when an unmerged branch is found, the user is prompted whether to perform an automatic merge, and a batch or individual repository merge strategy is provided; the merge operation is executed sequentially according to the merge plan confirmed by the user; after the merge is completed, the merge result is pushed to the respective remote repositories according to the configuration; finally, detailed merge and push results are output, and possible errors (such as remote repository access failure) are indicated; the management efficiency of merging branches of multiple Git repositories can be greatly improved; the error rate of manual branch merging is reduced; automated operation reduces operational complexity and improves consistency in the overall continuous integration process; unified statistics and transparency of the status of each repository branch are achieved, facilitating project management; and flexible merge and push strategies are supported to adapt to different project processes.

[0270] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods of the various embodiments of the present invention.

[0271] Obviously, the embodiments described above are merely some embodiments of the present invention, not all embodiments. The accompanying drawings show preferred embodiments of the present invention, but do not limit the patent scope of the present invention. The present invention can be implemented in many different forms; rather, these embodiments are provided to provide a more thorough and complete understanding of the disclosure of the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing specific embodiments, or make equivalent substitutions for some of the technical features. Any equivalent structures made using the content of this specification and drawings, directly or indirectly applied to other related technical fields, are similarly within the patent protection scope of this invention.

Claims

1. A method for batch statistics and automated management of Git multi-repository branches, characterized in that, Includes the following steps: Deploy the Shell repository branch management script in the terminal to provide users with a consistent interactive interface; Obtain the terminal repository path and the directories to be scanned under the repository path; Iterate through all Git repositories in the directory to be scanned, obtain the target branch and reference branch in each Git repository, and compare whether the target branch has merged the reference branch. Displays the merge status of each repository and each target branch, lists the Git repositories with unmerged branches by category, and outputs Git repository status statistics. Based on the Git repository status statistics, obtain the Git repository branches that need to be merged, configure the merge strategy, and generate a merge plan; Perform the merge operation according to the merge plan and push the merge results to the remote repository.

2. The Git multi-repository branch batch statistics and automated management method according to claim 1, characterized in that, The steps of deploying the Shell repository branch management script on the terminal to provide users with a consistent interactive interface specifically include: Obtain the number of warehouses to be monitored, branch types, statistical indicators, and automated management tasks; Based on the number of repositories to be monitored, branch types, statistical metrics, and automated management tasks obtained, create a shell script for batch statistics and management of Git repository branches; The created shell script is deployed to the user's terminal to provide a consistent interactive interface.

3. The Git multi-repository branch batch statistics and automated management method according to claim 1, characterized in that, The steps of obtaining the terminal repository path and the directories to be scanned under the repository path specifically include: Obtain the terminal repository path; Obtain the directories to be scanned under the specified repository path.

4. The Git multi-repository branch batch statistics and automated management method according to claim 1, characterized in that, The steps of traversing all Git repositories in the directory to be scanned, obtaining the target branch and reference branch in each Git repository, and comparing whether the target branch has merged the reference branch specifically include: Iterate through all Git repositories in the directory to be scanned; Get the target branch and reference branch in each Git repository; Compare whether the target branch has been merged with the reference branch.

5. The Git multi-repository branch batch statistics and automated management method according to claim 1, characterized in that, The steps of displaying the merge status of each repository and each target branch, classifying and listing Git repositories with unmerged branches, and outputting Git repository status statistics specifically include: Displays the merge status of each repository and each target branch; The list categorizes and lists Git repositories with unmerged branches; Output the Git repository status statistics.

6. The Git multi-repository branch batch statistics and automated management method according to claim 1, characterized in that, The steps of obtaining the Git repository branches to be merged based on the Git repository status statistics, configuring the merge strategy, and generating the merge plan specifically include: Based on the Git repository status statistics, obtain the Git repository branches that need to be merged; Configure the merge strategy according to the Git repository branches to be merged; Generate a merger plan based on the merger strategy.

7. The Git multi-repository branch batch statistics and automated management method according to any one of claims 1 to 6, characterized in that, The steps of executing the merge operation according to the merge plan and pushing the merge results to the remote repository specifically include the following steps: The merger process will be carried out step by step in accordance with the merger plan; Monitor conflicts during the merge process; Push the merge results to the remote repository.

8. A Git multi-repository branch batch statistics and automated management device, characterized in that, include: The deployment module is used to deploy Shell repository branch management scripts to the terminal, providing users with a consistent interactive interface. The acquisition module is used to acquire the terminal repository path and the directories to be scanned under the repository path; The traversal module is used to traverse all Git repositories in the directory to be scanned, obtain the target branch and reference branch in each Git repository, and compare whether the target branch has merged the reference branch. The output module is used to display the merge status of each repository and each target branch, categorize and list Git repositories with unmerged branches, and output Git repository status statistics. The generation module is used to obtain the Git repository branches that need to be merged based on the Git repository status statistics, configure the merge strategy, and generate a merge plan; The push module is used to execute merge operations according to the merge plan and push the merge results to the remote repository.

9. A computer device, characterized in that, The method includes a memory and a processor, wherein the memory stores computer-readable instructions, and the processor executes the computer-readable instructions to implement the steps of the Git multi-repository branch batch statistics and automated management method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-readable instructions, which, when executed by a processor, implement the steps of the Git multi-repository branch batch statistics and automated management method as described in any one of claims 1 to 7.

Images