Git 属于分布式版本控制系统，默认情况下，每个 Git 仓库都具有整个历史记录的完整文件副本。即便是中等规模的开发团队也会产生数千个提交，每个月向仓库添加几百兆的数据。而随着仓库的占用空间增加，Git 难以管理所有数据，导致其运行越来越不顺畅。如此一来，开发者的时间就会被浪费在执行命令后等待反馈的操作上，如使用git status获取被修改的文件，或者使用git fetch将代码拉取至本地。由于等待的时间过长，开发者大多会倾向于切换至完成另外的任务，待命令执行完成后再切换回来。而这种来回切换任务的工作方式常常会降低开发者的生产力。

对于处理巨型 Git 仓库的问题，微软显然是颇有经验。毕竟 Windows 操作系统的代码就是使用 Git 进行管理，为了克服上述的问题，微软开发了 VFS for Git（以前称为 GVFS），此项目使用虚拟文件系统绕过了许多仓库大小的限制，所以 Windows 开发者在如此庞大的项目前也能正常使用 Git。

在开发 Vit for Git 的同时，微软通过使用自定义跟踪系统和收集用户反馈来确定性能瓶颈。在此期间，微软也为 Git 客户端贡献了一些代码，包括提交树（Commit-Graph）功能以及对git push和稀疏检出的改进。基于这些贡献以及其他许多对 Git 的近期改进，微软启动了一个项目 —— 无需虚拟文件系统即可支持巨型 Git 仓库。这就是 Scalar 的诞生背景。

Scalar 是一个使用 C# 编写的 .NET Core 应用程序，仅支持在 Windows 和 macOS 平台中运行。Scalar 通过设置所建议的配置值和运行后台维护来最大程度优化 Git 命令的性能。无论开发者使用什么服务来托管代码仓库，Scalar 都能有效地加速 Git 指令。微软提到，只要使用 Scalar 为体积最大的代码仓库进行注册，就能马上感受到 Git 执行速度大的幅提升。

对于 Scalar 的未来，微软希望将其贡献给 Git。微软计划把 Scalar 中加速 Git 的方法直接合并到 Git 项目中，最终实现让开发者不需要 Scalar，仅使用 Git 客户端就能获得这些性能改进。不过要达成这个目标，仍然有很长的路要走。微软提到，目前稀疏检出是 Scalar 用来解决仓库规模扩大的方法，尽管 Git 最近更新了稀疏检出功能，使得该功能更容易使用，但是要达到提供完整功能的阶段，还有一段距离。

Scalar 目前使用稀疏检出而非虚拟文件系统，因此在执行 Git 命令时会存在瓶颈，特别是git checkout 的速度不及 VFS for Git，微软正在研究并行版本的git checkout，以提高执行性能。微软提到，为了真正地扩展 Git 服务以满足成千上万的工程师的需求，并构建与中央服务器交互的机器，Git 需要提供类似于 GVFS 缓存服务器的概念。他们也表示计划很快在邮件列表中提出这个想法。

另外，目前 Git 客户端仓库之所以能顺畅地执行，是依赖定期执行的前台垃圾回收器，但微软提到，对于巨型仓库来说，这是不可行的方法。因此微软计划在 Git 客户端中加入某种形式的后台维护功能，类似git maintenance start命令，并像scalar register一样容易使用。

详细的使用说明请查看 https://devblogs.microsoft.com/devops/introducing-scalar