分布式版本控制系统 Git 将迎来巨大的性能提升 —— Git 协议 v2 已正式推出。
来自 Git 团队的 Brandon Williams 今天在博客上宣布推出了 Git 协议的 v2 版本(Git protocol version 2)，v2 协议又叫做 Git Wire Protocol，Git 协议 2.0 版本效率更高，并拥有显著的性能优势，旨在改进 Git 的传输过程。
新的 Git 线协议为 reference 提供服务端过滤、让扩展新特性变得更容易以及简化 HTTP 传输的客户端处理。
谷歌已经在内部使用新版本的 Git 协议来提升速度。Brandon Williams 解释道：“对于包含 500k references 的仓库中的单个分支的无操作读取，性能提升了 3 倍。新版本协议还使得从 googlesource.com 服务器发送出来的开销字节数减少到原先的八分之一。这种改进主要是由于只返回客户端需要的 reference。”
Git protocol-v2 的开发成果在不到两周前合并到了 Git 2.18 的 mainline 上。凭借着显著的优势，谷歌已经在 Google Source 和 Cloud Source 仓库的 Git 服务器上支持这项新协议。
详情请查看谷歌的 Open-Source 博客。
引用来自“久永”的评论
@kut @mark35 @marlondu这么多条留言，真把我吓坏了！
那么多反驳的人，知道我用 git 开发过工具码？
我不是说用git，而是说读写 git 库，比如将 git 的提交日志导出为工作日志。比如改进 git 客户端，比如 各位知道有哪些 git 的开发包？同种语言的开发包有哪些差异？
—— 谁跟你们说，我不会用命令行的了？太可笑了吧？
我说的是效率！请记住这一点！
就像明明有IDE，却非要用记事本开发，还自觉得是高手——是的，我说的就是你！
可视化起码有两个好处（当然远不止这个两个好处）：
减轻记忆和输入负担，减少命令操作错误可能。
更加丰富直观的交互，便于接收更多的信息。
而且，估计习惯命令行的都没有用过可视化外壳，基本常用的可视化外壳，都可以使用命令。且都提供其实际运行的命令现实，以便你确认和修改。
明明一个菜单点两下的事，有的人非要输一句话大小的命令，来显摆自己懂 git ?
懂 git 重整过开发历史吗？不需要？对不起，你的思维还停留在 svn 时代，认为开发库要记录的“真实”的历史，
而我们不这么认为，我们认为开发库应该记录“有用”的历史。
用过 git 的“低级”命令吗？
做过拆库、拼库、接库、断库 吗？
所谓的“老鸟”？
作为国内几乎最早一批用 git ，而且还做过 git 可视化外壳翻译/汉化工作的“菜鸟”求求你们，绕了哪些刚开始啃 git 想入门的新手吧！
💧 误人子弟，等于谋财害命，好吗？💧
引用来自“kut”的评论
好委屈的样子。😂引用来自“久永”的评论
@kut @mark35 @marlondu这么多条留言，真把我吓坏了！
那么多反驳的人，知道我用 git 开发过工具码？
我不是说用git，而是说读写 git 库，比如将 git 的提交日志导出为工作日志。比如改进 git 客户端，比如 各位知道有哪些 git 的开发包？同种语言的开发包有哪些差异？
—— 谁跟你们说，我不会用命令行的了？太可笑了吧？
我说的是效率！请记住这一点！
就像明明有IDE，却非要用记事本开发，还自觉得是高手——是的，我说的就是你！
可视化起码有两个好处（当然远不止这个两个好处）：
减轻记忆和输入负担，减少命令操作错误可能。
更加丰富直观的交互，便于接收更多的信息。
而且，估计习惯命令行的都没有用过可视化外壳，基本常用的可视化外壳，都可以使用命令。且都提供其实际运行的命令现实，以便你确认和修改。
明明一个菜单点两下的事，有的人非要输一句话大小的命令，来显摆自己懂 git ?
懂 git 重整过开发历史吗？不需要？对不起，你的思维还停留在 svn 时代，认为开发库要记录的“真实”的历史，
而我们不这么认为，我们认为开发库应该记录“有用”的历史。
用过 git 的“低级”命令吗？
做过拆库、拼库、接库、断库 吗？
所谓的“老鸟”？
作为国内几乎最早一批用 git ，而且还做过 git 可视化外壳翻译/汉化工作的“菜鸟”求求你们，绕了哪些刚开始啃 git 想入门的新手吧！
💧 误人子弟，等于谋财害命，好吗？💧
引用来自“改着名儿玩”的评论
这样子吹，linus愿意么？引用来自“南湖船老大”的评论
git本来性能就低。。。有啥不能承认的，尤其是大文件和大数据量的情况下，为此还有专门的优化程序引用来自“山雨欲来”的评论
git是用来管理代码的，你这样说我也可以说微软的word很垃圾，放不下一个PB的数据，人家压根不是做这个的引用来自“南湖船老大”的评论
微软的word套件，编译后都有1个多G，源码那就得好几个G。微软的vs，光安装包就十几个G，据说源码有200多G。这些难道不是代码么。。。
引用来自“冰力”的评论
谷歌 什么时候能改掉吹牛逼的毛病？引用来自“不及阁大学士”的评论
谷歌，人类的希望，比那个卖假药的不知道高到哪里去了引用来自“久永”的评论
我奇怪，为什么那么好用免费的UI不用，非要用命令行？引用来自“marlondu”的评论
以后你会明白的引用来自“久永”的评论
我奇怪，为什么那么好用免费的UI不用，非要用命令行？引用来自“司徒永超”的评论
我现在是混用能用UI尽量用UI，第一次费事找下，后面就方便了。
引用来自“久永”的评论
我奇怪，为什么那么好用免费的UI不用，非要用命令行？引用来自“CrazyPeter”的评论
主要是因为UI界面操作的指令实际上也都是用命令行来执行，所以先有命令行，后有UI交互。另外如果真的想要深度使用git，命令行的练习是一定要有的。
我的建议是，先用界面外壳熟悉功能和使用，
再在界面外壳的使用过程中，满满的熟悉命令。
起码对于外壳现实的命令能懂个八分。
而这个过程也不是“练习”来的，应该看 git 的官方文档，熟悉 git 的设计思想。
在此基础上“理解”而不是仅仅“懂”git的命令。之后你才能游刃有余，哪怕没有的命令，你也能组合起来实现自己需要的操作。
否则，约到底层越搞不懂 git 的命令。
普通开发人员熟悉基本的操作，会用外壳就行了。
团队里一定要有个精通 git 一点的，
否则一旦出了问题，找不到人帮忙搞 git 的复杂不常用的操作，那就头大了。
引用来自“改着名儿玩”的评论
这样子吹，linus愿意么？引用来自“南湖船老大”的评论
git本来性能就低。。。有啥不能承认的，尤其是大文件和大数据量的情况下，为此还有专门的优化程序这么多条留言，真把我吓坏了！
那么多反驳的人，知道我用 git 开发过工具码？
我不是说用git，而是说读写 git 库，比如将 git 的提交日志导出为工作日志。比如改进 git 客户端，比如 各位知道有哪些 git 的开发包？同种语言的开发包有哪些差异？
—— 谁跟你们说，我不会用命令行的了？太可笑了吧？
我说的是效率！请记住这一点！
就像明明有IDE，却非要用记事本开发，还自觉得是高手——是的，我说的就是你！
可视化起码有两个好处（当然远不止这个两个好处）：
减轻记忆和输入负担，减少命令操作错误可能。
更加丰富直观的交互，便于接收更多的信息。
而且，估计习惯命令行的都没有用过可视化外壳，基本常用的可视化外壳，都可以使用命令。且都提供其实际运行的命令现实，以便你确认和修改。
明明一个菜单点两下的事，有的人非要输一句话大小的命令，来显摆自己懂 git ?
懂 git 重整过开发历史吗？不需要？对不起，你的思维还停留在 svn 时代，认为开发库要记录的“真实”的历史，
而我们不这么认为，我们认为开发库应该记录“有用”的历史。
用过 git 的“低级”命令吗？
做过拆库、拼库、接库、断库 吗？
所谓的“老鸟”？
作为国内几乎最早一批用 git ，而且还做过 git 可视化外壳翻译/汉化工作的“菜鸟”求求你们，绕了哪些刚开始啃 git 想入门的新手吧！
💧 误人子弟，等于谋财害命，好吗？💧
引用来自“改着名儿玩”的评论
这样子吹，linus愿意么？引用来自“南湖船老大”的评论
git本来性能就低。。。有啥不能承认的，尤其是大文件和大数据量的情况下，为此还有专门的优化程序引用来自“山雨欲来”的评论
git是用来管理代码的，你这样说我也可以说微软的word很垃圾，放不下一个PB的数据，人家压根不是做这个的这些难道不是代码么。。。
引用来自“改着名儿玩”的评论
这样子吹，linus愿意么？引用来自“南湖船老大”的评论
git本来性能就低。。。有啥不能承认的，尤其是大文件和大数据量的情况下，为此还有专门的优化程序引用来自“不及阁大学士”的评论
谷歌，人类的希望，比那个卖假药的不知道高到哪里去了引用来自“peakandyuri”的评论
google虽然提供很多好用的服务，但是它也在为美国国防部做事，对中国也算是有威胁的。引用来自“不及阁大学士”的评论
谷歌，人类的希望，比那个卖假药的不知道高到哪里去了引用来自“久永”的评论
我奇怪，为什么那么好用免费的UI不用，非要用命令行？另外如果真的想要深度使用git，命令行的练习是一定要有的。
引用来自“久永”的评论
我奇怪，为什么那么好用免费的UI不用，非要用命令行？引用来自“久永”的评论
我奇怪，为什么那么好用免费的UI不用，非要用命令行？引用来自“久永”的评论
我奇怪，为什么那么好用免费的UI不用，非要用命令行？引用来自“开源中国首席效率专家”的评论
你们用git怎么查看远程服务端最新的更新列表的？？引用来自“whiter001”的评论
git fetch origin master:tmp然后log或者diff
或者sourceTree之类的吧
引用来自“开源中国首席效率专家”的评论
@whiter001 我试过了，不行，是否我操作有问题？引用来自“whiter001”的评论
实际上就是 拉去一个最新版到本地tmptmp是新建的临时分支
然后对比这两个分支
可以checkout一下到最新的tmp, 也都会提示哪些文件有改动的
git log origin/master
引用来自“久永”的评论
我奇怪，为什么那么好用免费的UI不用，非要用命令行？引用来自“改着名儿玩”的评论
这样子吹，linus愿意么？引用来自“开源中国首席效率专家”的评论
你们用git怎么查看远程服务端最新的更新列表的？？引用来自“whiter001”的评论
git fetch origin master:tmp然后log或者diff
或者sourceTree之类的吧
引用来自“开源中国首席效率专家”的评论
@whiter001 我试过了，不行，是否我操作有问题？引用来自“whiter001”的评论
实际上就是 拉去一个最新版到本地tmptmp是新建的临时分支
然后对比这两个分支
可以checkout一下到最新的tmp, 也都会提示哪些文件有改动的
git diff master tmp --stat
git tmp -d
引用来自“Schr0dingerCat”的评论
@脱袜子 弄了个git 然后就不管了？😃引用来自“开源中国首席效率专家”的评论
你们用git怎么查看远程服务端最新的更新列表的？？引用来自“whiter001”的评论
git fetch origin master:tmp然后log或者diff
或者sourceTree之类的吧
引用来自“开源中国首席效率专家”的评论
@whiter001 我试过了，不行，是否我操作有问题？引用来自“whiter001”的评论
实际上就是 拉去一个最新版到本地tmptmp是新建的临时分支
然后对比这两个分支
可以checkout一下到最新的tmp, 也都会提示哪些文件有改动的
引用来自“开源中国首席效率专家”的评论
你们用git怎么查看远程服务端最新的更新列表的？？引用来自“whiter001”的评论
git fetch origin master:tmp然后log或者diff
或者sourceTree之类的吧
引用来自“开源中国首席效率专家”的评论
@whiter001 我试过了，不行，是否我操作有问题？tmp是新建的临时分支
然后对比这两个分支
可以checkout一下到最新的tmp, 也都会提示哪些文件有改动的
引用来自“开源中国首席效率专家”的评论
你们用git怎么查看远程服务端最新的更新列表的？？引用来自“whiter001”的评论
git fetch origin master:tmp然后log或者diff
或者sourceTree之类的吧
引用来自“开源中国首席效率专家”的评论
你们用git怎么查看远程服务端最新的更新列表的？？然后log或者diff
或者sourceTree之类的吧