在Azure DevOps Server中分析Git代码库的健康状况

1. 概述

开发团队使用Git作为版本管理工具，需要经常关注Git代码库的状况，例如分析代码库占用磁盘空间大小、开发人员提交和推送代码的频次、分支和标记的数据量、为合并的分支等，从而分析代码块的健康状况；一个健康的代码库，可以大幅减少管理人员的维护成本，提交软件开发的效率和质量。

在Azure DevOps Server中，系统提供了一个用于分析Git代码库“健康状况和使用状况”的功能，本文主要介绍这个功能的使用和健康状况的各项参数。

2. 功能描述

在Azure DevOps Server中，我们导航任意代码库，在代码库的的功能菜单中，选择“健康状况和使用状况”，如下图

在弹出的窗口中，可以看到当前代码的健康状况和使用情况，如下图：
!
下面我们来分别解析这个状况的各种参数。

2.1 主要使用情况

可访问存储库大小(GB)

该参数显示存储库在磁盘上占用的空间大小。
建议将存储库大小保持在 100 GB 以下，以获得最佳性能。较小的存储库可以更快地克隆，也更容易管理和维护。如果您的存储库超过此大小，建议使用 Git-LFS、Scalar 或 Azure Artifacts 来重构您的开发资源。

可访问的对象数

该参数表示存储库中的对象数量，这些对象可以通过任何引用或标签访问。对象不仅包括文件（blobs，即纯文件），还包括目录、提交记录和标签。

对象数量越多，Git 在遍历存储库历史时所需的时间就越长，这会影响显示提交历史和其他对象的速度。此外，ADO（Azure DevOps）的实现存在对象数量的硬性限制。Azure Repos 中的单个存储库最多不能包含超过 1 亿个对象。

2.2 使用情况和健康状况

引用个数

引用数量（Number of refs）显示存储库中的引用总数。注意引用，大部分场景中是指分支和标记。
如果你的 Git 存储库包含超过 10,000 个引用，建议启用“有限引用”（Limited Refs）功能。随着引用数量的增加，客户端与服务器之间需要协商的数据量也会增加。协商的数据越多，服务器的负载就越重，同时可能传输给客户端的数据也越多，从而导致用户体验下降。

可访问的 Blob 数

可访问 blob 数量（Number of reachable blobs）显示存储库中可访问的 blob 文件总数。注意blob一般是指Git库中的纯文件数据，不包含引用、分支等。

可访问的 Blob 大小(GB)

可以通过任意分支、标记和提交访问到的文件内容。
注意blob大小和代码库大小的主要区别是，代码库中还包含了许多不能访问的文件内容，例如dangling blob和孤儿文件等。

可访问的树tree的数量

在git中，树tree一般指的目录。目录太多，会大幅影响git的性能，例如git blame的操作

可访问的树大小(GB)

可访问树对象大小（Size of reachable trees）参数显示磁盘上所有可访问的树对象的总大小，单位为 GB（千兆字节）

可访问的提交数

可访问的提交数(Number of reachable commits)统计所有提交数，其中不包含不可访问的提交数。

可访问的提交大小(MB)

前面的可访问的提交数对应的磁盘文件的大小

可访问标记数

主要是指标记tag的个数

可访问的标记大小(MB)

标记tags对象占用磁盘文件的大小，这个数据一般不会太大

https://www.cnblogs.com/danzhang
Azure DevOps MVP 张洪君