翻译自:http://learn.jquery.com/performance/optimize-selectors/

在越来越多的浏览器支持document.querySelectorAll()之后,使得查找DOM的压力从jQuery转移到浏览器,选择器的优化,已经没有以往那么重要。然而,仍然有一些小技巧要记住。

基于ID的选择器(ID-Based Selectors)

基于ID进行查找永远是最好的方法。

// 快速:
$( "#container div.robotarm" );
 
// 更加快速:
$( "#container" ).find( "div.robotarm" );

使用.find()的方法更快,因为第一个选择器是没法脱离Sizzle选择器引擎的处理 – 而只有一个ID不包含其他类型的选择器,是直接由document.getElementById来处理的,这个是原生方法,超级快

特异性(Specificity)

把更特异的选择器放右侧,更简单的选择器放左侧。(Sizzle选择器在某些情况下,是会从右往左进行查找,这个时候,右侧的特异性,使得查找出来的结果集很小,然后再往上遍历查找符合条件的父级,效率就会很高 — 编者译)

// 没优化的:
$( "div.data .gonzalez" );
 
// 优化了的:
$( ".data td.gonzalez" );

避免过度特异性(Avoid Excessive Specificity)

$( ".data table.attendees td.gonzalez" );
 
// 更好的: 如果可以尽量去除中间的多余的条件
$( ".data td.gonzalez" );

一个轻简的DOM有助于提升选择器的性能(原文是:A “flatter” DOM also helps improve selector performance,不太好翻译),因为这样可以在查找dom的时候,减少需要检索的层级

避免全部选择器(Avoid the Universal Selector)

如果明确的或隐晦的的全部选择器(结果如果是会匹配绝大多数的DOM),这样的选择器会非常的缓慢

$( ".buttons > *" ); // 非常耗性能
$( ".buttons" ).children(); // 更好的方式
 
$( ".category :radio" ); // 隐晦的全部选择器
$( ".category *:radio" ); // 和上面的效果一样,只是更加明确
$( ".category input:radio" ); // 更好的写法

本文是翻译的https://help.github.com/articles/using-pull-requests/ 。旨在帮助大家了解GitHub上面如何给别人的仓库提交变更,英文好的同学可以查看上述网址,获取最新的内容

Pull Request可以让你通知别人,你已经推送了一个修改到GitHub的版本库。在pull request被发送之后,感兴趣的成员可以review这些代码变动,讨论可能需要的修改,甚至在必要的时候在这之后push一些commits

本指南详细描述了从发送一个pull request(假设的),使用各种代码审查工具和管理工具,到最后完成变更的过程。

协同开发模式的快速笔记

在GitHub上面有两种流行的协同开发模式:

Fork & Pull

Fork & Pull模式让任何人都可以fork(复制的意思)一个已经存在的版本库并且提交变更到他们自己fork出来的版本库上,而不需要获得源版本库的访问权限。变更必须通过项目维护者才能放入源版本库。这种模式降低了给新贡献者带来的麻烦,在开源项目非常流行,因为它使人们能够独立工作而不需要前期的协调。

共享版本库模式

共享版本库模式在小团队和组织合作的私人项目中更为普遍。每个人都有push到单一共享版本库或者用来隔离变更的顶级分支的权限。

Pull requests 在 Fork & Pull 模式 中更加有用,因为它提供了一种方法去提醒项目维护者,在他的fork里面有变更. 但是,在共享版本库模式中,他们同样有用,当人们启动代码审查或者在合并到主分支之前讨论所有变更的时候

开始之前

本指南假设您有一个GitHub的帐户 ,你已经Fork了一个的现有版本,并push了您的更改。想要获得关于Fork和推送变更的帮助,请参阅文章——Forking a Repo

启动Pull Request

在下面的例子中,codercat在Fork自Octocat的Spoon-Knife版本库中完成了一些工作,在他的Fork中push了一个commit,并希望有人来审查和合并。

进入到你希望别人Pull变更的版本库中,点击Pull Request按钮。

  1. 切换到您的分支 分支选择下拉
  2. 点击Compare & review按钮 Pull Request 按钮

Pull request可以基于任何分支或者commit发送,但是推荐是从一个顶级分支。这样,在必要的时候,一些跟随的commit可以被push,去更新这个Pull Request。

审查要提交的Pull Request

开始审查之后,你将会进入一个审查页面,在这里你可以概览到所有在你的分支和源版本库的master分支之间的变动。你可以审查在所有commit中的注释,明白哪些文件发生了变动,看到所有在你的分支中的贡献者。
Pull Request 复审页

改变分支范围和目标版本库

默认情况下,Pull Request被认为是基于父版本库的默认分支 。在这种情况下, hubot/Spoon-Knife是contoctocat/Spoon-Knife中Fork出来的。所以这次的Pull Request被假定为基于octocat/Spoon-Knife版本库的master分支。

在绝大多数情况下,默认值将是正确的,但是,如果有任何信息不正确,您可以从下拉列表中更改父版本库和分支。点击顶部的Edit按钮,可以让你换你的头和底座,以及建立各种参考点之间的差别。这里引用可以包括:

  • 添加了tag的release
  • commit的SHA值
  • 分支名称
  • Git的历史标志(如HEAD^1 )
  • 有效的时间引用(如master@{1day} )

欲了解更多信息,请查看our help article on setting up comparisons
Pull Request 选择比较的分支

理解分支范围的最简单的方法是这样的: 基础分支( base branch )是你认为变更应该应用的分支,而头部分支( head branch )是你想被人应用的分支 。

改变基础版本库会导致Pull Request发生时候的通知名单发送变动。所有对基础版本库有push权限的人都会在新的Pull Request产生的时候收到邮件,并且在他们下次登录的时候能够在他们的仪表盘查看该Pull Request。

当您更改分支范围内的任何信息,commit和文件改动的预览区域将更新以显示新的范围。

发送Pull Request

当你准备好提交您的Pull Request,点击Create pull request按钮:
Pull Request 提交

你会被带到一个讨论页面,在这里你可以输入一个标题和说明(可选)。你仍然可以看到,当Pull Request发送时哪些commit将包括在内。

当你你输入好标题和描述,针对commit范围做了必要的自定义,审查了要发送的commit和修改的文件,按Send pull request按钮。
Pull Request 发送按钮

Pull Request会被立即发送。你会被带往一个Pull Request讨论和审核的主页。

在你的Pull Request发送之后,任何push到你的分支的commit会被自动更新上去。如果您需要更多的改变,这尤其有用。

管理Pull Request

所有经由你发送或者审核的Pull Request都可以通过仪表盘的pull request 查看。给自定版本库的Pull Request,对于所有能够访问对应Pull Request页面的人来说,也是可见的。
已有的Pull Request 列表

Pull Request仪表板和版本库的Pull Request列表支持多种筛选和排序控件。用它们来把列表缩小到你感兴趣的Pull Request

审查建议的更改

当您收到一个Pull Request,要做的第一件事就是审查这些建议的更改。Pull Request被紧密地与底层的git仓库集成,所以你可以看到如果Request被接受,哪些commit会被合并:
commit 审核页

您还可以了解所有提交,查看所有文件更改的累计差异。
差异审核页

讨论Pull Request

审查了基本说明,commit,和累积差异后,负责应用更改的人可能有问题或意见。也许是编码风格不匹配项目的指引,或变更缺少单元测试,或者也许一切看起来不错,所有事情都准备就绪。设计这种讨论会面,旨在鼓励和关注这种类型的讨论。
Pull Request 讨论

这种讨论会面从Pull Request的原始标题和描述开始,然后从那里按时间顺序显示额外的活动。任何以下类型的活动,当发生的时候将会被关注:

  • 在Pull Request中的评论。
  • 在Pull Request分支中新提交的commit。
  • 在Pull Request范围内的commit中的存在的文件和行注释。

Pull Request的评论是Markdown语法兼容的,所以你可以嵌入图像,使用预格式化文本块,或者其他Markdown支持的格式。

查看长时间存留的Pull Request

当一个功能或bug修正去了几个月,但从来没有通过或者丢弃,你经常想要仔细看看,是什么阻止这个Pull Request被解决。查看旧的但仍然活跃的Pull Request,可以使得这个工作简化。

您可以从您的版本库的Pull Request页面查看和排序长时间存在的Pull Request。
排序Pull Request

长期存在的Pull Request是至少已经存在了一个多月,并已在过去一个月内有可见活动的。该过滤器将按这样一个排序方式显示那些长期运行的Pull Request:从创作到最新的活动的时间。(完)