登陆

极彩彩票官网-为何Google、微软、华为将亿级源代码放一个库房?从全球最大代码办理库说起

admin 2019-11-11 164人围观 ,发现0个评论

作者 | 夕颜

修正 | Just

出品 | AI 科技大本营(ID:rgznai100)

【导读】2017 年,在其时微软的一篇官方博客中,时任微软云开发服务副总裁的 Brian Harry 标明微软内部代码开端向 Git 搬迁,宣告推出针对大规划 repo 的“Git虚拟文件体系”GVFS(后更名为 VFS For Git)。他激动地同享了微软公司 4000 名工程师选用这个代码办理库房后三个月的运转杰出状况,称其处理了许多 Git 存在的问题。

时隔两年之后,这篇文章中对 VFS For Git 代码办理技能思路的介绍依然值得学习。

【导读】2017 年,在其时微软的一篇官方博客中,时任微软云开发服务副总裁的 Brian Harry 标明微软内部代码开端向 Git 搬迁,宣告推出针对大规划 repo 的“Git虚拟文件体系”GVFS(后更名为 VFS For Git)。他激动地同享了微软公司 4000 名工程师选用这个代码办理库房后三个月的运转杰出状况,称其处理了许多 Git 存在的问题。

时隔两年之后,这篇文章中对 VFS For Git 代码办理技能思路的介绍依然值得学习。

大型科技公司自身具有巨大的代码数据,而且每天都在发生数量巨大的新代码,怎么办理代码和版别成为备受重视的问题。许多公司会挑选将代码保管于 Git 等第三方代码保管渠道,但近年来,将代码办理交给公司自己开发的共同库房成为一种趋势。如微软的 VFS For Git 便是一个典型案例。

大公司应该怎么进行代码办理?微软研制并选用 VFS For Git 的进程和这个体系自身有哪些能够学习的当地?为了更深入了解 VFS For Git 和代码办理相关问题,AI科技大本营(ID:rgznai100)采访了微软亚洲研讨院首席研制司理邹欣,他对这些问题进行了回答。

为什么要做 VFS For Git?

邹欣回想,在将代码搬迁到 GVFS 前,微软曾运用多个首要的代码办理渠道,包含 SLM, Source Depot (上世纪 90 时代开端)、TFS 的源代码操控 TFVC (2006 年开端)。直到 2017 年,微软用三个月的时刻完结代码搬迁到 Git,并推出了 Git 的变种,针对特大 repo 的 GVFS,并沿袭至今。

GVFS 是一个 Git 虚拟文件体系,全称为 Git Virtual File System,答应 Git 处理 TB 规划的代码库,比方 270 GB 的 Windows 代码库。GVFS 的 V 便是 Virtual(虚拟),它处理了Git 本来的规划缺点(每个客户端都有一切版别的代码),而是用虚拟文件来替代那些本地用不着的文件, 大大减少了文件传输和本地机器存储的压力,让微软内部技能人员能够进行高效协作。

一段小插曲是,GVFS 从发布之初就引起了争议,原因是 GNOME 项目的虚拟文件体系也叫 GVfs,而 GNOME 的 GVfs 最早发布于 2006 年,之后的教程、文档、论坛都沿袭这个姓名。在微软的 GVfs 项目发布后,很快超越了 Gnome GVfs 项目的查找排名,且由于二者都与虚拟文件体系有关,导致用户在查找信息时简略呈现混杂。所以,许多开发者要求微软改名,经过一番曲折后,微软总算在 2018 年将 "GVFS" 项目的姓名改为 "VFS For Git"。

邹欣标明,其时微软将代码搬迁到 Git 首要是为了共同微软百家争鸣的内部东西,并没有一个肯定好的挑选,领导团队挑选了 Git, 但从现在的成果来看,这是一个比较好的挑选。现在,微软依然在对 Git 系列的东西做改善,也把改善回馈到 Git 社区。

现在,VFS For Git 现已是微软内部共同的东西,一起被其他大型企业选用:https://vfsforgit.org/

VFS For Git 在 GitHub 上也已开源:

GitHub开源地址:https://github.com/microsoft/VFSForGit

单一自研代码办理库房是最好的挑选吗?

除了微软,咱们发现,许多大公司的代码保管现已向自己内部开发的版别操控体系搬迁,比方 Google 就把运用不同言语编写的超越 10 亿文件,近百 TB 源代码都存放在自行开发的版别办理体系 Piper 中,只当项目开源且需求外部协作时,才会运用业界盛行的 Git。(详见文章《为何Google将几十亿行源代码放在一个库房?》)

再如华为的内源(Inner Source)渠道,承载着华为 1100 亿源代码、60 万+ 代码库房、每天 60 T 的下载容量、1 万次/秒的顶峰并发下载。

这是否阐明在大公司中盛行的单一库房便是最好的做法?这些公司在挑选选用代码保管办法时需求考虑哪些不同的问题?

邹欣对 AI科技大本营进行解说,在他看来,用 GVFS 也能够创立各种独立的库房。用一套东西有利于公司内部进行代码同享,让人员活动、代码复审、改善东西变得更简略,功率前进。

其次,大公司有很许多的代码,很长的前史和许多东西,假如轻率挑选一个新东西就会呈现以下问题:

a) 一些市面上的东西并不是为大规划代码规划的,处理不了许多代码, 咱们曾经用第三方的代码剖析东西, 成果处理 Office 的代码的时分,自己溃散了,由于 Office 的代码量太大,这个东西的开发者没有为如此大的代码规划软件。

b) 许多东西在前史中不断演化, 有自己一起的特色,许多和企业内部的某些特别需求有关,外部东西很难都完结这样的功用。

许多东西联合在一起,会形成了一个东西的生态,但假如只改动一个东西,让其他的东西变得不兼容, 那整个团队的许多作业流就会呈现问题。

此外,邹欣标明,代码保管与 AI 结合是未来发展方向。例如,这种结合会告知你昨天晚上签入代码有问题, 或许签入代码和某极彩彩票官网-为何Google、微软、华为将亿级源代码放一个库房?从全球最大代码办理库说起个其他团队的代码相似,主张重用。或许告知你签入的代码是从网上复制来的, 而且把本来代码中的 bug 也复制过来了。

终究,AI 科技大本营引证此前微软云开发服务副总裁 Brian Harry 于 2017 年宣布的一篇博文内容,在微软推出 VFS For Git 三个月后,他同享了该渠道的更多细节及其未来方针,包含扩大开放源代码并改善其在 Microsoft 上的运转体现,想要了解 VFS For Git 更具体的信息,无妨细心研读一下这篇文章:

用 Git 办理 Windows

用 Git 办理 Windows

在曩昔三个月中,咱们现已基本完结了向 Microsoft Windows 团队推出 Git/GVFS 的作业。

在曩昔三个月中,咱们现已基本完结了向 Microsoft Windows 团队推出 Git/GVFS 的作业。

Windows 代码库大约有 350 万个文件,当迁入 Git 版别库时将发生 300GB 的存储量。此外,Windows 团队约有 4000 名工程师,这个巨大的工程师体系每天都要处理不计其数次验证恳求,在 440 个分支里进行 1760 次实验性改动。在一切的三个维度(文件计数、版别库巨细和活动)都是令人生畏的扩展应战,这些要素搀杂在一起使得这个作业变得反常困难。在搬迁到 Git 之前,这些数据储存在 40 多个不同的库房里,咱们需求跨过多个库进行操作。

Windows 代码库大约有 350 万个文件,当迁入 Git 版别库时将发生 300GB 的存储量。此外,Windows 团队约有 4000 名工程师,这个巨大的工程师体系每天都要处理不计其数次验证恳求,在 440 个分支里进行 1760 次实验性改动。在一切的三个维度(文件计数、版别库巨细和活动)都是令人生畏的扩展应战,这些要素搀杂在一起使得这个作业变得反常困难。在搬迁到 Git 之前,这些数据储存在 40 多个不同的库房里,咱们需求跨过多个库进行操作。

在我三个月前编撰文本的时分,咱们将一切代码都储存在一个 Git 版别库里,几百名工程师在很小一部分日常构建(<10%)中运用并对它进行了测验,自此咱们在整个工程团队里掀起了波涛。

在我三个极彩彩票官网-为何Google、微软、华为将亿级源代码放一个库房?从全球最大代码办理库说起月前编撰文本的时分,咱们将一切代码都储存在一个 Git 版别库里,几百名工程师在很小一部分日常构建(<10%)中运用并对它进行了测验,自此咱们在整个工程团队里掀起了波涛。

第一次也是最大的一次作业发生在 3 月 22 日,其时咱们向具有约 2000 名工程师的 Windows OneCore 团队推行了 Git。他们周五在 Source Deport 上作业,周末回家,然后周一上班时体会 Git 的作用。咱们团队中的每个人在周末时都屏住呼吸,祈求周一上班时不会被一帮丢了代码的暴怒工程师围殴。但事实上,Windows 团队在备份计划方面做的十分超卓,也谢天谢地咱们并没有运用到这些计划。

第一次也是最大的一次作业发生在 3 月 22 日,其时咱们向具有约 2000 名工程师的 Windows OneCore 团队推行了 Git。他们周五在 Source Deport 上作业,周末回家,然后周一上班时体会 Git 的作用。咱们团队中的每个人在周末时都屏住呼吸,祈求周一上班时不会被一帮丢了代码的暴怒工程师围殴。但事实上,Windows 团队在备份计划方面做的十分超卓,也谢天谢地咱们并没有运用到这些计划。

老实说我关于作业进行的那么顺利仍是很惊奇的。毫无疑问咱们遇到了一些问题,由于巨大的团队规划和作业性质的问题,Windows 一般会在各个分支部分之间进行大兼并,导致每个小改动都会引发多个部分的一起改动。第一周时咱们发现咱们提出需求和处理矛盾的 UI 底子无法应对这么大规划的一起改动。咱们手忙脚乱地把列表虚拟化并逐步获取数据,以便 UI 不至于忙到挂起。咱们在几天之后处理了这个问题,整体来说,这周的体会比咱们幻想的要好得多。

老实说我关于作业进行的那么顺利仍是很惊奇的。毫无疑问咱们遇到了一些问题,由于巨大的团队规划和作业性质的问题,Windows 一般会在各个分支部分之间进行大兼并,导致每个小改动都会引发多个部分的一起改动。第一周时咱们发现咱们提出需求和处理矛盾的 UI 底子无法应对这么大规划的一起改动。咱们手忙脚乱地把列表虚拟化并逐步获取数据,以便 UI 不至于忙到挂起。咱们在几天之后处理了这个问题,整体来说,这周的体会比咱们幻想的要好得多。

咱们衡量成功的办法之一是在工程师团队中进行满足度查询。除了核心问题“你对它满足吗?“,咱们还提出了一些小问题。两周之后咱们第一次查询成果如下:

咱们衡量成功的办法之一是在工程师团队中进行满足度查询。除了核心问题“你对它满足吗?“,咱们还提出了一些小问题。两周之后咱们第一次查询成果如下:

从上往下分别为:十分满足,还算满足,不太满足,十分不满足

从上往下分别为:十分满足,还算满足,不太满足,十分不满足

咱们没有为这个查询成果开个派对庆祝,但作为一个历经千难万险不断学习新技能的开发团队,咱们对这个前进仍是十分高兴的。2000 个人的团队只要 251 个人回复了咱们的查询,咱们欢迎更多的人给予咱们点评。

咱们没有为这个查询成果开个派对庆祝,但作为一个历经千难万险不断学习新技能的开发团队,咱们对这个前进仍是十分高兴的。2000 个人的团队只要 251 个人回复了咱们的查询,咱们欢迎更多的人给予咱们点评。

别的一个衡量成功与否的办法是检查“工程活动”以查询工程师们是否完结作业。例如,咱们核算了官方分支的运用“报到数”,团队中有一半工程师运用 Source Depot ,另一半搬迁到了 Git 上,因而咱们对一段时刻内的归纳活动进行了研讨。鄙人面的图表中,Source Depot 的报到数大幅下降,而从 Git 输出的恳求大幅跃升,但两者的归纳坚持相对共同,咱们以为该数据标明这个体系正在无阻运转。

别的一个衡量成功与否的办法是检查“工程活动”以查询工程师们是否完结作业。例如,咱们核算了官方分支的运用“报到数”,团队中有一半工程师运用 Source Depot ,另一半搬迁到了 Git 上,因而咱们对一段时刻内的归纳活动进行了研讨。鄙人面的图表中,Source Depot 的报到数大幅下降,而从 Git 输出的恳求大幅跃升,但两者的归纳坚持相对共同,咱们以为该数据标明这个体系正在无阻运转。

标题为 每日检出量

4 月 22 日,咱们约请新一批约 1000 名工程师参与测验部队,5 月 12 日咱们又约请了 300-400 名。每一批新参与的工程师都差不是相同的作业形式,现在 Git 上有 3500-4000 名微软工程师。其他的小组正在准时完结作业并核算搬迁计划的最佳时刻点,我猜测接下来的几个月里应该能完结整个工程师团队的搬迁。

4 月 22 日,咱们约请新一批约 1000 名工程师参与测验部队,5 月 12 日咱们又约请了 300-400 名。每一批新参与的工程师都差不是相同的作业形式,现在 Git 上有 3500-4000 名微软工程师。其他的小组正在准时完结作业并核算搬迁计划的最佳时刻点,我猜测接下来的几个月里应该能完结整个工程师团队的搬迁。

整个体系的规划令人惊奇,让咱们看一些数字...

整个体系的规划令人惊奇,让咱们看一些数字...

- 曩昔 4 个月里,有超越 250000 个能够追溯的 commit

- 曩昔 4 个月里,有超越 250000 个能够追溯的 commit

- 均匀每天 8421 次 push

- 均匀每天 8421 次 push

- 均匀每个作业日 2500 次 pull 恳求和 6600 个回复的人

- 均匀每个作业日 2500 次 pull 恳求和 6600 个回复的人

- 4352 个活泼主题分支

- 4352 个活泼主题分支

- 每天 1760 个由官方建立(build)的测验

- 每天 1760 个由官方建立(build)的测验

如你所见,这个巨大的版别库里正在进行着许多的活动。

如你所见,这个巨大的版别库里正在进行着许多的活动。

GVFS 的大规划功用

GVFS 的大规划功用

在满足度查询里,有部分工程师对这个体系标明不满。咱们有许多数据来解说原因—-从部分东西尚不支撑 Git 到学习新知识的懊丧感。但我想深入研讨一个首要问题:Git 自身的功用。咱们知道当咱们推出 Git 时还有许多作业没有完结,还有许多新东西不断参与。咱们盯梢一些Git要害操作的体现。以下是遥测体系从大约 3500 名工程师里收集到的 GVFS 运用数据。

在满足度查询里,有部分工程师对这个体系标明不满。咱们有许多数据来解说原因—-从部分东西尚不支撑 Git 到学习新知识的懊丧感。但我想深入研讨一个首要问题:Git 自身的功用。咱们知道当咱们推出 Git 时还有许多作业没有完结,还有许多新东西不断参与。咱们盯梢一些Git要害操作的体现。以下是遥测体系从大约 3500 名工程师里收集到的 GVFS 运用数据。

表中的方针代表最糟糕的状况,假如体系的运转时刻高于此值则无法运用,这并不是“咱们期望体系在这个规模”的值。比照前7天和后7天在80%位点上的改动量,一切的数值都在变慢。

表中的方针代表最糟糕的状况,假如体系的运转时刻高于此值则无法运用,这并不是“咱们期望体系在这个规模”的值。比照前7天和后7天在80%位点上的改动量,一切的数值都在变慢。

假如在作业开端之前运用 “Vanilla Git”,许多指令或许需求30分钟到几个小时都无法完结。为了一个只需求20秒的指令等候10-15秒是一个很糟糕的作业。

假如在作业开端之前运用 “Vanilla Git”,许多指令或许需求30分钟到几个小时都无法完结。为了一个只需求20秒的指令等候10-15秒是一个很糟糕的作业。

当咱们第一次推出它时,成果要好得多。事实证明,跟着时刻消逝,工程师从代码库里学习的越来越多,然后导致了咱们称为“过度饱满”的问题。终究工程师仅仅获得了一堆偶然运用、不再进行修正的废文件。这导致了功用的逐步下降。人们能够将这些文件参与收拾,但这很费事,也很少人这么做,一朝一夕体系越来越慢。

当咱们第一次推出它时,成果要好得多。事实证明,跟着时刻消逝,工程师从代码库里学习的越来越多,然后导致了咱们称为“过度饱满”的问题。终究工程师仅仅获得了一堆偶然运用、不再进行修正的废文件。这导致了功用的逐步下降。人们能够将这些文件参与收拾,但这很费事,也很少人这么做,一朝一夕体系越来越慢。

这启发了咱们开端另一轮称为“O(modified)”的功用优化,它将许多要害指令更改为与用户修正过的文件数量成正比。咱们将鄙人周把这些修正推行到团队里,所以现在还没有统计数据,但参与前期测验的用户遍及反映杰出。

这启发了咱们开端另一轮称为“O(modified)”的功用优化,它将许多要害指令更改为与用户修正过的文件数量成正比。咱们将鄙人周把这些修正推行到团队里,所以现在还没有统计数据,但参与前期测验的用户遍及反映杰出。

我没有悉数数据,但我从上个表格中挑选了一些案例并把体现成果复制到“O 饱满(hydrated)列”,运用下周即将推出的功用增强后得到的履行成果列为“O 改动(Modified)”。一切数字都以秒为单位。从表中咱们能够看到功用有了全面前进—有些很小,有些大约2倍,状况快了将近5倍。咱们十分达观,这些改动将前进用户体会。虽然我永久不会满足(直到状况低于1秒我才会满足),但这个前进仍是让我高兴。

我没有悉数数据,但我从上个表格中挑选了一些案例并把体现成果复制到“O 饱满(hydrated)列”,运用下周即将推出的功用增强后得到的履行成果列为“O 改动(Modified)”。一切数字都以秒为单位。从表中咱们能够看到功用有了全面前进—有些很小,有些大约2倍,状况快了将近5倍。咱们十分达观,这些改动将前进用户体会。虽然我永久不会满足(直到状况低于1秒我才会满足),但这个前进仍是让我高兴。

影响体现的要害要素还有分布式团队。Windows 的工程师遍及全世界—美国、欧洲、中东、印度和我国等。长间隔大规模拉取数据是一个问题。为了处理这个问题,咱们花大力气构建了一个用于 GVFS 的 Git 署理处理计划,该计划让咱们能够“在边际”缓存 Git 数据。咱们还在顶峰负载期运用 Visual Studio 团队服务分管了许多流量,防止危害用户体会。总的来说,咱们在全球规模内有 20 个 Git 署理。

影响体现的要害要素还有分布式团队。Windows 的工程师遍及全世界—美国、欧洲、中东、印度和我国等。长间隔大规模拉取数据是一个问题。为了处理这个问题,咱们花大力气构建了一个用于 GVFS 的 Git 署理处理计划,该计划让咱们能够“在边际”缓存 Git 数据。咱们还在顶峰负载期运用 Visual Studio 团队服务分管了许多流量,防止危害用户体会。总的来说,咱们在全球规模内有 20 个 Git 署理。

让我举个比如,Windows 团队服务账户坐落美国西海岸的 Azure 数据中心。在这个当地,Windows 工程师克隆速度的 80% 位点为 127 秒。这是由于咱们大部分微软工程师都在Redmond,这个数据首要是由他们主导。咱们在北卡罗莱那州的办公室(间隔咱们很远而且宽带较低)进行了测验。不运用署理服务器的状况下,从北卡罗来纳州进行克隆需求25分钟,而在装备了署理服务器并坚持更新的状况下,该进程仅花费了 70 秒(比 Redmond 更快,由于 Redmond 团队比运用署理服务器,他们有必要经过网络跨过数百英里抵达 Azure 数据中心)。从 70 秒到 25 分钟,功用前进了将近 95%。

让我举个比如,Windows 团队服务账户坐落美国西海岸的 Azure 数据中心。在这个当地,Windows 工程师克隆速度的 80% 位点为 127 秒。这是由于咱们大部分微软工程师都在Redmond,这个数据首要是由他们主导。咱们在北卡罗莱那州的办公室(间隔咱们很远而且宽带较低)进行了测验。不运用署理服务器的状况下,从北卡罗来纳州进行克隆需求25分钟,而在装备了署理服务器并坚持更新的状况下,该进程仅花费了 70 秒(比 Redmond 更快,由于 Redmond 团队比运用署理服务器,他们有必要经过网络跨过数百英里抵达 Azure 数据中心)。从 70 秒到 25 分钟,功用前进了将近 95%。

整体来说,搭载 GVFS 的 Git 完全能够在大规划状况下有效地被运用。一起,咱们做了许多作业使工程师们对它的体现标明“满足”,但在咱们完结整个项现在,咱们依然有许多能够改善的当地。

整体来说,搭载 GVFS 的 Git 完全能够在大规划状况下有效地被运用。一起,咱们做了许多作业使工程师们对它的体现标明“满足”,但在咱们完结整个项现在,咱们依然有许多能够改善的当地。

开发者试用 GVFS

开发者试用 GVFS

GVFS 是一个开源项目,任何人都欢迎来测验一下。你只需求下载和装置,创立一个带有 Git 版别库的 Visual Studio 团队服务账号就能够开端运用。自从咱们开端发布 GVFS 以来,咱们现已取得了许多不错的前进,一些首要的改善包含:

GVFS 是一个开源项目,任何人都欢迎来测验一下。你只需求下载和装置,创立一个带有 Git 版别库的 Visual Studio 团队服务账号就能够开端运用。自从咱们开端发布 GVFS 以来,咱们现已取得了许多不错的前进,一些首要的改善包含:

咱们对现已发布的代码库进行定时更新—正朝着“公共开发”跨进。到现在,咱们一切的最新改动(包含O 改动(modified)的改善)均已发布到公共库里,咱们将定时对其进行更新。

咱们对现已发布的代码库进行定时更新—正朝着“公共开发”跨进。到现在,咱们一切的最新改动(包含O 改动(modified)的改善)均已发布到公共库里,咱们将定时对其进行更新。

GVFS 依赖于名为 GVFIt 的 Windows 文件驱动体系。现在为止,咱们供给的该驱动程序还正式试用(由于还有许多进行中的作业),明显这导致许多测验抵触。今日咱们发布了签名版别的 GVFIt 并消除了这个问题(例如用户不再需求禁用 BitLocker 后才干装置它)。虽然咱们有试用的 GVFIt 驱动程序,但这并不是一个可维持的交给办法,咱们期望这个功用能够组合进未来的 Windows 发行版里。

GVFS 依赖于名为 GVFIt 的 Windows 文件驱动体系。现在为止,咱们供给的该驱动程序还正式试用(由于还有许多进行中的作业),明显这导致许多测验抵触。今日咱们发布了签名版别的 GVFIt 并消除了这个问题(例如用户不再需求禁用 BitLocker 后才干装置它)。虽然咱们有试用的 GVFIt 驱动程序,但这并不是一个可维持的交给办法,咱们期望这个功用能够组合进未来的 Windows 发行版里。

从咱们在 Git Merge 的讲演开端,咱们针对 Git 和 GVFS 扩展问题与更广泛的Git社区进行了互动。在与其他大型科技公司(例如谷歌和 Facebook )进行了对话时,咱们发现他们也面临着相似的应战,所以向他们同享了经历与办法。咱们还与一些抢手的 Git 客户协作,以保证他们在 GVFS 上的顺利体会,包含 Atlassian Source Tree、Tower Git 团队、Visual Studio、Git for Windows 等。

从咱们在 Git Merge 的讲演开端,咱们针对 Git 和 GVFS 扩展问题与更广泛的Git社区进行了互动。在与其他大型科技公司(例如谷歌和 Facebook )进行了对话时,咱们发现他们也面临着相似的应战,所以向他们同享了经历与办法。咱们还与一些抢手的 Git 客户协作,以保证他们在 GVFS 上的顺利体会,包含 Atlassian Source Tree、Tower Git 团队、Visual Studio、Git for Windows 等。

总结

总结

咱们将持续尽力把 Git 扩展到足以支撑大型团队的代码库,从第一次记载这些作业已通曩昔了三个月,这期间发生了许多事,咱们团队现已...

咱们将持续尽力把 Git 扩展到足以支撑大型团队的代码库,从第一次记载这些作业已通曩昔了三个月,这期间发生了许多事,咱们团队现已...

- 成功将其推行给3000个微软工程师

- 成功将其推行给3000个微软工程师

- 进行了一些严重的功用改善并引入了 Git 署理

- 进行了一些严重的功用改善并引入了 Git 署理

- 浮荡用最新代码更新了开源项目,并开端欢迎外部协助

- 用最新代码更新了开源项目,并开端欢迎外部协助

- 供给了签名版别的 GVFIt 驱动并降低了它的运用难度

- 供给了签名版别的 GVFIt 驱动并降低了它的运用难度

- 与社区协作,为抢手东西(SourceTree、Tower、Visual Studio等)供给支撑

- 与社区协作,为抢手东西(SourceTree、Tower、Visual Studio等)供给支撑

- 宣布了一些文章同享咱们对 Git 和 GVFS 运用技能的更多见地

- 宣布了一些文章同享咱们对 Git 和 GVFS 运用技能的更多见地

不管对微软团队仍是我的团队,这都是一个激动人心的改动。这是一个极具应战的项目,我为前进喝彩,也为剩余的作业头疼。现在,Visual Studio 团队服务是仅有支撑 GVFS 协议增强功用的后端完结。假如市场反应够强,咱们会与 Team Foundation 服务器和其他 Git 服务洽谈增加支撑。

不管对微软团队仍是我的团队,这都是一个激动人心的改动。这是一个极具应战的项目,我为前进喝彩,也为剩余的作业头疼。现在,Visual Studio 团队服务是仅有支撑 GVFS 协议增强功用的后端完结。假如市场反应够强,咱们会与 Team Foundation 服务器和其他 Git 服务洽谈增加支撑。

相关链接:

https://devblogs.microsoft.com/bharry/the-largest-git-repo-on-the-planet/

(*本文为 AI科技大本营收拾文章, 转 载请微 信联络 1092722531 )

即日起,定量 5 折票开售,数量有限,扫码购买,先到先得!

极彩彩票官网-为何Google、微软、华为将亿级源代码放一个库房?从全球最大代码办理库说起
  • 极彩彩票官网-外商看好我国 外资大项目加快落地
  • 请关注微信公众号
    微信二维码
    不容错过
    Powered By Z-BlogPHP