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