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

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

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

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

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

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

　　另外，目前 Git 客戶(hù)端倉庫之所以能順暢地執行，是依賴(lài)定期執行的前臺垃圾回收器，但微軟提到，對于巨型倉庫來(lái)說(shuō)，這是不可行的方法。因此微軟計劃在 Git 客戶(hù)端中加入某種形式的后臺維護功能，類(lèi)似git maintenance start命令，并像scalar register一樣容易使用。
　?。?a href="http://www.reeanfmc.com">邯鄲網(wǎng)站建設）

微軟全新Android版Office...

“小扎，醒醒！” 扎克...