原文链接： What’s new in Git 2.1 - Tim Pettersen
译文发在博乐在线： http://blog.jobbole.com/76550/，2014-09-08
在git 2.0.0发布2个半月后，作为小版本更新迎来了2.1.0，带来了一大波令人兴奋的新特性。
完整的发布说明文档可以在这里查看，但如果你不怎么接触git社区，会觉得发布说明文档有些太简明了。这篇文章是我对这次发布在Atlassian使用中令我们兴奋的方面所做的评注。
本文引文都是直接摘自发布说明文档，其中会加上自己的评注。
从很早期的
Git开始，调用less分页程序用的LESS环境变量设置的缺省值是FRSX。S选项（截断长文本行而不是折行）从缺省值中删除了，因为对不同的人有不同的说法，这个选项或多或少是个人口味问题。相比，其它的选项作为缺省设置是合理的（如，R选项非常合理，因为很多不同的输出都是彩色的，而FX也是合理的，因为输出常常短于一页。）
如果你还没有覆盖过git分页程序的缺省值，这个变化意味着git命令的分页输出会在终端宽度的地方折行而不是截断行。下面是git 2.1.0（折行，左图）和git 2.0.3（截断，右图）显示的例子：
这个只会影响你日志的输出，如果你用的是一个窄的终端，或者在提交消息中有长行。一般git推荐提交日志信息的宽度不要超过72字符，但如果觉得折行很烦，可以通过恢复原来的行为来禁用：
$ git config core.pager "less -S"当然，分页程序也会用于其它的输出，比如git blame，这种情况下由于作者名的长度和代码风格，可以能会有很长的行。2.1.0的发布说明文档也指出了可以只在blame的分页程序中启用-S选项：
$ git config pager.blame "less -S"如果你对git还在使用的缺省less选项很好奇，说明如下：
-F：让less进程自动退出，如果输出少于一页。-R：保证只有ANSI颜色转义序列按原始形式输出，这样git控制台颜色才能生效。-X：避免屏幕在less启动时被清空。这个也是在less输出少于一页时才有用。
更新了
Bash的补全脚本（在contrib/目录），能更好地处理定义了复杂命令序列的别名。
这个超酷！我是一个自定义git别名的大粉丝。能够在复杂的别名上用上git的Bash自动补全，让这些别名在命令行上使用起来更强大和方便。举个例子，我定义一个可以从日志中grep出JIRA风格的issue主键（如STASH-123）的别名：
issues = !sh -c 'git log --oneline $@ | egrep -o [A-Z]+-[0-9]+ | sort | uniq' -所有的命令行参数传给git log命令，这样可以限制提交的范围用于返回issue主键。比如，git issues -n 1只会显示我的分支最近一次提交所关联的issue主键。在2.1.0中，git的Bash补全让我可以像git log命令一样去补全git的issue别名。
在git 2.0.3下，键入git issues m<tab>会退化成缺省的Bash补全行为，列出当前目录下m开头的文件。在git 2.1.0下，正确地补全成master，就和git log命令下补全动作一样。通过在别名加上空命令前缀:，可以用于提示Bash补全行为。如果要补全的不是别名中的第一个命令，这个很有用。举个例子：
issues = "!f() { echo 'Printing issue keys'; git log --oneline $@ | egrep -o [A-Z]+-[0-9]+ | sort | uniq; }; f"这个别名不能正常补全，因为git不能把echo命令识别为补全目标。但如果加上前缀成: git log;，补全就正确了：
issues = "!f() { : git log ; echo 'Printing issue keys'; git log --oneline $@ | egrep -o [A-Z]+-[0-9]+ | sort | uniq; }; f"如果你喜欢编写复杂的别名脚本，这是个可用性的巨大改进！请记住，补全功能的脚本在contrib/目录下，不是git核心的一部分，所以如果你要使用这个功能，不要忘了更新Bash profile指向新版本的contrib/completion/git-completion.bash。
git commit ‐‐date=<date>选项有了更多的时间戳格式选项，包括--date=now。
当严格的parse_date()函数不能解析给的日期字符串时，git提交的--date选项现在会回退到git酷炫的（也有些古怪的）approxidate（大概日期）解析器。approxidate可以处理显而易见的值，像--date=now，也允许一些略复杂格式，像--date="midnight the 12th of october, anno domini 1979"或是--date=teatime。如果你想了解更多，Alex Peattie有一篇优秀的关于git酷炫日期处理的博文。
git grep会读取grep.fullname配置变量，强制‐‐full-name成为缺省。这可能会让以脚本方式使用的用户出错，这些用户不期望这样的新行为。
省得你去翻git-grep的man，下面是--full-name选项的文档说明：
--full-name当从子目录运行时，命令输出的路径通常相对于当前目录。这个选项强制输出的路径是相对项目的顶级目录。
非常贴心！这个缺省行为非常符合我的工作方式，我常常会运行git grep找出一个文件的路径，拷贝粘贴到一个XML文件中（这样的做法可能出卖了我是个Java开发 😁）。如果你也觉得有用，只要简单运行：
$ git config --global grep.fullname true在你的配置文件开启这个选项。
--global选项把配置应用到$HOME/.gitconfig文件中，这样配置值就会成为我系统上所有git仓库的缺省行为。如果有必要，你可以也只在仓库级别覆盖配置值。
停一会儿！先看看git replace能做什么？
简单地说，git replace重写git仓库中的某个对象并且不保持对应树或是提交的SHA不变。如果你是第一次听到git replace并且知道git的数据模型，会觉得这样的做法听起来很逆天！我就是这么觉得。我有另一篇正在写的博文讨论什么时候和为什么要使用这样的功能。如果现在你想了解更多，看这篇文章比看man手册好得多，手册中只有很少且有些牵强的用例说明。
git replace会读取--edit选项，可以编辑一个已有的对象再做替换。
--edit选项会dump一个对象的内容到一个临时文件，启动你喜欢的编辑器，这样就可以方便地拷贝和替换这个对象。要替换master分支的最近那次提交，可以简单运行命令：
$ git replace --edit master或者编辑最近那次提交的blob，假设是文件jira-components/pom.xml，可以运行命令：
$ git replace --edit master:jira-components/pom.xml应该这么做？基本上不会 😄 大部分情况应该用git rebase重写对象，这样会正确的重写提交的SHA，保证历史是健全的（sane history）。
git replace会读取--graft选项，可以编辑父提交。
--graft选项是替换一个提交有相同的内容但用不同的父提交的快捷操作。这可以方便地完成一个稍微正常一点的git replace的用例，缩短git历史。要替换master分支的最近那次提交的父，可以简单运行命令：
$ git replace master --graft [new parent]..或者要砍掉某个点之后的历史，可以忽略所有父提交让这个提交成为孤儿提交：
$ git replace master --graft再次说明，如果没有好的理由基本上不应该这么做。通常重写历史的首选方法是用明智的git rebase。
git tag开始注意tag.sort的配置问题了，这个配置在没有指定--sort选项时做为缺省排序。
如果你在tag名中使用版本号（我想99.9%你就是这么做的），这真是好消息。一旦你发布的版本号中有一段多于一个数字（比如 v10或v1.10），git缺省的字典排序就不好用了。举个例子，看看Atlassian Stash的git仓库的缺省tag排序：
src/stash $ git tag -l *.*.0
..
stash-parent-2.0.0
stash-parent-2.1.0
stash-parent-2.10.0
stash-parent-2.11.0
stash-parent-2.12.0
stash-parent-2.2.0
stash-parent-2.3.0
stash-parent-2.4.0
stash-parent-2.5.0
stash-parent-2.6.0
stash-parent-2.7.0
stash-parent-2.8.0
stash-parent-2.9.0
stash-parent-3.0.0
..有问题啊！2.10.0是2.3.0之后发的，所以缺省的tag排序不对的。从git 2.0.0开始，可以用--sort选项可以正确按数值做版本排序：
src/stash $ git tag --sort="version:refname" -l *.*.0
..
stash-parent-2.0.0
stash-parent-2.1.0
stash-parent-2.2.0
stash-parent-2.3.0
stash-parent-2.4.0
stash-parent-2.5.0
stash-parent-2.6.0
stash-parent-2.7.0
stash-parent-2.8.0
stash-parent-2.9.0
stash-parent-2.10.0
stash-parent-2.11.0
stash-parent-2.12.0
stash-parent-3.0.0
..这好多了。在git 2.1.0中，可以设定这种排序成缺省方式，运行命令：
$ git config --global tag.sort version:refname顺便说一下，上面的示例git tag命令中使用了方便的-l选项，限制了只显示符合指定模式的tag名。-l *.*.0用于只显示大版本（major）和小版本（minor）的Stash的发布。
新加了
git verify-commit命令用于检查有签名提交的GPG签名，使用方式和git verify-tag检查签名的tag类似。
如果你要用提交签名来认证提交的作者，verify-commit命令大大简化了验证签名的操作。不再需要自己写个脚本去分析git log --show-signature，只要简单把要验证签名的那些提交传给git verify-commit。有可能你没有用签名提交（在Atlassian我们没有用），因为这么做需要管理Key和开发额外麻烦的操作。对于多数项目，一般情况下签名的Tag是在方便性和安全性之间一个更好的平衡。如果你想知道为什么有项目要使用签名提交，Mike Gerwitz讲了一个在假设场景下git的恐怖故事，这个场景下签名提交是非常有用的。所以如果你在特别敏感的企业工作，可能要把它加入到工作流中。
git 2.1.0也带来了一些不错的性能提升。
引入了使用2个文件（一个基础文件和一个相应的增量文件）来表示索引的试验性格式；当要重写只有小部分工作树变化的大索引时，这样可能减少I/O消耗。
复述一下意思就是：如果你的提交有大量文件修改时，运行git add可能会更快。我本地的任何增量操作，git add已经像闪电一样快了，所以我看不出和测试的git版本之间有什么大的性能变化。有意思的是，大量文件的第一次add好像快了一点。做了个快糙猛的性能测试，我试着暂存所有在JIRA代码库从JIRA 5到JIRA 6的修改。
$ git checkout jira-v6.0
$ git reset jira-v5.0
$ time git add --allgit 2.0.3平均使用2.44秒。而git 2.1.0平均使用2.18秒 —— 节省超过10%的时间！注意，由于实验条件这是个很不准确的测试，添加14500+个文件到索引中节省了1/4秒，所以在日常git使用中不会看到大的变化。关于新索引格式可以在索引格式文档中了解更多。
缺省开启了
core.preloadindex配置项，以充分利用现代平台的多核。
不错！之前我没有开启这个功能，但升级到2.1.0后性能变化很显著。再做一个快糙猛的测试，运行git status显示之前我用的从JIRA 5到JIRA 6的暂存修改。显示暂存的14500+个文件，git 2.0.3平均使用4.94秒。而git 2.1.0平均使用3.99秒 —— 节省了多达～19%的时间。如果你使用了自定义的shell提示符，在每次提示符显示时检查工作拷贝中是否有未提交的修改，这个性能就非常有用！当索引很大时，我明显觉得bash反应快了一些。
通过重组用于跟踪已有提交的数据结构，大大优化了
git blame。
在分析出谁提交某行（搞坏项目的）代码，git blame更快了。我很高兴看到这个改进，就是说git-guilt（我写的一个小工具，用于研究如何blame提交的修改）可以有相当的性能提高，因为它重度依赖于blame到函数的输出。
又来一个快糙猛的测试，看一下算出git源码仓库从2.0.0到2.1.0的『罪行证据』（guilt transfer）要花多长时间。这个操作git-guilt要在git 2.0.0到2.1.0修改过的不同大小的文件上调用886次git blame命令。
$ git guilt v2.0.0 v2.1.0git 2.0.3平均使用72.1秒。而git 2.1.0平均使用66.7秒，提升了7.5%！如果有兴趣，你可以看看git-guilt transfer的实际代码（Karsten Blees的66 LOC行的实现，以微弱优势胜出Junio C Hamano）。
上面的性能测试都有些随意，但我们正在进行Bitbucket的git 2.1.0升级。线上会监控升级前后的功能，可以确定新版本对这些操作的性能影响，特别是blame和diff操作。过几周我会发出结果让大家知道。
在git 2.1.0中还有其它很好的内容我没有在一篇文章中涉及到，所以有兴趣可以看看完整的发布说明文档。由衷地感谢git团队又提供了一个高质量和丰富新功能的版本。如果你有兴趣了解更多有关于git的实用小建议和花边新闻，欢迎在Twitter上关注我（@kannonboy）和Atlassian开发工具（@atldevtools）。