From 1323da08ca87eb98e3080d04038e6a073258b421 Mon Sep 17 00:00:00 2001 From: Jerry Lee Date: Mon, 8 Sep 2014 14:58:03 +0800 Subject: [PATCH] update format for jobbole publish --- whats-new-git-2-1/README.md | 124 ++++++++++-------------------------- 1 file changed, 32 insertions(+), 92 deletions(-) diff --git a/whats-new-git-2-1/README.md b/whats-new-git-2-1/README.md index d5f93e8..f9da548 100644 --- a/whats-new-git-2-1/README.md +++ b/whats-new-git-2-1/README.md @@ -5,34 +5,26 @@ 在`git` `2.0.0`发布2个半月后，作为小版本更新迎来了`2.1.0`，带来了一大波令人兴奋的新特性。 -完整的发布说明文档可以在[这里](https://raw.githubusercontent.com/git/git/master/Documentation/RelNotes/2.1.0.txt)查看， -但如果你不怎么接触`git`社区，会觉得发布说明文档说明有些太简明了。 -这篇文章是我对这次发布在`Atlassian`使用中令我们兴奋的方面所做的评注。 +完整的发布说明文档可以在[这里](https://raw.githubusercontent.com/git/git/master/Documentation/RelNotes/2.1.0.txt)查看，但如果你不怎么接触`git`社区，会觉得发布说明文档说明有些太简明了。这篇文章是我对这次发布在`Atlassian`使用中令我们兴奋的方面所做的评注。 更好的分页程序缺省设置 ------------------ -本文引文都是直接摘自发布说明文档，会在其中加上自己的评注。 +本文引文都是直接摘自发布说明文档，其中会加上自己的评注。 -> 从很早期的`Git`开始，调用`less`分页程序用的`LESS`环境变量设置的缺省值是`FRSX`。 -`S`选项（截断长文本行而不是折行）从缺省值中删除了，因为对不同的人有不同的说法，这个选项或多或少是个人口味问题。 -相比，其它的选项作为缺省设置是合理的（如，`R`选项非常合理，因为很多不同的输出都是彩色的，而`FX`也是合理的，因为输出常常短于一页。） +> 从很早期的`Git`开始，调用`less`分页程序用的`LESS`环境变量设置的缺省值是`FRSX`。`S`选项（截断长文本行而不是折行）从缺省值中删除了，因为对不同的人有不同的说法，这个选项或多或少是个人口味问题。相比，其它的选项作为缺省设置是合理的（如，`R`选项非常合理，因为很多不同的输出都是彩色的，而`FX`也是合理的，因为输出常常短于一页。） -如果你还没有覆盖过`git`分页程序的缺省值，这个变化意味着`git`命令的分页输出会在终端宽度的地方折行而不是截断行。 -下面是`git` `2.1.0`（折行，左图）和`git` `2.0.3`（截断，右图）显示的例子： +如果你还没有覆盖过`git`分页程序的缺省值，这个变化意味着`git`命令的分页输出会在终端宽度的地方折行而不是截断行。下面是`git` `2.1.0`（折行，左图）和`git` `2.0.3`（截断，右图）显示的例子： ![](git210leftvsgit200right-600x293.png) -这个只会影响你日志的输出，如果你用的是一个窄的终端，或者在提交消息中有长行。 -一般`git`推荐提交日志信息的[宽度不要超过72字符](http://stackoverflow.com/questions/2290016/git-commit-messages-50-72-formatting)， -但如果觉得折行很烦，可以通过恢复原来的行为来禁用： +这个只会影响你日志的输出，如果你用的是一个窄的终端，或者在提交消息中有长行。一般`git`推荐提交日志信息的[宽度不要超过72字符](http://stackoverflow.com/questions/2290016/git-commit-messages-50-72-formatting)，但如果觉得折行很烦，可以通过恢复原来的行为来禁用： ```bash $ git config core.pager "less -S" ``` -当然，分页程序也会用于其它的输出，比如`git blame`，这种情况下由于作者名的长度和代码风格，可以能会有很长的行。 -`2.1.0`的发布说明文档也指出了可以只在`blame`的分页程序中启用`-S`选项： +当然，分页程序也会用于其它的输出，比如`git blame`，这种情况下由于作者名的长度和代码风格，可以能会有很长的行。`2.1.0`的发布说明文档也指出了可以只在`blame`的分页程序中启用`-S`选项： ```bash $ git config pager.blame "less -S" @@ -49,62 +41,47 @@ $ git config pager.blame "less -S" > 更新了`Bash`的补全脚本（在`contrib/`目录），能更好地处理定义了复杂命令序列的别名。 -这个**超酷**！我是一个自定义`git`别名的大粉丝。能够在复杂的别名上用上`git`的`Bash`自动补全， -让这些别名在命令行上使用起来更强大和方便。举个例子，我定义一个可以从日志中`grep`出`JIRA`风格的`issue`主键（如`STASH-123`）的别名： +这个**超酷**！我是一个自定义`git`别名的大粉丝。能够在复杂的别名上用上`git`的`Bash`自动补全，让这些别名在命令行上使用起来更强大和方便。举个例子，我定义一个可以从日志中`grep`出`JIRA`风格的`issue`主键（如`STASH-123`）的别名： ```bash 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 log`命令，这样可以限制提交的范围用于返回`issue`主键。比如，`git issues -n 1`只会显示我的分支最近一次提交所关联的`issue`主键。在`2.1.0`中，`git`的`Bash`补全让我可以像`git log`命令一样去补全`git`的`issue`别名。 -在`git` `2.0.3`下，键入`git issues m`会退化成缺省的`Bash`补全行为，列出当前目录下`m`开头的文件。 -在`git` `2.1.0`下，正确地补全成`master`，就和`git log`命令下补全动作一样。 -通过在别名加上空命令前缀`:`，可以用于提示`Bash`补全行为。 -如果要补全的不是别名中的第一个命令，这个很有用。举个例子： +在`git` `2.0.3`下，键入`git issues m`会退化成缺省的`Bash`补全行为，列出当前目录下`m`开头的文件。在`git` `2.1.0`下，正确地补全成`master`，就和`git log`命令下补全动作一样。通过在别名加上空命令前缀`:`，可以用于提示`Bash`补全行为。如果要补全的不是别名中的第一个命令，这个很有用。举个例子： ```bash issues = "!f() { echo 'Printing issue keys'; git log --oneline $@ | egrep -o [A-Z]+-[0-9]+ | sort | uniq; }; f" ``` -这个别名不能正常补全，因为`git`不能把`echo`命令识别为补全目标。 -但如果加上前缀成`: git log;`，补全就正确了： +这个别名不能正常补全，因为`git`不能把`echo`命令识别为补全目标。但如果加上前缀成`: git log;`，补全就正确了： ```bash 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`。 +如果你喜欢编写复杂的别名脚本，这是个可用性的巨大改进！请记住，补全功能的脚本在`contrib/`目录下，不是`git`核心的一部分，所以如果你要使用这个功能，不要忘了更新`Bash profile`指向新版本的`contrib/completion/git-completion.bash`。 `git commit`命令使用`approxidate` ------------------ > `git commit ‐‐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`酷炫日期处理的博文](http://alexpeattie.com/blog/working-with-dates-in-git/)。 +当严格的`parse_date()`函数不能解析给的日期字符串时，`git`提交的`--date`选项现在会回退到`git`酷炫的（也有些古怪的）`approxidate`（大概日期）解析器。`approxidate`可以处理显而易见的值，像`--date=now`，也允许一些略复杂格式，像`--date="midnight the 12th of october, anno domini 1979"`或是`--date=teatime`。如果你想了解更多，Alex Peattie有一篇优秀的[关于`git`酷炫日期处理的博文](http://alexpeattie.com/blog/working-with-dates-in-git/)。 更好的路径显示方式`grep.fullname` ------------------ -> `git grep`会读取`grep.fullname`配置变量，强制`‐‐full-name`成为缺省。 -这可能会让以脚本方式使用的用户出错，这些用户不期望这样的新行为。 +> `git grep`会读取`grep.fullname`配置变量，强制`‐‐full-name`成为缺省。这可能会让以脚本方式使用的用户出错，这些用户不期望这样的新行为。 省得你去翻`git-grep`的`man`，下面是`--full-name`选项的文档说明： -> --full-name +> `--full-name` > > 当从子目录运行时，命令输出的路径通常相对于当前目录。这个选项强制输出的路径是相对项目的顶级目录。 -非常贴心！这个缺省行为非常符合我的工作方式，我常常会运行`git grep`找出一个文件的路径， -拷贝粘贴到一个`XML`文件中（这样的做法可能出卖了我是个`Java`开发 :grin:）。 -如果你也觉得有用，只要简单运行： +非常贴心！这个缺省行为非常符合我的工作方式，我常常会运行`git grep`找出一个文件的路径，拷贝粘贴到一个`XML`文件中（这样的做法可能出卖了我是个`Java`开发 :grin:）。如果你也觉得有用，只要简单运行： ```bash $ git config --global grep.fullname true @@ -112,24 +89,18 @@ $ git config --global grep.fullname true 在你的配置文件开启这个选项。 -`--global`选项把配置应用到`$HOME/.gitconfig`文件中，这样配置值就会成为我系统上所有`git`仓库的缺省行为。 -如果有必要，你可以也只在仓库级别覆盖配置值。 +`--global`选项把配置应用到`$HOME/.gitconfig`文件中，这样配置值就会成为我系统上所有`git`仓库的缺省行为。如果有必要，你可以也只在仓库级别覆盖配置值。 更聪明的`git replace` ------------------ 停一会儿！先看看`git replace`能做什么？ -简单地说，`git replace`重写`git`仓库中的某个对象并且不保持对应树或是提交的`SHA`不变。 -如果你是第一次听到`git replace`并且知道`git`的数据模型，会觉得这样的做法听起来很逆天！ -我就是这么觉得。我有另一篇正在写的博文讨论什么时候和为什么要使用这样的功能。 -如果现在你想了解更多，看[这篇文章](http://git-scm.com/blog/2010/03/17/replace.html)比看`man`手册好得多， -手册中只有很少且有些牵强的用例说明。 +简单地说，`git replace`重写`git`仓库中的某个对象并且不保持对应树或是提交的`SHA`不变。如果你是第一次听到`git replace`并且知道`git`的数据模型，会觉得这样的做法听起来很逆天！我就是这么觉得。我有另一篇正在写的博文讨论什么时候和为什么要使用这样的功能。如果现在你想了解更多，看[这篇文章](http://git-scm.com/blog/2010/03/17/replace.html)比看`man`手册好得多，手册中只有很少且有些牵强的用例说明。 > `git replace`会读取`--edit`选项，可以编辑一个已有的对象再做替换。 -`--edit`选项会`dump`一个对象的内容到一个临时文件，启动你喜欢的编辑器，这样就可以方便地拷贝和替换这个对象。 -要替换`master`分支的最近那次提交，可以简单运行命令： +`--edit`选项会`dump`一个对象的内容到一个临时文件，启动你喜欢的编辑器，这样就可以方便地拷贝和替换这个对象。要替换`master`分支的最近那次提交，可以简单运行命令： ```bash $ git replace --edit master @@ -145,9 +116,7 @@ $ git replace --edit master:jira-components/pom.xml > `git replace`会读取`--graft`选项，可以编辑父提交。 -`--graft`选项是替换一个提交有相同的内容但用不同的父提交的快捷操作。 -这可以方便地完成一个稍微正常一点的`git replace`的用例，[缩短`git`历史](http://git-scm.com/blog/2010/03/17/replace.html)。 -要替换`master`分支的最近那次提交的父，可以简单运行命令： +`--graft`选项是替换一个提交有相同的内容但用不同的父提交的快捷操作。这可以方便地完成一个稍微正常一点的`git replace`的用例，[缩短`git`历史](http://git-scm.com/blog/2010/03/17/replace.html)。要替换`master`分支的最近那次提交的父，可以简单运行命令： ```bash $ git replace master --graft [new parent].. @@ -166,9 +135,7 @@ $ git replace master --graft > `git tag`开始注意`tag.sort`的配置问题了，这个配置在没有指定`--sort`选项时做为缺省排序。 -如果你在`tag`名中使用版本号（我想99.9%你就是这么做的），这真是好消息。 -一旦你发布的版本号中有一段多于一个数字（比如 `v10`或`v1.10`），`git`缺省的字典排序就不好用了。 -举个例子，看看`Atlassian Stash`的`git`仓库的缺省`tag`排序： +如果你在`tag`名中使用版本号（我想99.9%你就是这么做的），这真是好消息。一旦你发布的版本号中有一段多于一个数字（比如 `v10`或`v1.10`），`git`缺省的字典排序就不好用了。举个例子，看看`Atlassian Stash`的`git`仓库的缺省`tag`排序： ```bash src/stash $ git tag -l *.*.0 @@ -190,8 +157,7 @@ stash-parent-3.0.0 .. ``` -有问题啊！`2.10.0`是`2.3.0`之后发的，所以缺省的`tag`排序不对的。 -从`git` `2.0.0`开始，可以用`--sort`选项可以正确按数值做版本排序： +有问题啊！`2.10.0`是`2.3.0`之后发的，所以缺省的`tag`排序不对的。从`git` `2.0.0`开始，可以用`--sort`选项可以正确按数值做版本排序： ```bash src/stash $ git tag --sort="version:refname" -l *.*.0 @@ -219,33 +185,23 @@ stash-parent-3.0.0 $ git config --global tag.sort version:refname ``` -顺便说一下，上面的示例`git tag`命令中使用了方便的`-l`选项，限制了只显示符合指定模式的`tag`名。 -`-l *.*.0`用于只显示大版本（`major`）和小版本（`minor`）的`Stash`的发布。 +顺便说一下，上面的示例`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`的恐怖故事](http://mikegerwitz.com/papers/git-horror-story)，这个场景下签名提交是非常有用的。 -所以如果你在特别敏感的企业工作，可能要把它加入到工作流中。 +如果你要用提交签名来认证提交的作者，`verify-commit`命令大大简化了验证签名的操作。不再需要自己写个脚本去分析`git log --show-signature`，只要简单把要验证签名的那些提交传给`git verify-commit`。有可能你没有用签名提交（在`Atlassian`我们没有用），因为这么做需要管理`Key`和开发额外麻烦的操作。对于多数项目，一般情况下签名的`Tag`是在方便性和安全性之间一个更好的平衡。如果你想知道为什么有项目要使用签名提交，Mike Gerwitz讲了一个在假设场景下[`git`的恐怖故事](http://mikegerwitz.com/papers/git-horror-story)，这个场景下签名提交是非常有用的。所以如果你在特别敏感的企业工作，可能要把它加入到工作流中。 更多的性能加速 ------------------ `git` `2.1.0`也带来了一些不错的性能提升。 -> 引入了使用2个文件（一个基础文件和一个相应的增量文件）来表示索引的试验性格式； -当要重写只有小部分工作树变化的大索引时，这样可能减少I/O消耗。 +> 引入了使用2个文件（一个基础文件和一个相应的增量文件）来表示索引的试验性格式；当要重写只有小部分工作树变化的大索引时，这样可能减少I/O消耗。 -复述一下意思就是：如果你的提交有大量文件修改时，运行`git add`可能会更快。 -我本地的任何增量操作，`git add`已经像闪电一样快了，所以我看不出和测试的`git`版本之间有什么大的性能变化。 -有意思的是，大量文件的第一次`add`好像快了一点。 -做了个快糙猛的性能测试，我试着暂存所有在`JIRA`代码库从`JIRA 5`到`JIRA 6`的修改。 +复述一下意思就是：如果你的提交有大量文件修改时，运行`git add`可能会更快。我本地的任何增量操作，`git add`已经像闪电一样快了，所以我看不出和测试的`git`版本之间有什么大的性能变化。有意思的是，大量文件的第一次`add`好像快了一点。做了个快糙猛的性能测试，我试着暂存所有在`JIRA`代码库从`JIRA 5`到`JIRA 6`的修改。 ```bash $ git checkout jira-v6.0 @@ -253,43 +209,27 @@ $ git reset jira-v5.0 $ time git add --all ``` -`git` `2.0.3`平均使用2.44秒。而`git` `2.1.0`平均使用2.18秒 —— -节省超过10%的时间！注意，由于实验条件这是个很不准确的测试，添加14500+个文件到索引中节省了1/4秒，所以在日常`git`使用中不会看到大的变化。 -关于新索引格式可以在[索引格式文档](https://code.google.com/p/git-core/source/browse/Documentation/technical/index-format.txt)中了解更多。 +`git` `2.0.3`平均使用2.44秒。而`git` `2.1.0`平均使用2.18秒 —— 节省超过10%的时间！注意，由于实验条件这是个很不准确的测试，添加14500+个文件到索引中节省了1/4秒，所以在日常`git`使用中不会看到大的变化。关于新索引格式可以在[索引格式文档](https://code.google.com/p/git-core/source/browse/Documentation/technical/index-format.txt)中了解更多。 > 缺省开启了`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`反应快了一些。 +不错！之前我没有开启这个功能，但升级到`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`提交的修改](https://blogs.atlassian.com/2014/07/git-guilt-blame-code-review/)） -可以有相当的性能提高，因为它重度依赖于`blame`到函数的输出。 +在分析出谁提交某行（搞坏项目的）代码，`git blame`更快了。我很高兴看到这个改进，就是说`git-guilt`（我写的一个小工具，用于研究[如何`blame`提交的修改](https://blogs.atlassian.com/2014/07/git-guilt-blame-code-review/)）可以有相当的性能提高，因为它重度依赖于`blame`到函数的输出。 -又来一个快糙猛的测试，看一下算出`git`源码仓库从`2.0.0`到`2.1.0`的『罪行证据』（`guilt transfer`）要花多长时间。 -这个操作`git-guilt`要在`git` `2.0.0`到`2.1.0`修改过的不同大小的文件上调用886次`git blame`命令。 +又来一个快糙猛的测试，看一下算出`git`源码仓库从`2.0.0`到`2.1.0`的『罪行证据』（`guilt transfer`）要花多长时间。这个操作`git-guilt`要在`git` `2.0.0`到`2.1.0`修改过的不同大小的文件上调用886次`git blame`命令。 ```bash $ git guilt v2.0.0 v2.1.0 ``` -`git` `2.0.3`平均使用72.1秒。而`git` `2.1.0`平均使用66.7秒， -提升了7.5%！如果有兴趣，你可以看看[`git-guilt transfer`](http://pastie.org/9492426)的实际代码 -（Karsten Blees的66 LOC行的实现，以微弱优势胜出Junio C Hamano）。 +`git` `2.0.3`平均使用72.1秒。而`git` `2.1.0`平均使用66.7秒，提升了7.5%！如果有兴趣，你可以看看[`git-guilt transfer`](http://pastie.org/9492426)的实际代码（Karsten Blees的66 LOC行的实现，以微弱优势胜出Junio C Hamano）。 -上面的性能测试都有些随意，但我们正在进行`Bitbucket`的`git` `2.1.0`升级。 -线上会监控升级前后的功能，可以确定新版本对这些操作的性能影响，特别是`blame`和`diff`操作。 -过几周我会发出结果让大家知道。 +上面的性能测试都有些随意，但我们正在进行`Bitbucket`的`git` `2.1.0`升级。线上会监控升级前后的功能，可以确定新版本对这些操作的性能影响，特别是`blame`和`diff`操作。过几周我会发出结果让大家知道。 等等，还有还有！ ------------------ -在`git` `2.1.0`中还有其它很好的内容我没有在一篇文章中涉及到，所以有兴趣可以看看[完整的发布说明文档](https://raw.githubusercontent.com/git/git/master/Documentation/RelNotes/2.1.0.txt)。 -由衷地感谢`git`团队又提供了一个高质量和丰富新功能的版本。 -如果你有兴趣了解更多有关于`git`的实用小建议和花边新闻， -欢迎在Twitter上关注我（[@kannonboy](https://twitter.com/kannonboy)）和Atlassian开发工具（[@atldevtools](https://twitter.com/atldevtools)）。 +在`git` `2.1.0`中还有其它很好的内容我没有在一篇文章中涉及到，所以有兴趣可以看看[完整的发布说明文档](https://raw.githubusercontent.com/git/git/master/Documentation/RelNotes/2.1.0.txt)。由衷地感谢`git`团队又提供了一个高质量和丰富新功能的版本。如果你有兴趣了解更多有关于`git`的实用小建议和花边新闻，欢迎在Twitter上关注我（[@kannonboy](https://twitter.com/kannonboy)）和Atlassian开发工具（[@atldevtools](https://twitter.com/atldevtools)）。