Git屬于分布式版本控制系統(tǒng)，默認(rèn)情況下，每個Git倉庫都具有整個歷史記錄的完整文件副本。即便是中等規(guī)模的開發(fā)團(tuán)隊(duì)也會產(chǎn)生數(shù)千個提交，每個月向倉庫添加幾百兆的數(shù)據(jù)。而隨著倉庫的占用空間增加，Git難以管理所有數(shù)據(jù)，導(dǎo)致其運(yùn)行越來越不順暢。如此一來，開發(fā)者的時間就會被浪費(fèi)在執(zhí)行命令后等待反饋的操作上，如使用git status獲取被修改的文件，或者使用git fetch將代碼拉取至本地。由于等待的時間過長，開發(fā)者大多會傾向于切換至完成另外的任務(wù)，待命令執(zhí)行完成后再切換回來。而這種來回切換任務(wù)的工作方式常常會降低開發(fā)者的生產(chǎn)力。

　　對于處理巨型Git倉庫的問題，微軟顯然是頗有經(jīng)驗(yàn)。畢竟Windows操作系統(tǒng)的代碼就是使用Git進(jìn)行管理，為了克服上述的問題，微軟開發(fā)了VFS for Git（以前稱為GVFS），此項(xiàng)目使用虛擬文件系統(tǒng)繞過了許多倉庫大小的限制，所以Windows開發(fā)者在如此龐大的項(xiàng)目前也能正常使用Git。

　　在開發(fā)Vit for Git的同時，微軟通過使用自定義跟蹤系統(tǒng)和收集用戶反饋來確定性能瓶頸。在此期間，微軟也為Git客戶端貢獻(xiàn)了一些代碼，包括提交樹（Commit-Graph）功能以及對git push和稀疏檢出的改進(jìn)?；谶@些貢獻(xiàn)以及其他許多對Git的近期改進(jìn)，微軟啟動了一個項(xiàng)目——無需虛擬文件系統(tǒng)即可支持巨型Git倉庫。這就是Scalar的誕生背景。

　　Scalar是一個使用C#編寫的.NET Core應(yīng)用程序，僅支持在Windows和macOS平臺中運(yùn)行。Scalar通過設(shè)置所建議的配置值和運(yùn)行后臺維護(hù)來最大程度優(yōu)化Git命令的性能。無論開發(fā)者使用什么服務(wù)來托管代碼倉庫，Scalar都能有效地加速Git指令。微軟提到，只要使用Scalar為體積最大的代碼倉庫進(jìn)行注冊，就能馬上感受到Git執(zhí)行速度大的幅提升。

　　對于Scalar的未來，微軟希望將其貢獻(xiàn)給Git。微軟計劃把Scalar中加速Git的方法直接合并到Git項(xiàng)目中，最終實(shí)現(xiàn)讓開發(fā)者不需要Scalar，僅使用Git客戶端就能獲得這些性能改進(jìn)。不過要達(dá)成這個目標(biāo)，仍然有很長的路要走。微軟提到，目前稀疏檢出是Scalar用來解決倉庫規(guī)模擴(kuò)大的方法，盡管Git最近更新了稀疏檢出功能，使得該功能更容易使用，但是要達(dá)到提供完整功能的階段，還有一段距離。

　　Scalar目前使用稀疏檢出而非虛擬文件系統(tǒng)，因此在執(zhí)行Git命令時會存在瓶頸，特別是git checkout的速度不及VFS for Git，微軟正在研究并行版本的git checkout，以提高執(zhí)行性能。微軟提到，為了真正地擴(kuò)展Git服務(wù)以滿足成千上萬的工程師的需求，并構(gòu)建與中央服務(wù)器交互的機(jī)器，Git需要提供類似于GVFS緩存服務(wù)器的概念。他們也表示計劃很快在郵件列表中提出這個想法。

　　另外，目前Git客戶端倉庫之所以能順暢地執(zhí)行，是依賴定期執(zhí)行的前臺垃圾回收器，但微軟提到，對于巨型倉庫來說，這是不可行的方法。因此微軟計劃在Git客戶端中加入某種形式的后臺維護(hù)功能，類似git maintenance start命令，并像scalar register一樣容易使用。