From d70d3a0ed1bec9af5b58ba2c30f442ff09a2881e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E7=8B=82=E9=A3=99?= Date: Tue, 18 Aug 2015 10:21:20 +0800 Subject: [PATCH 1/6] Sync 06-github 1-github --- book/06-github/1-github.asc | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/book/06-github/1-github.asc b/book/06-github/1-github.asc index 3682ac7e..20927b2a 100644 --- a/book/06-github/1-github.asc +++ b/book/06-github/1-github.asc @@ -14,7 +14,8 @@ GitHub 是最大的 Git 版本库托管商，是成千上万的开发者和项 [WARNING] .接口的改变 ==== -需要注意一点，同很多活跃的网站一样，书中截取的界面会随时间而改变。希望我们试图表达的核心思想一直是不变的，但是，如果你想要这些截图的更新版本，本书的在线版本或许有更新的截图。 +需要注意一点，同很多活跃的网站一样，书中截取的界面会随时间而改变。 +希望我们试图表达的核心思想一直是不变的，但是，如果你想要这些截图的更新版本，本书的在线版本或许有更新的截图。 ==== include::sections/1-setting-up-account.asc[] From 29051f26336bfaf5ccb960054cac1f8dfdb683ea Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E7=8B=82=E9=A3=99?= Date: Tue, 18 Aug 2015 10:34:16 +0800 Subject: [PATCH 2/6] Sync 06-github 1-setting-up-account --- .../sections/1-setting-up-account.asc | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/book/06-github/sections/1-setting-up-account.asc b/book/06-github/sections/1-setting-up-account.asc index bc3ab8e2..4c6f2006 100644 --- a/book/06-github/sections/1-setting-up-account.asc +++ b/book/06-github/sections/1-setting-up-account.asc @@ -42,13 +42,15 @@ image::images/ssh-keys.png[``SSH keys''链接。] [NOTE] ==== -确保给你的 SSH 密钥起一个能够记得住的名字。你可以为每一个密钥起名字（例如，“我的笔记本电脑”或者“工作账户”等），以便以后需要吊销密钥时能够方便地区分。 +确保给你的 SSH 密钥起一个能够记得住的名字。 +你可以为每一个密钥起名字（例如，“我的笔记本电脑”或者“工作账户”等），以便以后需要吊销密钥时能够方便地区分。 ==== [[_personal_avatar]] ==== 头像 -下一步，如果愿意的话，你可以将生成的头像换成你喜欢的图片。首先，来到``Profile''标签页（在``SSH Keys''标签页上方），点击``Upload new picture''。 +下一步，如果愿意的话，你可以将生成的头像换成你喜欢的图片。 +首先，来到``Profile''标签页（在``SSH Keys''标签页上方），点击``Upload new picture''。 .``Profile''链接。 image::images/your-profile.png[``Profile''链接。] @@ -64,17 +66,24 @@ image::images/avatar-crop.png[裁剪已上传的头像。] ==== 邮件地址 -GitHub 使用用户邮件地址区分 Git 提交。如果你在自己的提交中使用了多个邮件地址，希望 GitHub 可以正确地将它们连接起来，你需要在管理页面的 Emails 部分添加你拥有的所有邮箱地址。 +GitHub 使用用户邮件地址区分 Git 提交。 +如果你在自己的提交中使用了多个邮件地址，希望 GitHub 可以正确地将它们连接起来，你需要在管理页面的 Emails 部分添加你拥有的所有邮箱地址。 [[_add_email_addresses]] .添加邮件地址 image::images/email-settings.png[添加所有邮件地址。] -在 <<_add_email_addresses>> 中我们可以看到一些不同的状态。顶部的地址是通过验证的，并且被设置为主要地址，这意味着该地址会接收到所有的通知和回复。第二个地址是通过验证的，如果愿意的话，可以将其设置为主要地址。最后一个地址是未通过验证的，这意味着你不能将其设置为主要地址。当 GitHub 发现任意版本库中的任意提交信息包含了这些地址，它就会将其链接到你的账户。 +在 <<_add_email_addresses>> 中我们可以看到一些不同的状态。 +顶部的地址是通过验证的，并且被设置为主要地址，这意味着该地址会接收到所有的通知和回复。 +第二个地址是通过验证的，如果愿意的话，可以将其设置为主要地址。 +最后一个地址是未通过验证的，这意味着你不能将其设置为主要地址。 +当 GitHub 发现任意版本库中的任意提交信息包含了这些地址，它就会将其链接到你的账户。 ==== 两步验证 -最后，为了额外的安全性，你绝对应当设置两步验证，简写为 ``2FA''。两步验证是一种用于降低因你的密码被盗而带来的账户风险的验证机制，现在已经变得越来越流行。开启两步验证，GitHub 会要求你用两种不同的验证方法，这样，即使其中一个被攻破，攻击者也不能访问你的账户。 +最后，为了额外的安全性，你绝对应当设置两步验证，简写为 ``2FA''。 +两步验证是一种用于降低因你的密码被盗而带来的账户风险的验证机制，现在已经变得越来越流行。 +开启两步验证，GitHub 会要求你用两种不同的验证方法，这样，即使其中一个被攻破，攻击者也不能访问你的账户。 你可以在 Account settings 页面的 Security 标签页中找到 Two-factor Authentication 设置。 From b1fd92a0e2552adf23c0c6a30fc036de44bb7ec8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E7=8B=82=E9=A3=99?= Date: Tue, 18 Aug 2015 10:48:56 +0800 Subject: [PATCH 3/6] Sync 06-github 2-contributing --- book/06-github/sections/2-contributing.asc | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/book/06-github/sections/2-contributing.asc b/book/06-github/sections/2-contributing.asc index dd3d3e84..6f097346 100644 --- a/book/06-github/sections/2-contributing.asc +++ b/book/06-github/sections/2-contributing.asc @@ -54,11 +54,14 @@ Tony 在找一些能在他的 Arduino 微控制器上运行的代码，他觉得 .他想要做出贡献的项目 image::images/blink-01-start.png[他想要做出贡献的项目] -但是有个问题，这个代码中的的闪烁频率太高，我们觉得 3 秒一次比 1 秒一次更好一些。所以让我们来改进这个程序，并将修改后的代码提交给这个项目。 +但是有个问题，这个代码中的的闪烁频率太高，我们觉得 3 秒一次比 1 秒一次更好一些。 +所以让我们来改进这个程序，并将修改后的代码提交给这个项目。 -首先，单击“Fork”按钮来获得这个项目的副本。我们使用的用户名是“tonychacon”，所以这个项目副本的访问地址是： `https://github.com/tonychacon/blink` 。我们将它克隆到本地，创建一个分支，修改代码，最后再将改动推送到 GitHub。 +首先，单击“Fork”按钮来获得这个项目的副本。 +我们使用的用户名是“tonychacon”，所以这个项目副本的访问地址是： `https://github.com/tonychacon/blink` 。 +我们将它克隆到本地，创建一个分支，修改代码，最后再将改动推送到 GitHub。 -[source,shell] +[source,console] ---- $ git clone https://github.com/tonychacon/blink <1> Cloning into 'blink'... @@ -84,7 +87,7 @@ void loop() { } $ git commit -a -m 'three seconds is better' <5> -[master 5ca509d] three seconds is better +[slow-blink 5ca509d] three seconds is better 1 file changed, 2 insertions(+), 2 deletions(-) $ git push origin slow-blink <6> @@ -201,7 +204,7 @@ GitHub 上的大多数的开发者会使用后一种方法，基于我们在上 在这个例子中，我们再次使用之前的“tonychacon”用户来进行示范，源作者提交了一个改动，使得合并请求和它产生了冲突。现在来看我们解决这个问题的步骤。 -[source,shell] +[source,console] ---- $ git remote add upstream https://github.com/schacon/blink <1> @@ -242,7 +245,7 @@ To https://github.com/tonychacon/blink 你完成了上面的步骤后，合并请求将会自动更新并重新检查是否能干净的合并。 -[[_pr_fail]] +[[_pr_merge_fix]] .合并请求现在可以干净地合并了 image::images/pr-02-merge-fix.png[修复了的合并请求] @@ -276,7 +279,7 @@ image::images/mentions-02-render.png[渲染后的合并请求中的引用] .在合并请求中渲染后的交叉引用 image::images/mentions-03-closed.png[合并请求关闭] -除了议题编号外，你还可以通过使用提交的 SHA 来引用提交。你必须完整的写出 40 位长的 SHA，GitHub 会在评论中自动地产生指向这个提交的链接。同样的，你可以像引用议题一样对“Fork”出的项目中的提交或者其他项目中的提交进行引用。 +除了议题编号外，你还可以通过使用提交的 SHA-1 来引用提交。你必须完整的写出 40 位长的 SHA，GitHub 会在评论中自动地产生指向这个提交的链接。同样的，你可以像引用议题一样对“Fork”出的项目中的提交或者其他项目中的提交进行引用。 ==== Markdown From 27dab7dbdd15271154d3bd7c00983213e87a6210 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E7=8B=82=E9=A3=99?= Date: Tue, 18 Aug 2015 16:00:50 +0800 Subject: [PATCH 4/6] Sync 06-github 3-maintaining --- book/06-github/sections/3-maintaining.asc | 121 +++++++++++++++------- 1 file changed, 83 insertions(+), 38 deletions(-) diff --git a/book/06-github/sections/3-maintaining.asc b/book/06-github/sections/3-maintaining.asc index adec1796..ef461a14 100644 --- a/book/06-github/sections/3-maintaining.asc +++ b/book/06-github/sections/3-maintaining.asc @@ -32,7 +32,9 @@ Git 可以通过以上两种 URL 进行抓取和推送，但是用户的访问 [NOTE] ==== -通常对于公开项目可以优先分享基于 HTTP 的 URL，因为用户克隆项目不需要有一个 GitHub 帐号。如果你分享 SSH URL，用户必须有一个帐号并且上传 SSH 密钥才能访问你的项目。 HTTP URL 与你贴到浏览器里查看项目用的地址是一样的。 +通常对于公开项目可以优先分享基于 HTTP 的 URL，因为用户克隆项目不需要有一个 GitHub 帐号。 +如果你分享 SSH URL，用户必须有一个帐号并且上传 SSH 密钥才能访问你的项目。 +HTTP URL 与你贴到浏览器里查看项目用的地址是一样的。 ==== ==== 添加合作者 @@ -58,42 +60,55 @@ image::images/collaborators.png[版本库合作者.] 现在你有一个包含一些代码的项目，可能还有几个有推送权限的合作者，下面来看当你收到合并请求时该做什么。 -合并请求可以来自仓库副本的一个分支，或者同一仓库的另一个分支。 唯一的区别是 fork 过来的通常是和你不能互相推送的人，而内部的推送通常都可以互相访问。 +合并请求可以来自仓库副本的一个分支，或者同一仓库的另一个分支。 +唯一的区别是 fork 过来的通常是和你不能互相推送的人，而内部的推送通常都可以互相访问。 -作为例子，假设你是 ``tonychacon'' ，你创建了一个名为 ``fade'' 的 Arudino 项目. +作为例子，假设你是 ``tonychacon'' ，你创建了一个名为 ``fade'' 的 Arduino 项目. [[_email_notifications]] ===== 邮件通知 -有人来修改了你的代码，给你发了一个合并请求。你会收一封关于合并请求的提醒邮件，它看起来像 <<_email_pr>>。 +有人来修改了你的代码，给你发了一个合并请求。 +你会收一封关于合并请求的提醒邮件，它看起来像 <<_email_pr>>。 [[_email_pr]] .新的合并请求的邮件通知. image::images/maint-01-email.png[合并请求的邮件通知] -关于这个邮件有几个要注意的地方。它会给你一个小的变动统计结果 -- 一个包含合并请求中改变的文件和改变了多少的列表。它还给你一个 GitHub 上进行合并请求操作的链接。还有几个可以在命令行使用的 URL。 +关于这个邮件有几个要注意的地方。 +它会给你一个小的变动统计结果 -- 一个包含合并请求中改变的文件和改变了多少的列表。 +它还给你一个 GitHub 上进行合并请求操作的链接。 +还有几个可以在命令行使用的 URL。 -如果你注意到 `git pull patch-1` 这一行，这是一种合并远程分支的简单方式，无需必须添加一个远程分支。我们很快会在 <<_checking_out_remotes>>._ 讲到它。如果你愿意，你可以创建并切换到一个主题分支，然后运行这个命令把合并请求合并进来。 +如果你注意到 `git pull patch-1` 这一行，这是一种合并远程分支的简单方式，无需必须添加一个远程分支。 +我们很快会在 <<_checking_out_remotes>>._ 讲到它。 +如果你愿意，你可以创建并切换到一个主题分支，然后运行这个命令把合并请求合并进来。 -还有一些有趣的 URL，像 `.diff` 和 `.patch` ，就像你猜的那样，它们提供 diff 和 patch 的标准版本。你可以技术性地用下面的方法合并“合并请求”： +还有一些有趣的 URL，像 `.diff` 和 `.patch` ，就像你猜的那样，它们提供 diff 和 patch 的标准版本。 +你可以技术性地用下面的方法合并“合并请求”： -[source,shell] +[source,console] ---- $ curl http://github.com/tonychacon/fade/pull/1.patch | git am ---- ===== 在合并请求上进行合作 -就像我们在 <<_github_flow>>，_ 说过的，现在你可以跟开启合并请求的人进行会话。你既可以对某些代码添加注释，也可以对整个提交添加注释或对整个合并请求添加注释，在任何地方都可以用 GitHub Flavored Markdown。 +就像我们在 <<_github_flow>>，_ 说过的，现在你可以跟开启合并请求的人进行会话。 +你既可以对某些代码添加注释，也可以对整个提交添加注释或对整个合并请求添加注释，在任何地方都可以用 GitHub Flavored Markdown。 -每次有人在合并请求上进行注释你都会收到通知邮件，通知你哪里发生改变。他们都会包含一个到改变位置的链接，你可以直接在邮件中对合并请求进行注释。 +每次有人在合并请求上进行注释你都会收到通知邮件，通知你哪里发生改变。 +他们都会包含一个到改变位置的链接，你可以直接在邮件中对合并请求进行注释。 .Responses to emails are included in the thread. image::images/maint-03-email-resp.png[邮件回复] 一旦代码符合了你的要求，你想把它合并进来，你可以把代码拉取下来在本地进行合并，也可以用我们之前提到过的 `git pull ` 语法，或者把 fork 添加为一个 remote，然后进行抓取和合并。 -对于很琐碎的合并，你也可以用 GitHub 网站上的 ``Merge'' 按钮。 它会做一个 ``non-fast-forward'' 合并，即使可以快进(fast-forward)合并也会产生一个合并提交记录。就是说无论如何，只要你点击 merge 按钮，就会产生一个合并提交记录。你可以在 <<_merge_button>>看到_，如果你点击提示链接，GitHub 会给你所有的这些信息。 +对于很琐碎的合并，你也可以用 GitHub 网站上的 ``Merge'' 按钮。 +它会做一个 ``non-fast-forward'' 合并，即使可以快进（fast-forward）合并也会产生一个合并提交记录。 +就是说无论如何，只要你点击 merge 按钮，就会产生一个合并提交记录。 +你可以在 <<_merge_button>> 看到，如果你点击提示链接，GitHub 会给你所有的这些信息。 [[_merge_button]] .合并按钮和手工合并一个合并请求的指令. @@ -104,15 +119,18 @@ image::images/maint-02-merge.png[合并按钮] [[_pr_refs]] ===== 合并请求引用 -如果你正在处理 *许多* 合并请求，不想添加一堆 remote 或者每次都要做一次拉取，这里有一个可以在 GitHub 上用的小技巧。这是有点高级的技巧，但它相当有用，我们会在 <<_refspec>>_ 有更多的细节说明。 +如果你正在处理 *许多* 合并请求，不想添加一堆 remote 或者每次都要做一次拉取，这里有一个可以在 GitHub 上用的小技巧。 +这是有点高级的技巧，但它相当有用，我们会在 <<_refspec>> 有更多的细节说明。 -实际上 GitHub 在服务器上把合并请求分支视为一种 ‘假分支’。默认情况下你克隆时不会得到它们，但它们还是隐式地存在，你可以很容易地访问到它们。 +实际上 GitHub 在服务器上把合并请求分支视为一种 “假分支”。 +默认情况下你克隆时不会得到它们，但它们还是隐式地存在，你可以很容易地访问到它们。 -为了展示这个，我们要用到一个叫做 `ls-remote` 的低级命令（通常被叫做“plumbing”，我们会在 <<_plumbing_porcelain>>_ 读到更多相关内容）。 这个命令在日常 Git 操作中基本不会用到，但在显示服务器上有哪些引用（reference）时很管用。 +为了展示这个，我们要用到一个叫做 `ls-remote` 的低级命令（通常被叫做“plumbing”，我们会在 <<_plumbing_porcelain>> 读到更多相关内容）。 +这个命令在日常 Git 操作中基本不会用到，但在显示服务器上有哪些引用（reference）时很管用。 如果在我们之前用过的 ``blink'' 版本库上使用这个命令，我们会得到一个版本库里所有的分支，标签和其它引用（reference）的列表。 -[source,shell] +[source,console] ---- $ git ls-remote https://github.com/schacon/blink 10d539600d86723087810ec636870a504f4fee4d HEAD @@ -127,13 +145,16 @@ a5a7751a33b7e86c5e9bb07b26001bb17d775d1a refs/pull/4/head 当然，如果你在你自己的版本库或其它你想检查的远程版本库中使用 `git ls-remote origin` ，它会显示相似的内容。 -如果版本库在 GitHub 上并且有打开的合并请求，你会得到一些以 `refs/pull/` 开头的引用。它们实际上是分支，但因为它们不在 `refs/heads/` 中，所以正常情况下你克隆时不会从服务器上得到它们 -- 抓取过程正常情况下会忽略它们。 +如果版本库在 GitHub 上并且有打开的合并请求，你会得到一些以 `refs/pull/` 开头的引用。 +它们实际上是分支，但因为它们不在 `refs/heads/` 中，所以正常情况下你克隆时不会从服务器上得到它们 -- 抓取过程正常情况下会忽略它们。 -每个合并请求有两个引用 - 其中以 `/head` 结尾的引用指向的提交记录与合并请求分支中的最后一个提交记录是同一个。所以如果有人在我们的版本库中开启了一个合并请求，他们的分支叫做 `bug-fix`，指向 `a5a775` 这个提交记录，那么在 *我们的* 版本库中我们没有 `bug-fix` 分支（因为那是在他们的 fork 中），但我们 *可以* 有一个 `pull//head` 指向 `a5a775`。这意味着我们可以很容易地拉取每一个合并请求分支而不用添加一堆 remote。 +每个合并请求有两个引用 - 其中以 `/head` 结尾的引用指向的提交记录与合并请求分支中的最后一个提交记录是同一个。 +所以如果有人在我们的版本库中开启了一个合并请求，他们的分支叫做 `bug-fix`，指向 `a5a775` 这个提交记录，那么在 *我们的* 版本库中我们没有 `bug-fix` 分支（因为那是在他们的 fork 中），但我们 *可以* 有一个 `pull//head` 指向 `a5a775`。 +这意味着我们可以很容易地拉取每一个合并请求分支而不用添加一堆 remote。 现在，你可以像直接抓取引用一样抓取那些分支或提交。 -[source,shell] +[source,console] ---- $ git fetch origin refs/pull/958/head From https://github.com/libgit2/libgit2 @@ -170,7 +191,7 @@ Git 高高兴兴去执行，下载构建那个引用需要的所有内容，然 最后一行告诉 Git： “所有看起来像 `refs/pull/123/head` 的引用应该在本地版本库像 `refs/remotes/origin/pr/123` 一样存储” 现在，如果你保存那个文件，执行 `git fetch`： -[source,shell] +[source,console] ---- $ git fetch # … @@ -183,7 +204,7 @@ $ git fetch 现在所有的合并请求在本地像分支一样展现，它们是只读的，当你执行抓取时它们也会更新。 这让在本地测试合并请求中的代码变得超级简单： -[source,shell] +[source,console] ---- $ git checkout pr/2 Checking out files: 100% (3769/3769)， done. @@ -192,16 +213,19 @@ Switched to a new branch 'pr/2' ---- 你的鹰眼系统会发现在 refspec 的 remote 部分的结尾有个 `head` 。 -在 GitHub 那边也有一个 `refs/pull/#/merge` 引用，它代表的是如果你在网站上按了 ``merge'' 按钮对应的提交记录。这甚至让你可以在按按钮之前就测试这个合并。 +在 GitHub 那边也有一个 `refs/pull/#/merge` 引用，它代表的是如果你在网站上按了 ``merge'' 按钮对应的提交记录。 +这甚至让你可以在按按钮之前就测试这个合并。 ===== 合并请求之上的合并请求 -你不仅可以在主分支或者说 `master` 分支上开启合并请求，实际上你可以在网络上的任何一个分支上开启合并请求。其实，你甚至可以在另一个合并请求上开启一个合并请求。 +你不仅可以在主分支或者说 `master` 分支上开启合并请求，实际上你可以在网络上的任何一个分支上开启合并请求。 +其实，你甚至可以在另一个合并请求上开启一个合并请求。 如果你看到一个合并请求在向正确的方向发展，然后你想在这个合并请求上做一些修改或者你不太确定这是个好主意，或者你没有目标分支的推送权限，你可以直接在合并请求上开启一个合并请求。 -当你开启一个合并请求时，在页面的顶端有一个框框显示你要合并到哪个分支和你从哪个分支合并过来的。如果你点击那个框框右边的 ``Edit'' 按钮，你不仅可以改变分支，还可以选择哪个 fork。 +当你开启一个合并请求时，在页面的顶端有一个框框显示你要合并到哪个分支和你从哪个分支合并过来的。 +如果你点击那个框框右边的 ``Edit'' 按钮，你不仅可以改变分支，还可以选择哪个 fork。 [[_pr_targets]] .手工修改合并请求的目标. @@ -220,9 +244,13 @@ image::images/maint-05-mentions.png[提醒] 你也可以提醒不在列表中的用户，但是通常自动补全用起更快。 -当你发布了一个带用户提醒的评论，那个用户会收到通知。这意味着把人们拉进会话中要比让他们投票有效率得多。对于 GitHub 上的合并请求，人们经常把他们团队或公司中的其它人拉来审查问题或合并请求。 +当你发布了一个带用户提醒的评论，那个用户会收到通知。 +这意味着把人们拉进会话中要比让他们投票有效率得多。 +对于 GitHub 上的合并请求，人们经常把他们团队或公司中的其它人拉来审查问题或合并请求。 -如果有人收到了合并请求或问题的提醒，他们会＂订阅＂它，后面有新的活动发生他们都会持续收到提醒。如果你是合并请求或者问题的发起方你也会被订阅上，比如你在关注一个版本库或者你评论了什么东西。如果你不想再收到提醒，在页面上有个 ``Unsubscribe'' 按钮，点一下就不会再收到更新了。 +如果有人收到了合并请求或问题的提醒，他们会＂订阅＂它，后面有新的活动发生他们都会持续收到提醒。 +如果你是合并请求或者问题的发起方你也会被订阅上，比如你在关注一个版本库或者你评论了什么东西。 +如果你不想再收到提醒，在页面上有个 ``Unsubscribe'' 按钮，点一下就不会再收到更新了。 .取消订阅一个问题或合并请求. image::images/maint-06-unsubscribe.png[取消订阅] @@ -239,23 +267,31 @@ image::images/maint-07-notifications.png[通知中心] ==== 网页通知 -网页通知只在 GitHub 上存在，你也只能在 GitHub 上查看。如果你打开了这个选项并且有一个你的通知，你会在你屏幕上方的通知图标上看到一个小蓝点。参见 <<_not_center>>。 +网页通知只在 GitHub 上存在，你也只能在 GitHub 上查看。 +如果你打开了这个选项并且有一个你的通知，你会在你屏幕上方的通知图标上看到一个小蓝点。参见 <<_not_center>>。 [[_not_center]] .通知中心. image::images/maint-08-notifications-page.png[通知中心] -如果你点击那个玩意儿，你会看到你被通知到的所有条目，按照项目分好了组。你可以点击左边栏的项目名字来过滤项目相关的通知。你可以点击通知旁边的对号图标把通知标为已读，或者点击组上面的图标把项目中 *所有的* 通知标为已读。在每个对号图标旁边都有一个静音按钮，你可以点一下，以后就不会收到它相关的通知。 +如果你点击那个玩意儿，你会看到你被通知到的所有条目，按照项目分好了组。 +你可以点击左边栏的项目名字来过滤项目相关的通知。 +你可以点击通知旁边的对号图标把通知标为已读，或者点击组上面的图标把项目中 *所有的* 通知标为已读。 +在每个对号图标旁边都有一个静音按钮，你可以点一下，以后就不会收到它相关的通知。 -所有这些工具对于处理大量通知非常有用。很多 GitHub 资深用户都关闭邮件通知，在这个页面上处理他们所有的通知。 +所有这些工具对于处理大量通知非常有用。 +很多 GitHub 资深用户都关闭邮件通知，在这个页面上处理他们所有的通知。 ==== 邮件通知 -邮件通知是你处理 GitHub 通知的另一种方式。如果你打开这个选项，每当有通知时，你会收到一封邮件。我们在 <<_email_notification>> 和 <<_email_pr>>_ 看到了一些例子。邮件也会被合适地按话题组织在一起，如果你使用一个具有会话功能的邮件客户端那会很方便。 +邮件通知是你处理 GitHub 通知的另一种方式。 +如果你打开这个选项，每当有通知时，你会收到一封邮件。 +我们在 <<_email_notification>> 和 <<_email_pr>> 看到了一些例子。 +邮件也会被合适地按话题组织在一起，如果你使用一个具有会话功能的邮件客户端那会很方便。 GitHub 在发送给你的邮件头中附带了很多元数据，这对于设置过滤器和邮件规则非常有帮助。 -举个例子，我们来看一看在 <<_email_pr>>_ 中发给 Tony 的一封真实邮件的头部，我们会看到下面这些： +举个例子，我们来看一看在 <<_email_pr>> 中发给 Tony 的一封真实邮件的头部，我们会看到下面这些： [source,mbox] ---- @@ -270,9 +306,12 @@ List-Unsubscribe: ，... X-GitHub-Recipient-Address: tchacon@example.com ---- -这里有一些有趣的东西。如果你想高亮或者转发这个项目甚至这个合并请求相关的邮件，`Message-ID` 中的信息会以 `///` 的格式展现所有的数据。例如，如果这是一个问题(issue)，那么 `` 字段就会是 ``issues'' 而不是 ``pull'' 。 +这里有一些有趣的东西。 +如果你想高亮或者转发这个项目甚至这个合并请求相关的邮件，`Message-ID` 中的信息会以 `///` 的格式展现所有的数据。 +例如，如果这是一个问题(issue)，那么 `` 字段就会是 ``issues'' 而不是 ``pull'' 。 -`List-Post` 和 `List-Unsubscribe` 字段表示如果你的邮件客户端能够处理这些，那么你可以很容易地在列表中发贴或取消对这个相关帖子的订阅。那会很有效率，就像在页面中点击静音按钮或在问题／合并请求页面点击 ``Unsubscribe'' 一样。 +`List-Post` 和 `List-Unsubscribe` 字段表示如果你的邮件客户端能够处理这些，那么你可以很容易地在列表中发贴或取消对这个相关帖子的订阅。 +那会很有效率，就像在页面中点击静音按钮或在问题／合并请求页面点击 ``Unsubscribe'' 一样。 值得注意的是，如果你同时打开了邮件和网页通知，那么当你在邮件客户端允许加载图片的情况下阅读邮件通知时，对应的网页通知也将会同时被标记为已读。 @@ -282,9 +321,12 @@ X-GitHub-Recipient-Address: tchacon@example.com ==== README -第一个就是 `README` 文件，可以是几乎任何 GitHub 可以识别的格式。例如，它可以是 `README` ，`README.md` ， `README.asciidoc` 。如果 GitHub 在你的版本库中找到 README 文件，会把它在项目的首页渲染出来。 +第一个就是 `README` 文件，可以是几乎任何 GitHub 可以识别的格式。 +例如，它可以是 `README` ，`README.md` ， `README.asciidoc` 。 +如果 GitHub 在你的版本库中找到 README 文件，会把它在项目的首页渲染出来。 -很多团队在这个文件里放版本库或项目新人需要了解的所有相关的信息。它一般包含这些内容： +很多团队在这个文件里放版本库或项目新人需要了解的所有相关的信息。 +它一般包含这些内容： * 该项目的作用 * 如何配置与安装 @@ -296,13 +338,15 @@ X-GitHub-Recipient-Address: tchacon@example.com ==== 贡献 CONTRIBUTING -另一个 GitHub 可以识别的特殊文件是 `CONTRIBUTING` 。如果你有一个任意扩展名的 `CONTRIBUTING` 文件，当有人开启一个合并请求时 GitHub 会显示 <<_contrib_file>>_ +另一个 GitHub 可以识别的特殊文件是 `CONTRIBUTING` 。 +如果你有一个任意扩展名的 `CONTRIBUTING` 文件，当有人开启一个合并请求时 GitHub 会显示 <<_contrib_file>>。 [[_contrib_file]] .开启合并请求时有 CONTRIBUTING 文件存在. image::images/maint-09-contrib.png[贡献注意事项] -这个的作用就是你可以在这里指出对于你的项目开启的合并请求你想要的／不想要的各种事情。这样别人在开启合并请求之前可以读到这些指导方针。 +这个的作用就是你可以在这里指出对于你的项目开启的合并请求你想要的／不想要的各种事情。 +这样别人在开启合并请求之前可以读到这些指导方针。 ==== 项目管理 @@ -323,9 +367,10 @@ image::images/maint-10-default-branch.png[默认分支] 如果你想把一个项目移交给 GitHub 中的另一个人或另一个组织，还是设置页面的这个 ＂options＂标签下有一个 ``Transfer ownership'' 选项可以用来干这个。 [[_transfer_project]] -.把项目移交给另一个 GitHub 用户或组织. +.把项目移交给另一个 GitHub 用户或组织。 image::images/maint-11-transfer.png[移交] 当你正准备放弃一个项目且正好有别人想要接手时，或者你的项目壮大了想把它移到一个组织里时，这就管用了。 -这么做不仅会把版本库连带它所有的观察和星标数都移到另一个地方，它还会将你的 URL 重定向到新的位置。它也重定向了来自 Git 的克隆和抓取，而不仅仅是网页端请求。 +这么做不仅会把版本库连带它所有的观察和星标数都移到另一个地方，它还会将你的 URL 重定向到新的位置。 +它也重定向了来自 Git 的克隆和抓取，而不仅仅是网页端请求。 From 1170072709bc4f350237b7415d74ffdad501018f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E7=8B=82=E9=A3=99?= Date: Tue, 18 Aug 2015 16:06:09 +0800 Subject: [PATCH 5/6] Sync 06-github 4-managing-organization --- .../sections/4-managing-organization.asc | 22 +++++++++++++------ 1 file changed, 15 insertions(+), 7 deletions(-) diff --git a/book/06-github/sections/4-managing-organization.asc b/book/06-github/sections/4-managing-organization.asc index e7236fbe..2b9ff73f 100644 --- a/book/06-github/sections/4-managing-organization.asc +++ b/book/06-github/sections/4-managing-organization.asc @@ -14,14 +14,18 @@ .``New organization''菜单项 image::images/neworg.png[``New organization''菜单项] -首先你必须提供组织的名称和组织的主要联系邮箱。然后，如果你希望的话，也可以邀请其他用户作为共同拥有人。 +首先你必须提供组织的名称和组织的主要联系邮箱。 +然后，如果你希望的话，也可以邀请其他用户作为共同拥有人。 完成以上步骤后，你就会拥有一个全新的组织。 类似于个人帐户，如果组织的所有内容都是开源的，那么你就可以免费使用这个组织。 -作为一个组织的拥有者，当你在派生一个版本库的时候，你可以选择把它派生到你的组织的命名空间内。当你新建版本库时，你可以把它存放到你的个人帐户或你拥有的组织内。同时，你也会自动地“关注”所有这些组织内的新版本库。 +作为一个组织的拥有者，当你在派生一个版本库的时候，你可以选择把它派生到你的组织的命名空间内。 +当你新建版本库时，你可以把它存放到你的个人帐户或你拥有的组织内。 +同时，你也会自动地“关注”所有这些组织内的新版本库。 -就像<<_personal_avatar>>，你可以为你的组织上传头像，使它更个性化。同时，也和个人帐户类似，组织会有一个着陆页（landing page），用于列出该组织所有的版本库，并且该页面可供所有人浏览。 +就像<<_personal_avatar>>，你可以为你的组织上传头像，使它更个性化。 +同时，也和个人帐户类似，组织会有一个着陆页（landing page），用于列出该组织所有的版本库，并且该页面可供所有人浏览。 下面我们来说一些组织和个人帐户不同的地方。 @@ -39,7 +43,10 @@ image::images/neworg.png[``New organization''菜单项] .组织页面 image::images/orgs-01-page.png[组织页面] -你可以点击<<_org_page>>右边的团队侧边栏（Teams）来管理你的团队。点击之后，你会进入一个新页面，在这里你可以添加新成员和版本库到团队中，或者管理团队的访问权限和其它设置。每个团队对于版本库可以有只读、读写和管理三种权限。你可以通过点击在<<_team_page>>内的 “Settings” 按钮更改相应权限等级。 +你可以点击 <<_org_page>> 右边的团队侧边栏（Teams）来管理你的团队。 +点击之后，你会进入一个新页面，在这里你可以添加新成员和版本库到团队中，或者管理团队的访问权限和其它设置。 +每个团队对于版本库可以有只读、读写和管理三种权限。 +你可以通过点击在 <<_team_page>> 内的 “Settings” 按钮更改相应权限等级。 [[_team_page]] .团队页面 @@ -55,10 +62,11 @@ image::images/orgs-02-teams.png[团队页面] ==== 审计日志 -组织的拥有者还可以访问组织中发生的事情的所有信息。在 'Audit Log' 标签页有整个组织的日志，你可以看到谁在世界上哪个地方做了什么事。 +组织的拥有者还可以访问组织中发生的事情的所有信息。 +在 'Audit Log' 标签页有整个组织的日志，你可以看到谁在世界上哪个地方做了什么事。 [[_audit_log]] .审计日志 -image::images/orgs-03-audit.png[审计日志] +image::images/orgs-03-audit.png[] -你也可以通过选定某一类型的事件，某个地方，某个人对日志进行过滤。 +你也可以通过选定某一类型的事件、某个地方、某个人对日志进行过滤。 From df9ffd3a271a5adb6345edf93f8d1d0926c87073 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E7=8B=82=E9=A3=99?= Date: Tue, 18 Aug 2015 16:14:24 +0800 Subject: [PATCH 6/6] Sync 06-github 5-scripting --- book/06-github/sections/5-scripting.asc | 88 ++++++++++++++++++------- 1 file changed, 63 insertions(+), 25 deletions(-) diff --git a/book/06-github/sections/5-scripting.asc b/book/06-github/sections/5-scripting.asc index 2b242d24..4936ea32 100644 --- a/book/06-github/sections/5-scripting.asc +++ b/book/06-github/sections/5-scripting.asc @@ -2,7 +2,8 @@ 所以现在我们已经介绍了 GitHub 的大部分功能与工作流程，但是任意一个小组或项目都会去自定义，因为他们想要创造或扩展想要整合的服务。 -对我们来说很幸运的是，GitHub 在许多方面都真的很方便 Hack。在本节中我们将会介绍如何使用 GitHub 钩子系统与 API 接口，使 GitHub 按照我们的设想来工作。 +对我们来说很幸运的是，GitHub 在许多方面都真的很方便 Hack。 +在本节中我们将会介绍如何使用 GitHub 钩子系统与 API 接口，使 GitHub 按照我们的设想来工作。 ==== 钩子 @@ -10,39 +11,53 @@ GitHub 仓库管理中的钩子与服务区块是 GitHub 与外部系统交互 ===== 服务 -首先我们来看一下服务。钩子与服务整合都可以在仓库的设置区块中找到，就在我们之前添加协作者与改变项目的默认分支的地方。在 ``Webhooks and Services'' 标签下你会看到与 <<_services_hooks>> 类似的内容。 +首先我们来看一下服务。 +钩子与服务整合都可以在仓库的设置区块中找到，就在我们之前添加协作者与改变项目的默认分支的地方。 +在 ``Webhooks and Services'' 标签下你会看到与 <<_services_hooks>> 类似的内容。 [[_services_hooks]] .服务与钩子配置区域 image::images/scripting-01-services.png[服务与钩子] -有许多可以选择的服务，大多数是整合到其他的商业与开源系统中。它们中的大多数是为了整合持续集成服务、BUG 与问题追踪系统、聊天室系统与文档系统。我们将会通过设置一个非常简单的例子来介绍。如果从 ``Add Service'' 选择 ``email''，会得到一个类似 <<_service_config>> 的配置屏幕。 +有许多可以选择的服务，大多数是整合到其他的商业与开源系统中。 +它们中的大多数是为了整合持续集成服务、BUG 与问题追踪系统、聊天室系统与文档系统。 +我们将会通过设置一个非常简单的例子来介绍。 +如果从 ``Add Service'' 选择 ``email''，会得到一个类似 <<_service_config>> 的配置屏幕。 [[_service_config]] .电子邮件服务配置 image::images/scripting-02-email-service.png[电子邮件服务] -在本例中，如果我们点击 ``Add service'' 按钮，每次有人推送内容到仓库时，指定的电子邮件地址都会收到一封邮件。服务可以监听许多不同类型的事件，但是大多数只监听推送事件然后使用那些数据做一些事情。 +在本例中，如果我们点击 ``Add service'' 按钮，每次有人推送内容到仓库时，指定的电子邮件地址都会收到一封邮件。 +服务可以监听许多不同类型的事件，但是大多数只监听推送事件然后使用那些数据做一些事情。 -如果有一个正在使用的系统想要整合到 GitHub，应当先检查这里看有没有已有的可用的服务整合。例如，如果正使用 Jenkins 来测试你的代码库，当每次有人推送到你的仓库时你可以启用 Jenkins 内置的整合启动测试运行。 +如果有一个正在使用的系统想要整合到 GitHub，应当先检查这里看有没有已有的可用的服务整合。 +例如，如果正使用 Jenkins 来测试你的代码库，当每次有人推送到你的仓库时你可以启用 Jenkins 内置的整合启动测试运行。 ===== 钩子 -如果需要做一些更具体的事，或者想要整合一个不在这个列表中的服务或站点，可以转而使用更通用的钩子系统。GitHub 仓库钩子是非常简单的。指定一个 URL 然后 GitHub 在任一期望的事件发生时就会发送一个 HTTP 请求到那个 URL 。 +如果需要做一些更具体的事，或者想要整合一个不在这个列表中的服务或站点，可以转而使用更通用的钩子系统。 +GitHub 仓库钩子是非常简单的。 +指定一个 URL 然后 GitHub 在任一期望的事件发生时就会发送一个 HTTP 请求到那个 URL 。 通常做这件事的方式是可以设置一个小的 web 服务来监听 GitHub 钩子请求然后使用收到的数据做一些事情。 -为了启用一个钩子，点击 <<_services_hooks>> 中的 ``Add webhook'' 按钮。这会将你引导至一个类似 <<_web_hook>> 的页面。 +为了启用一个钩子，点击 <<_services_hooks>> 中的 ``Add webhook'' 按钮。 +这会将你引导至一个类似 <<_web_hook>> 的页面。 [[_web_hook]] .Web 钩子配置 image::images/scripting-03-webhook.png[Web 钩子配置] -Web 钩子的设置非常简单。大多数情况下只需要输入一个 URL 与一个密钥然后点击 ``Add webhook''。有几个选项可以指定在哪个事件时想要 GitHub 发送请求 -- 默认的行为是只有当某人推送新代码到仓库的任一分支时的 `push` 事件获得一个请求。 +Web 钩子的设置非常简单。 +大多数情况下只需要输入一个 URL 与一个密钥然后点击 ``Add webhook''。 +有几个选项可以指定在哪个事件时想要 GitHub 发送请求 -- 默认的行为是只有当某人推送新代码到仓库的任一分支时的 `push` 事件获得一个请求。 -让我们看一个设置处理 web 钩子的 web 服务的小例子。我们将会使用 Ruby web 框架 Sinatra，因为它相当简洁，应该能够轻松地看到我们正在做什么。 +让我们看一个设置处理 web 钩子的 web 服务的小例子。 +我们将会使用 Ruby web 框架 Sinatra，因为它相当简洁，应该能够轻松地看到我们正在做什么。 -假设我们想要在某个特定的人推送到我们的项目的特定分支并修改一个特定文件时得到一封邮件。我们可以相当容易地使用类似下面的代码做到： +假设我们想要在某个特定的人推送到我们的项目的特定分支并修改一个特定文件时得到一封邮件。 +我们可以相当容易地使用类似下面的代码做到： [source,ruby] ---- @@ -78,9 +93,13 @@ post '/payload' do end ---- -这里我们拿到一个 GitHub 传送给我们的 JSON 请求然后查找推送者，他们推送到了什么分支以及推送的所有提交都改动了哪些文件。然后我们检查它是否与我们的条件区配，如果匹配则发送一封邮件。 +这里我们拿到一个 GitHub 传送给我们的 JSON 请求然后查找推送者，他们推送到了什么分支以及推送的所有提交都改动了哪些文件。 +然后我们检查它是否与我们的条件区配，如果匹配则发送一封邮件。 -为了开发与测试类似这样的东西，在设置钩子的地方有一个漂亮的开发者控制台。可以看到 GitHub 为那个 webhook 的最后几次请求。对每一个钩子，当它发送后都可以深入挖掘，检测它是否是成功的与请求及回应的消息头与消息体。这使得测试与调试钩子非常容易。 +为了开发与测试类似这样的东西，在设置钩子的地方有一个漂亮的开发者控制台。 +可以看到 GitHub 为那个 webhook 的最后几次请求。 +对每一个钩子，当它发送后都可以深入挖掘，检测它是否是成功的与请求及回应的消息头与消息体。 +这使得测试与调试钩子非常容易。 [[_web_hook_debug]] .Web 钩子调试信息 @@ -95,11 +114,15 @@ image::images/scripting-04-webhook-debug.png[Web 钩子调试信息] (((GitHub, API))) 服务与钩子给你提供了一种方式来接收关于在仓库中发生的事件的推送通知，但是如何获取相关事件的详情呢？如何自动化一些诸如添加协作者或给问题加标签的事情呢？ -这是 GitHub API 派上用场的地方。在自动化流行的趋势下，GitHub 提供了大量的 API 接口，可以进行几乎任何能在网站上进行的操作。在本节中我们将会学习如何授权与连接到 API，如何通过 API 在一个问题上评论与如何修改一个 Pull Request 的状态。 +这是 GitHub API 派上用场的地方。 +在自动化流行的趋势下，GitHub 提供了大量的 API 接口，可以进行几乎任何能在网站上进行的操作。 +在本节中我们将会学习如何授权与连接到 API，如何通过 API 在一个问题上评论与如何修改一个 Pull Request 的状态。 ==== 基本用途 -可以做的最基本的事情是向一个不需要授权的接口上发送一个简单的 GET 请求。该接口可能是一个用户或开源项目的只读信息。例如，如果我们想要知道更多关于名为 ``schacon'' 的用户信息，我们可以运行类似下面的东西： +可以做的最基本的事情是向一个不需要授权的接口上发送一个简单的 GET 请求。 +该接口可能是一个用户或开源项目的只读信息。 +例如，如果我们想要知道更多关于名为 ``schacon'' 的用户信息，我们可以运行类似下面的东西： [source,javascript] ---- @@ -117,7 +140,8 @@ $ curl https://api.github.com/users/schacon } ---- -有大量类似这样的接口来获得关于组织、项目、问题、提交的信息 -- 差不多就是你能在 GitHub 上看到的所有东西。甚至可以使用 API 来渲染任意 Markdown 或寻找一个 `.gitignore` 模板。 +有大量类似这样的接口来获得关于组织、项目、问题、提交的信息 -- 差不多就是你能在 GitHub 上看到的所有东西。 +甚至可以使用 API 来渲染任意 Markdown 或寻找一个 `.gitignore` 模板。 [source,javascript] ---- @@ -145,20 +169,28 @@ hs_err_pid* 然而，如果想要在网站上进行一个操作，如在 Issue 或 Pull Request 上评论，或者想要查看私有内容或与其交互，你需要授权。 -这里提供了几种授权方式。你可以使用仅需用户名与密码的基本授权，但是通常更好的主意是使用一个个人访问令牌。 +这里提供了几种授权方式。 +你可以使用仅需用户名与密码的基本授权，但是通常更好的主意是使用一个个人访问令牌。 可以从设置页的 ``Applications'' 标签生成访问令牌。 [[_access_token]] .从设置页的 ``Applications'' 标签生成访问令牌。 image::images/scripting-05-access-token.png[访问令牌] -它会询问这个令牌的作用域与一个描述。确保使用一个好的描述信息，这样当脚本或应用不再使用时你会很放心地移除。 +它会询问这个令牌的作用域与一个描述。 +确保使用一个好的描述信息，这样当脚本或应用不再使用时你会很放心地移除。 -GitHub 只会显示令牌一次，所以记得一定要拷贝它。现在可以在脚本中使用它代替使用用户名写密码来授权。这很漂亮，因为可以限制想要做的范围并且令牌是可废除的。 +GitHub 只会显示令牌一次，所以记得一定要拷贝它。 +现在可以在脚本中使用它代替使用用户名写密码来授权。 +这很漂亮，因为可以限制想要做的范围并且令牌是可废除的。 -这也会有一个提高频率上限的附加优点。如果没有授权的话，你会被限制在一小时最多发起 60 次请求。如果授权则可以一小时最多发起 5000 次请求。 +这也会有一个提高频率上限的附加优点。 +如果没有授权的话，你会被限制在一小时最多发起 60 次请求。 +如果授权则可以一小时最多发起 5000 次请求。 -所以让我们利用它来对我们的其中一个问题进行评论。想要对一个特定问题 Issue #6 留下一条评论。必须使用刚刚生成的令牌作为 Authorization 头信息，发送一个到 `repos///issues//comments` 的 HTTP POST 请求。 +所以让我们利用它来对我们的其中一个问题进行评论。 +想要对一个特定问题 Issue #6 留下一条评论。 +必须使用刚刚生成的令牌作为 Authorization 头信息，发送一个到 `repos///issues//comments` 的 HTTP POST 请求。 [source,javascript] ---- @@ -192,9 +224,11 @@ image::images/scripting-06-comment.png[API 评论] ==== 修改 Pull Request 的状态 -如果使用 Pull Requests 的话我们将要看到的最后一个例子会很有用。每一个提交可以有一个或多个与它关联的状态，有 API 来添加与查询状态。 +如果使用 Pull Requests 的话我们将要看到的最后一个例子会很有用。 +每一个提交可以有一个或多个与它关联的状态，有 API 来添加与查询状态。 -大多数持续集成与测试服务通过测试推送的代码后使用这个 API 来回应，然后报告提交是否通过了全部测试。你也可以使用该接口来检查提交信息是否经过合适的格式化、提交者是否遵循了所有你的贡献准则、提交是否经过有效的签名 -- 种种这类事情。 +大多数持续集成与测试服务通过测试推送的代码后使用这个 API 来回应，然后报告提交是否通过了全部测试。 +你也可以使用该接口来检查提交信息是否经过合适的格式化、提交者是否遵循了所有你的贡献准则、提交是否经过有效的签名 -- 种种这类事情。 假设在仓库中设置了一个 web 钩子访问一个用来检查提交信息中的 `Signed-off-by` 字符串的小的 web 服务。 @@ -241,9 +275,11 @@ post '/payload' do end ---- -希望这相当容易做。在这个 web 钩子处理器中我们浏览刚刚推送上来的每一个提交，在提交信息中查找字符串 'Signed-off-by' 并且最终使用 HTTP 向 `/repos///statuses/` API 接口发送一个带有状态的 POST 请求。 +希望这相当容易做。 +在这个 web 钩子处理器中我们浏览刚刚推送上来的每一个提交，在提交信息中查找字符串 'Signed-off-by' 并且最终使用 HTTP 向 `/repos///statuses/` API 接口发送一个带有状态的 POST 请求。 -在本例中可以发送一个状态（'success', 'failure', 'error'）、一个发生了什么的描述信息、一个用户可以了解更多信息的目标 URL 与一个 ``context'' 以防一个单独的提交有多个状态。例如，一个测试服务可以提供一个状态与一个类似这样的验证服务也可能提供一个状态 -- ``context'' 字段是用来区别它们的。 +在本例中可以发送一个状态（'success', 'failure', 'error'）、一个发生了什么的描述信息、一个用户可以了解更多信息的目标 URL 与一个 ``context'' 以防一个单独的提交有多个状态。 +例如，一个测试服务可以提供一个状态与一个类似这样的验证服务也可能提供一个状态 -- ``context'' 字段是用来区别它们的。 如果某人在 GitHub 中打开了一个新的 Pull Request 并且这个钩子已经设置，会看到类似 <<_commit_status>> 的信息。 @@ -251,7 +287,9 @@ end .通过 API 的提交状态 image::images/scripting-07-status.png[提交状态] -现在可以看到一个小的绿色对勾标记在提交信息中有 ``Signed-off-by'' 的提交旁边，红色的对勾标记在作者忘记签名的提交旁边。也可以看到 Pull Request 显示在那个分支上的最后提交的状态，如果失败的话会警告你。如果对测试结果使用这个 API 那么就不会不小心合并某些未通过测试的最新提交。 +现在可以看到一个小的绿色对勾标记在提交信息中有 ``Signed-off-by'' 的提交旁边，红色的对勾标记在作者忘记签名的提交旁边。 +也可以看到 Pull Request 显示在那个分支上的最后提交的状态，如果失败的话会警告你。 +如果对测试结果使用这个 API 那么就不会不小心合并某些未通过测试的最新提交。 ==== Octokit