Github-精要第二版-全-
Github 精要第二版（全）
原文：
annas-archive.org/md5/1b3c4270e73ae134f62259dab718aa7f译者：飞龙
前言
GitHub 是领先的代码托管平台，几乎所有开源项目都在其上托管其代码。与 Git 结合使用，它提供了高效的开发工作流，并是开发者首选的工具。
从创建仓库的基础开始，您将学习如何管理问题追踪器，让您的项目可以在此讨论。继续我们的旅程，我们将探讨如何使用 Wiki 并编写丰富的文档来伴随您的项目。组织和团队管理将是下一个重点，然后是拉取请求，这使得 GitHub 如此著名。
接下来，我们将专注于创建托管在 GitHub 上的简单网页，最后，我们将探索可配置给用户和仓库的设置。
本书适合谁
本书适合有经验或初学者的开发者，具有 Git 的基本知识。如果您曾想了解 Twitter、Google 甚至 GitHub 等大型项目如何协作编码，那么这本书适合您。
本书内容
第一章，仓库概述及问题追踪使用，解释了 GitHub 提供的一些主要特性及其用途。问题追踪是项目开发者和/或用户之间沟通的核心。可以将其看作是每个仓库专用的记事本，用于跟踪错误、报告、功能请求以及所有能够记录的其他内容。GitHub 还实施了许多其他功能，如标签和里程碑，用于更好地可视化和分类所有问题。
第二章，使用 Wiki 和管理代码版本，帮助您学习如何创建、编辑和维护 Wiki，为您的文档提供一个家。您还将学习如何从现有分支或标签创建新的发布，并附带可选的发布说明。通过这种方式，最终用户可以了解与任何先前版本的变更。
第三章，管理组织和团队，教您如何创建和管理您拥有的组织。您还将学习如何创建团队，向其添加用户，并根据需要分配不同的访问级别。
第四章，使用 GitHub 工作流进行协作，重点介绍如何使用分支和拉取请求，这是 GitHub 最强大的功能。
第五章，GitHub Pages 和 Web 分析，详细介绍了如何围绕您的项目构建网页，这些网页专门托管在 GitHub 上。您可以使用 HTML、CSS 和 JavaScript 创建静态网页。
第六章，探索用户和仓库设置，探讨了用户和仓库最常见和最基本的设置。作为用户，你可以在用户设置页面上设置很多信息，例如将多个电子邮件与帐户关联，添加多个 SSH 密钥，或设置双重身份验证。类似地，仓库的一些功能可以通过其设置页面进行设置。例如，你可以启用或禁用 wiki 页面，并授予公众写权限，或者完全禁用问题跟踪器。
充分利用本书
本书需要 Git（任何版本均可）和一个 GitHub 帐户。
下载示例代码文件
你可以从你的帐户在 www.packtpub.com 下载本书的示例代码文件。如果你在其他地方购买了本书，你可以访问 www.packtpub.com/support 并注册，将文件直接通过电子邮件发送给你。
你可以按照以下步骤下载代码文件：
-
登录或注册到 www.packtpub.com。
-
选择“支持”标签。
-
点击“代码下载与勘误表”。
-
在搜索框中输入书名，并按照屏幕上的说明进行操作。
下载文件后，请确保使用最新版本的以下工具解压或提取文件夹：
-
WinRAR/7-Zip for Windows
-
Zipeg/iZip/UnRarX for Mac
-
7-Zip/PeaZip for Linux
本书的代码包也托管在 GitHub 上，网址为 github.com/PacktPublishing/GitHub-Essentials-Second-Edition。如果代码有更新，将会在现有的 GitHub 仓库中进行更新。
我们还提供了来自我们丰富书籍和视频目录的其他代码包，网址为 github.com/PacktPublishing/。快去看看吧！
下载彩色图像
我们还提供了一份 PDF 文件，其中包含本书中使用的截图/图表的彩色图像。你可以在此下载：www.packtpub.com/sites/default/files/downloads/GitHubEssentialsSecondEdition_ColorImages.pdf。
使用的约定
本书中使用了若干文本约定。
CodeInText：表示文本中的代码词、数据库表名、文件夹名称、文件名、文件扩展名、路径名、虚拟 URL、用户输入以及 Twitter 用户名。示例：“将下载的 WebStorm-10*.dmg 磁盘映像文件挂载为系统中的另一个磁盘。”
代码块的格式如下：
echo "\n## Description\n\nGitHub for dummies" >> README.md
git add README.md
git commit -m "Add second level header to README file"
git push origin add_description
当我们希望引起你对某一代码块中特定部分的注意时，相关行或项会用粗体标出：
echo "\n## Description\n\nGitHub for dummies" >> README.md
git add README.md
git commit -m "Add second level header to README file"
git push origin add_description
任何命令行输入或输出都将按以下方式显示：
mkdir -p ~/github-essentials
cd $_
粗体：表示新术语、重要词汇或屏幕上看到的词汇。例如，菜单或对话框中的词汇会以这种方式显示在文本中。以下是一个示例：“从管理面板中选择系统信息。”
警告或重要说明如下所示。
提示和技巧如下所示。
联系我们
我们始终欢迎读者的反馈。
一般反馈：请通过电子邮件feedback@packtpub.com与我们联系，并在邮件主题中注明书名。如果您对本书的任何方面有疑问，请通过questions@packtpub.com与我们联系。
勘误表：尽管我们已经尽力确保内容的准确性，但错误仍然可能发生。如果您在本书中发现任何错误，欢迎您向我们报告。请访问 www.packtpub.com/submit-errata，选择您的书籍，点击勘误表提交链接，并填写相关信息。
盗版：如果您在互联网上遇到任何我们作品的非法复制品，恳请您提供该位置地址或网站名称。请通过copyright@packtpub.com与我们联系，并附上材料的链接。
如果您有兴趣成为作者：如果您在某个领域拥有专业知识，并且有意愿写书或为书籍做贡献，请访问 authors.packtpub.com。
评价
请留下评价。在您阅读并使用本书后，为什么不在您购买本书的网站上留下评价呢？潜在读者可以看到您的无偏见意见，帮助他们做出购买决策，我们也能了解您对我们产品的看法，而我们的作者则可以看到您对其书籍的反馈。谢谢！
欲了解更多关于 Packt 的信息，请访问 packtpub.com。
第一章：简要介绍仓库概述和问题追踪器的使用
几乎所有在 GitHub 上发生的事情都与仓库有关。仓库就像一个包含您项目所有文件的文件夹。
GitHub 上仓库的登陆页面展示了一个人的本地 Git 仓库的内容。除了文件的树状结构外，GitHub 还提供了一些附加功能，将最著名和最常用的 Git 命令带到您的浏览器中。其他功能包括仓库的分支、提交和标签。
除了这些功能，GitHub 还为每个仓库提供了问题追踪器。这是讨论发生的地方，跟踪和报告错误，提出功能请求，以及几乎所有与项目相关的内容都会在这里讨论。
GitHub 还实现了许多其他功能，位于问题追踪器之上，例如标签和里程碑，这些功能提供了更好的可视化和问题的分类。我们将广泛地探索所有这些功能，所以即使您还不熟悉这些术语，也不用担心。以下是我们将在本章中介绍的内容：
-
探索仓库的主页
-
学习如何使用强大的问题追踪器功能
项目 和 仓库 这两个术语，尽管不完全相同，但在本书中会被视为同义词并交替使用。
探索仓库的主页
仓库的主页是访问项目时大多数人停留的地方。在本节中，您将学习如何创建一个仓库，接着我们将探索 GitHub 的广泛功能，这些功能将 Git 的命令行带入您的浏览器。
创建一个新仓库
假设您已经通过 github.com/join 注册了 GitHub，我们现在将探索仓库的主页，并学习如何创建一个新的仓库来托管您的代码。
导航到页面的右上角，点击您用户名旁的小十字，选择“新建仓库”，如以下截图所示：
然后，您将进入一个页面，您需要提供一些关于新仓库的信息：
在“仓库名称”下填写一个名称，该名称最终将形成您的仓库注册的 URL。这是您创建仓库时需要执行的最基本操作。
GitHub 上的所有仓库都具有以下 URL 结构：https://github.com/<username>/<repository_name>
提供仓库描述是可选的，但建议您这样做。这样，其他用户可以一目了然地了解您的项目内容。
接下来的设置是选择您的仓库是公开还是私有。通常，您可以选择公开，除非您不希望所有人看到您的文件。但是，私有仓库是需要付费的。
GitHub 提供的下一个功能是创建一个包含 README 文件的仓库。README 文件通常包含关于你托管在仓库中的项目的全面信息，如安装指南、构建和使用说明，以及如何贡献的指南。你可以随时添加 README 文件，所以暂时可以不选这个选项。
另一个不错的功能是可以在创建时选择并包含一个 gitignore 文件。你可以从github.com/github/gitignore提供的一系列有用的.gitignore模板中选择。
最终，你在 GitHub 上托管的代码将能够被第三方派生和重用。如果你是从一个全新的仓库开始，可以选择在创建时包含一个许可证。这是可选的，你也可以稍后手动添加许可证文件。
让我们点击“创建仓库”按钮并完成仓库的创建。到目前为止，它看起来是这样的：
你可以看到 GitHub 提供了关于下一步该做什么的有用信息。如果你本地计算机上已经有一个现有的 Git 仓库，你可以将其代码推送到 GitHub，或者按照屏幕上的指示从头开始创建。
由于我们稍后将从命令行工作，强烈建议你生成一个 SSH 密钥并将其与 GitHub 账户关联。请参阅help.github.com/articles/generating-ssh-keys/上的指南。此外，请确保正确配置你的 Git 用户名和电子邮件设置。更多信息，请参见help.github.com/articles/setting-your-username-in-git/和help.github.com/articles/setting-your-email-in-git/。
恭喜你创建了第一个仓库！
下一个目标是浏览仓库的主页。当你访问 https://github.com/<username>/<repository> 时，你应该能看到以下内容：
-
<username>：这是你注册时使用的用户名（在右上角可以找到）。 -
<repository>：这是你在前面步骤中输入的仓库名称
提交页面与 git log 命令的比较
GitHub 有一个很不错的 Web 用户界面，许多常见的 git 命令都可以在其中输入。
让我们首先创建一个 README.md 文件并将其推送到 GitHub，以便浏览提交页面：
- 创建一个目录来存放你的代码并
cd进入该目录：
mkdir -p ~/github-essentials
cd $_
- 然后，按照 GitHub 提供的指示创建一个新项目：
echo "# github-essentials-v2" >> README.md
git init
git add README.md
git commit -m "first commit"
git remote add origin git@github.com:<username>/<repository>.git
git push -u origin master
注意，我使用的是 Git 协议（github.com/），它在底层使用 SSH，这样我就不需要每次输入用户名和密码（请参阅前面关于如何实现这一点的说明）。
目录名（在我们的例子中是github-essentials）可能与创建时输入的仓库名称完全不同。必须与你通过git remote add设置的远程 URL 匹配 GitHub 提供的仓库 URL。
每次你添加更多提交时，它们的总数也会出现在项目的主页上。在之前的步骤中，我们进行了第一次提交，因此提交计数为 1，所以截图中显示了 1 个提交选项：
点击前面截图中显示的 1 个提交链接，进入提交页面。
在这里，你可以浏览提交列表（目前我们只有一个提交），并可视化git log的输出。让我们对比这两个提交。在本地仓库中输入git log；输出应该类似于以下内容：
commit b77a7ff22653ca74b10e99efdbc45f6f54ef10f4
Author: Achilleas Pipinellis <mail@example.com>
Date: Sun Apr 15 23:26:32 2018 +0200
first commit
现在，前往 GitHub 的提交页面。在这里，你可以看到以一种友好的界面呈现的相同信息：
我们可以看到提交信息、提交的日期和时间，以及该提交的 SHA。注意，SHA 被简化为 40 个字符中的前 7 个。点击 SHA 或提交信息会显示该提交所做的更改。我们来尝试一下，并对比 GitHub 显示的git show <commit>命令的结果：
commit b77a7ff22653ca74b10e99efdbc45f6f54ef10f4
Author: Achilleas Pipinellis <mail@example.com>
Date: Sun Apr 15 23:26:32 2018 +0200
first commit
diff --git a/README.md b/README.md
new file mode 100644
index 0000000..54a8290
--- /dev/null
+++ b/README.md
@@ -0,0 +1 @@
+# github-essentials-v2
前面代码的结果如下面截图所示：
提交信息以大号粗体字显示，因为它传达了一个重要信息。在它下面，是包含该提交的分支（目前只有 master 分支）。
你可以看到提交的 SHA、作者名以及日期，显示在蓝色区域的下方。GitHub 还会告诉你，在上次提交中，有多少文件发生了变化，并且做了多少次添加或删除。
最后，我们可以看到以绿色标示的新增内容。如果你删除了某些内容，它将以粉红色显示，稍后我们会看到这一点。
分支页面和与 git branch 命令的对比
我们来创建一个名为add_description的分支，并切换到该分支：
git checkout -b add_description
接下来，编辑README.md，添加一些文本，进行新的提交，并将其推送到 GitHub：
echo "\n## Description\n\nGitHub for dummies" >> README.md
git add README.md
git commit -m "Add second level header to README file"
git push origin add_description
现在，让我们从 master 分支创建一个名为new_feature的第二个分支，并将其推送到 GitHub：
git checkout master
git branch new_feature
git push origin new_feature
现在是时候切换到 GitHub，查看所有这些信息是如何呈现的。
在主仓库页面，你现在可以看到有三个分支。点击分支链接以获取更多信息。
概览页面正如其标题所示，是你在其旁边看到的其他标签的概览。它告诉我们默认分支是什么，你从你的账户推送了哪些分支（与“你的”标签相同），以及过去三个月中最活跃的分支（按日期排序，与“活跃”标签相同）。而“过时”标签代表的是那些超过三个月未更新的分支。
你可以在项目的设置中更改默认分支，它会出现在项目首页。这在第六章《探索用户和仓库设置》中有详细讲解。
你可能会注意到，尽管我们在推送 add_description 后推送了 new_feature 分支，但它的更新时间似乎出现在 add_description 之前。这是正常现象，因为 new_feature 的提交日期与我们的 master 分支相同，而该日期早于 add_description 分支。
现在，如果你仔细观察显示分支的标签，你会看到，在小字体中，显示了各个分支相对于默认分支的提交数——在我们的例子中，默认分支是 master。
在分支页面，你可以删除所有分支，除了你设置为默认的分支。我们来试着删除 new_feature 分支。点击红色的垃圾桶图标，看看会发生什么。GitHub 会给你恢复最近删除分支的机会：
如果你刷新页面或浏览删除分支的页面其他部分，Restore 按钮会消失。
新建拉取请求按钮将在后续章节中讲解。
Raw、Blame 和 History 按钮
现在我们已经了解了 GitHub 如何看待分支，让我们来看看 GitHub 提供的其他 Git 功能。
Raw、Blame 和 History 按钮会出现在查看仓库的单个文件时。例如，我们可以通过点击来查看 README.md 文件：
Raw 按钮顾名思义，会以原始形式打开文件，这意味着任何 HTML 格式都会消失。当你想下载单个文件时，这特别有用。你会注意到，互联网上的许多指南都会告诉你使用命令行工具（例如 wget 或 curl）下载文件时，使用的就是这种原始文件格式。如果你曾尝试从 GitHub 下载文件，而得到的只是一个 HTML 文件，请记得使用 raw 格式。
Blame 按钮利用了 Git 的 blame 功能。基本上，对于文件的每一行，Git 会告诉你是谁修改了该行以及修改的时间。如果你想了解更多信息，可以访问 git-scm.com/docs/git-blame。
为了正确查看该功能的使用，我不会使用我们之前创建的 README.md 文件，因为其中没有太多信息可以展示 GitHub 如何使用这个 Git 功能。相反，我将使用另一个仓库中的文件，这个文件有更多的提交。例如，可以查看 github.com/gitlabhq/gitlabhq/blame/master/app/models/ability.rb，如下所示：
下载示例代码
你可以从你在www.packtpub.com的账户中下载所有已购买的 Packt 书籍的示例代码文件。如果你在其他地方购买了本书，可以访问www.packtpub.com/support，注册后将文件直接发送到你的邮箱。
相比在终端中调用git blame，你可以感受到 GitHub 功能的优越性。每一行代码都有注释，你可以看到哪一行文件在什么提交下被修改，谁修改的。还有一个很棒的小功能——热度：较旧的提交会显示为棕色线条，而较新的则显示为黄色。
最后，History 按钮不过就是git log在特定文件中的作用。
Watch、Star 和 Fork 按钮
你可能已经注意到，位于仓库页面右上角的三个按钮。这些按钮在每个公共仓库中都会出现，不仅仅是你自己的仓库。
Watch 按钮管理仓库中订阅的级别。每当你关注的仓库发生操作时，GitHub 会通过邮件通知你，同时将这些操作列出在通知区域（github.com/notifications），你可以稍后将它们标记为已读，如下图所示：
订阅有三个级别，从“永不通知”到“大哥”不等。你可以选择仅在你明确参与对话或某人提到你时才收到通知（不关注）。这是你可以得到的中级通知，也是创建新仓库时的默认行为。下一个级别是始终收到通知，例如每当开始对话，或创建新问题，或某人在代码行中留下评论，或某人提到你时（关注）。最后，第三个选项是永不接收通知（忽略）。
你可以通过在用户名之前加上at符号（@）来提到某人。这是 GitHub 理解你需要某人注意的特殊方式。开始输入用户名时，GitHub 会智能地自动完成它。
Star 按钮是向仓库及其创作者表示感谢的一种方式。它表示项目的受欢迎程度。每当你给一个仓库加星，它会被添加到你的星标仓库列表中。你可以在github.com/stars查看你所有的星标仓库。
在 GitHub 上，你可以在github.com/search?utf8=%E2%9C%93&q=stars%3A%3E1&type=Repositories找到按星标数排序的项目列表。
你可以通过点击 Star/Unstar 按钮旁边的数字，查看谁给仓库加过星。对于我刚创建的仓库，你可以看到我就是唯一的“星标者”：
Fork 按钮及其作用是 GitHub 能够脱颖而出的原因。正如我们在本书后面会看到的，它的主要用途是当你想要为某个项目做贡献时。当你 Fork 一个仓库时，它会复制到你自己的命名空间中，这样你就完全拥有了该副本；因此，你可以修改任何你想要的内容。试试看吧，前往 github.com/axilleas/github-essentials，点击 Fork 按钮。稍等片刻（根据仓库大小不同），你将被重定向到你完全拥有的该仓库副本。
修改描述和网址
之前，我们学习了如何为我们的项目添加描述。这在创建新仓库时是可选的，如果你选择跳过创建，我们来看一下现在如何添加它。
前往主仓库页面，你会看到两个空白表单。在描述字段中，写下你项目的描述性注释；在网站字段中，填写你的项目可能拥有的网址。这也可以是你的 GitHub 仓库网址。如下所示：
点击保存后，你会立即看到更改。
学习如何利用问题追踪器的强大功能
GitHub 提供了一个功能全面的问题追踪器，紧密关联到每个仓库。
它的主要用途是作为一个错误追踪器，因为报告和讨论错误在你项目的成长中起着至关重要的作用。它也可以用来提交功能请求，作为博客或项目的讨论板，甚至可以作为修理房屋的记事本！有关这方面的更多内容，请参阅以下链接：
创建新问题
访问 https://github.com/<用户名>/<仓库>/issues，可以查看所有问题的活动概览。如果没有人曾在你的项目中打开过问题，你将看到一个空白页面，GitHub 会提示你打开一个新问题。我们现在来做这个操作。点击那个写着“新建问题”的大绿色按钮。
当你只提供最少的标题时，可能会创建一个问题。仔细查看以下截图，提交新问题按钮被禁用，无法点击。标题应尽可能详细地描述你在创建问题时想要传达的内容。
在下方的“写”标签下，你可以提供详细信息，并且基本上开始与所有希望参与的人进行讨论（前提是仓库是公开的）。这就是为什么 GitHub 聪明地建议你“留下评论”。
除了写文字外，你还可以通过简单的拖放，或者通过文件夹导航选择图片，来附加图片。以下是这个仓库的第一个问题的样子：
“写作”标签旁边是“预览”标签。为了理解它的作用，你首先需要了解 Markdown。
简而言之，Markdown 是一个文本转 HTML 的工具，允许你编写包含结构信息的文本，并将其自动转换为有效的 HTML。由 John Gruber 编写，并被 GitHub（以及其他许多平台）采纳，Markdown 因其易用性而成为最著名的文本转 HTML 工具。
你可以在guides.github.com/features/mastering-markdown/的指南中阅读关于 GitHub 如何扩展 Markdown 功能的所有信息。
回到我们的新问题。顾名思义，预览（Preview）会显示提交问题时的结果。它会根据“写作”标签中的常规文本，将其格式化为有意义的文本，URL 会被正确格式化，图片会显示，表情符号也会展示等。
正如我们在本书后面会看到的，GitHub 风格的 Markdown 包含了许多小功能，充分利用了问题跟踪器的使用。这些只是冰山一角。
感觉准备好提交了吗？点击页面底部的“提交新问题”。恭喜你创建了第一个问题！结果将如下所示：
每个创建的问题都会分配一个唯一的编号，之后我们可以在其他问题中引用它。在我们的例子中，由于这是第一个问题，它被分配了编号#1。标题区域提供了一些有用的信息。你可以看到该问题标记为“开放状态”，问题创建者的用户名，创建时间以及评论数量。
如果你后来发现自己犯了错误，不要慌张——你可以随时编辑已创建的问题。编辑按钮允许你编辑标题，铅笔图标用于编辑描述。通过点击“关闭问题”按钮来关闭问题。
如果你希望在关闭问题时同时发表评论，例如说明问题为何关闭，可以在输入评论时，按钮会从“关闭问题”变为“关闭并评论”。
将问题分配给用户
一个仓库可以有多个协作者。协作者是指具有推送权限的人，在我们的例子中，协作者还可以编辑和关闭问题。
用户分配在流量大的仓库中效果很好，特别是当有一个团队负责处理错误修复、功能增强等任务时。
有两种方法可以将问题分配给某人。首先，正如你在前面的图片中看到的，每个问题中都有一个受分配人（Assignee）部分，如下图所示：
在这个特定阶段，只有一个协作者——我——所以列表中只会显示我的名字。好的，我们已经学会了如何从问题内部分配一个问题给协作者，但如果你有几十个问题要分配给某人怎么办？逐个分配会有点繁琐且费时。你会高兴地知道，你可以批量分配问题给某人。
为此，让我们再创建两个问题。前往问题页面，勾选你想要分配的多个问题框，并选择一个受理人，如下截图所示：
选择受理人后，问题将立即更新为新的信息。你可以看到，受理人的头像出现在分配给他们的每个问题上：
你可以选择最多 10 个受理人来分配给一个问题。
标签
如果你使用过 WordPress，标签类似于标签（Tags）。不过，这与 Git 标签不同。接下来我们将探讨如何创建标签，并有效使用它们来轻松分类一批问题。
为什么标签对用户体验（UX）是一个宝贵的资产
标签提供了一种简便的方式来根据描述性标题对问题进行分类，比如“bug”，“功能”，以及你想使用的其他任何词汇。它们是有颜色的，并且在问题跟踪器中或每个问题内部都可以看到。
通过标签，你可以导航到问题跟踪器，过滤掉冗余的信息，只显示你感兴趣的问题。让我们看看它是如何工作的。
创建新标签名称并设置不同的颜色
前往问题跟踪器，并通过点击“标签”导航到标签页面。正如你所看到的，GitHub 已经设置了一些预定义的标签，可以直接使用。新标签和现有标签的名称、颜色和描述都可以完全自定义。
创建新标签非常简单，只需点击“新建标签”按钮，填写名称，选择颜色，并可选择性地输入描述。事实上，系统会自动选择一个随机颜色，所以唯一的前提是输入名称。我已经创建了一个新的黄色标签，命名为 needs testing，如以下截图所示：
点击“创建标签”按钮后，标签将被创建并显示在列表中。回到问题页面——让我们进入第一个问题，并给它添加刚刚创建的标签。点击齿轮图标，菜单将会出现。开始输入以缩小搜索范围。现在我们只有 9 个标签，但假设有 42 个以上，你将不得不一直滚动，直到找到你想要的标签。
如你所料，你可以在一个问题中选择多个标签。选择完标签后，只需点击标签窗口外的任意位置即可保存操作。你会立刻看到变更：
请注意，GitHub 会记录对问题所做的任何更改。这样，你就能知道是谁进行了某个特定操作，以及操作发生的时间。没有什么能逃得过 GitHub 的眼睛！尝试删除“enhancement”标签，看看会发生什么。
和受指派者一样，你也可以批量为问题分配标签。我们可以通过进入主问题页面，选择一些问题，然后选择“bug”标签来尝试这一操作：
问题跟踪器将被更新，现在你可以查看分配给每个问题的标签概况：
使用标签来分组问题
假设你有 100 个打开的问题，其中许多被标记为“bug”。如果通过某种方式，这些问题仅出现在问题主页面上，那不是很酷吗？嗯，猜猜看——当你点击“bug”标签时，GitHub 基本上会进行查询，结果是只有 bug 类型的问题会显示出来。分组功能来救场！
返回标签页面，你会看到你可以概览每个标签下分配的所有问题数量。
里程碑
里程碑，类似于标签，主要用于将问题分组，但目的是不同的。考虑一个里程碑，它就像一个特殊的标签，具有标题、描述和可选的截止日期。
为什么里程碑在代码版本控制中起着重要作用
众所周知，应用程序是以版本发布的。从你笔记本电脑的 BIOS 到你用来浏览互联网的网页浏览器，所有应用程序都使用版本控制。
许多公司，甚至是社区驱动的开源项目，通常都会有一张路线图，规定何时将新产品发布给公众。
GitHub 将此功能与问题跟踪器进行了整合。让我们深入了解，学习如何创建一个新里程碑，将一些问题分配给它，并使用概览查看哪些问题已经解决或未解决。
创建一个新的里程碑
在问题跟踪器的主页面上，点击“里程碑”链接，位于“标签”链接旁边。如果还没有创建任何里程碑，你将看到两个按钮可以创建一个里程碑。通常，“新建里程碑”按钮将是主要使用的按钮。
现在，让我们创建第一个里程碑。唯一的要求是标题；描述和截止日期是可选的。但是，为了看看效果如何，我们来填入所有信息：
点击“创建里程碑”，它将出现在“里程碑”页面上，显示我们之前输入的所有信息：
在左侧，你可以看到名称、截止日期、描述以及里程碑上次更新的时间。右侧则展示了完成百分比以及开放和关闭问题的数量。当然，你也可以编辑、关闭或完全删除它。
将问题添加到里程碑
现在我们至少有一个里程碑了，让我们将它分配给一个问题。
同样，有两种方法可以为问题添加里程碑。就像分配人和标签一样，你可以在每个问题内进行操作，或者在问题主页面上批量添加。这里，我将尝试第二种方法；你可以自己尝试第一种方法：
选择里程碑后，页面将刷新，问题将被添加到选定的里程碑中。如果你仔细观察，你会看到一个小图标和旁边的里程碑名称：
使用里程碑查看哪些问题已解决或尚未解决
当处理成百上千个问题、bug 报告和改进建议时，能够一目了然地查看哪些已经解决，哪些尚未解决是非常方便的。
让我们再为里程碑添加一个问题，然后立即关闭它，就像我们在 创建问题 部分中学到的那样。在里程碑的上下文中，这将被视为已完成。前往里程碑页面。你会看到条形图现在已填充一半（50%）：
提示与技巧
README 文件对于你的项目至关重要，因为它们在首页提供有用的信息。让我们简要探索一下这个功能，然后再学习键盘快捷键。
了解 README 文件
README 文件用于提供关于你项目的信息。其内容会自动显示在你仓库的首页，因此提供一个 README 文件始终是个好主意。
GitHub 会检查 README 文件是否带有扩展名；如果扩展名被支持进行渲染，它会根据其实现自动进行格式化。
例如，README 文件可以有一个 .md 扩展名，代表 markdown；一个 .rst 扩展名，代表重构文本；以及一个 .adoc 扩展名，代表 AsciiDoc。
如果扩展名不被支持，GitHub 会将其视为普通文本文件，并且不会进行任何格式化。
有关支持的标记语言列表，请访问 github.com/github/markup#markups。
使用键盘快捷键轻松导航
GitHub 有一个很好的功能，支持键盘快捷键。你可以通过在任何页面上按下 ? 键查看支持哪些快捷键。一个对话框将弹出，显示该页面支持的所有快捷键。要查看所有快捷键，请点击“显示所有”链接。
总结
在本章中，你学习了如何创建第一个仓库，并浏览了其主页面。你还学习了如何有效使用问题追踪器来追踪项目的 bug、功能请求等。此外，你还学会了如何使用标签和里程碑来更好地分组问题。
在下一章中，我们将学习维基（wikis），以及 GitHub 关于代码发布的功能。
第二章：使用维基和管理代码版本控制
在上一章中，我们探索了存储库的主页，并介绍了其问题跟踪器的基础知识。
GitHub 还提供了一个类似维基风格的地方来添加项目的文档。您可以创建任意数量的页面，并公开访问以便每个人都可以编辑。
此外，当您是产品的创建者并有依赖于它的用户时，您希望它尽可能稳定。版本控制有助于实现这一目标。GitHub 提供了适合发布代码版本的正确工具，实际上这些只是时间快照。每当您认为项目准备好进入世界时，无论是修复了错误还是添加了新功能，您都可以使用发布功能并向世界提供版本化的 tarball 文件。
完成本章后，您将学会如何通过为文档提供一个家园来创建、编辑和维护维基。
您还将学会如何从现有分支或标签创建新版本发布，并提供可选的发布说明。这样，最终用户可以了解与任何先前版本的变化。
我们将覆盖以下内容：
-
使用维基：
-
为何维基是记录项目的好地方
-
创建新的维基页面
-
删除页面
-
Markdown 简介
-
如何为维基添加侧边栏和页脚
-
观察维基页面的提交历史并根据需要恢复到之前的状态
-
-
管理代码版本控制：
-
创建发布
-
编辑发布
-
从命令行推送标签
-
标记为预发布
-
制作发布的草稿
-
上传您自己的文件
-
-
小贴士：
-
通过 Atom feed 订阅新发布内容
-
本地编辑维基
-
使用维基
当您首次创建新存储库时，与此项目关联的维基也会随之创建。默认情况下启用，每个人都可以添加新内容或修改现有页面。如果您想更改此行为，可以参考第六章，探索用户和存储库设置，其中详细说明了如何完成此操作。
为何维基是记录项目的好地方
文档工作绝不可小觑。引用一句名言，伴随伟大的项目而来的是优秀的文档。
尽管有许多工具可以转换标记文件，比如将 Markdown 转换为 HTML，但您可能不希望使用外部页面来托管您的文档。进入 GitHub 维基。
创建新的维基页面
选择维基标签（带有书籍图标的标签），前往维基。由于我们的维基目前没有内容，页面并不存在。在这种情况下，GitHub 会提示您创建第一个页面。请继续点击绿色按钮。
每次添加新页面到维基时，过程都是相同的。页面顶部是标题。这是唯一强制填写的字段，用于创建维基页面，同时也用于形成您将访问页面的 URL：
当第一个 Wiki 页面创建时，GitHub 默认使用 Home 作为标题。即使你选择了其他名称，Home 页面仍会自动创建，并作为 Wiki 的首页。Home 的作用类似于仓库中的 README，它无法被删除。
在标题区域下方，有两个标签。当“写作”标签处于活动状态时，你可以开始在下方的空白区域进行写作。如果选择使用标记语言写作，预览标签将渲染文本，并向你展示保存页面后的展示效果。
在标题下方，有一个不错的工具栏，包含了最常见的操作，如标题、粗体文本、斜体和列表。在编写本书时，GitHub 支持九种标记语言供选择。从编辑模式下拉列表中选择一种，文本将根据所选语言进行渲染。对于你从菜单中选择的每种语言，都会有一个小帮助页面，列出最常用的操作。点击问号图标即可查看帮助区域。
最后，当你准备保存页面时，可以提供一个简短的消息，描述所做的修改内容。可以将其看作是一个 Git 提交消息。稍后，当我们浏览页面的历史记录时，编辑消息将派上用场。
当你准备好时，点击保存页面按钮，页面将如下所示：
删除页面
除了 Home 页面外，其他页面都可以删除。为了删除页面，进入你想删除的页面并点击右上角的编辑按钮。如你所见，删除页面并不一定意味着它被永久清除。继续阅读，了解如何撤销操作。
一个基于 Markdown 的 Wiki —— Markdown 简介
虽然 GitHub 支持多种标记语言，但我们将探索 Markdown，因为它是最知名的一种。
让我们创建另一个页面，名为Installation，并添加以下内容：
我使用了几个 Markdown 元素，点击预览将显示保存后页面的渲染效果。点击保存页面按钮后，新创建的 Installation 页面将如下所示：
有一些值得提到的元素是链接。有两种类型的链接：外部链接和内部链接。外部链接通过给出完整的 URL，包括 FQDN 来编写，而内部链接只需使用页面名称即可。
你可以创建外部链接，并通过将其用<>包围来显示实际的 URL，例如 <https://duckduckgo.com>，你还可以包含一些随机文本，如 [git clone](https://git-scm.com/docs/git-clone)。在方括号内，你可以添加任何文本，后跟实际链接，括号内是链接的内容。注意不要在第二个方括号和第一个括号之间留空格。
内部链接在你想链接到 wiki 的另一页时非常有用。假设你有 42 页，当你想引用另一个页面时，每次都需要输入完整的网址。GitHub 在这种情况下实现了 MediaWiki 的标记。使用双括号（[[]]），并在其中放入你要链接的 wiki 页面的名称。在我们的示例中，我使用了[[Contributing]]，这将创建一个指向另一个页面的链接。请注意，如果链接不存在，它会以红色显示。如果点击它，你将被重定向到创建页面的界面。
创建标题时，你需要在文本前面加上#。#的数量定义了将使用的标题样式。每个标题都有一个单独的锚点链接，你可以在保存页面时将鼠标悬停在标题上查看这个锚点链接。然后，你可以使用这个锚点链接来引用内部链接。
在我们的示例中，你可以看到我创建了三个标题，即Getting started、Contribute和Alternative methods。在Getting started中，我放置了一个指向Alternative methods的互联链接。实现这一点的 Markdown 代码是[[here|Installation#alternative-methods]]。这种风格引入了两个新的探索领域。
首先，你可以看到，备用文本可以像外部链接一样使用。唯一的区别是，备用文本和链接都放在双括号内，用管道符号（|）分隔。其次，你可以看到如何调用内部引用链接。页面标题放在最前面，后跟井号符号（#），最后是标题。理解这一点很重要，因为作为互联链接的一部分，标题会被转换，而空格会被替换为连字符（-），所有特殊字符（如?,'!等）都会丢失。
你可以随时使用预览来测试锚点链接是否会正确渲染。
内部链接仅在同一 wiki 内支持。你不能使用内部链接链接到另一个 wiki。在这种情况下，你必须使用外部链接。
我们只触及了 Markdown 的表面。你可以在github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet的优秀备忘单中阅读更多相关内容。
如何为你的 wiki 添加侧边栏和页脚
如果你有 wiki 的写入权限，你应该能够看到“添加自定义侧边栏”和“添加自定义页脚”按钮。
GitHub 有一个默认的侧边栏，用于放置所有的 wiki 页面。由于它按名称顺序显示页面，这可能并不总是有用，有时你可能希望用户能够方便地访问重要信息，而无需进行过多的搜索。
和其他 wiki 页面一样，侧边栏也可以使用 GitHub 支持的标记语言编写。在下面的示例中，我使用了Markdown：
如你所见，我使用了一个项目符号列表，并在每个项目上放置了链接。缩进项目（一个或多个空格）将得到以下结果：
就像侧边栏一样，你还可以创建自己的自定义页脚。例如，我使用了两个带有自定义文本的外部链接，正如下面的截图所示：
所有修改完成后，我们得到了一个漂亮的 Wiki 页面，包含自定义的侧边栏和页脚：
查看 Wiki 页面提交历史，并在需要时恢复到之前的状态
如果告诉你 Wiki 本质上是一个独立的 Git 仓库，你会感到惊讶吗？在技巧和窍门部分，我们将看到如何将 Wiki 克隆到本地，进行更改并推送回 GitHub。
与所有 Git 仓库一样，这里有提交记录和历史日志。每个页面都有其过滤后的提交日志，记录了页面所经历的所有更改。一种快速访问历史日志的方法是点击每个页面上的修订链接。这个链接可以在每个页面标题下找到。例如，首页有三个修订版本：
查看页面历史的另一种方式是使用“页面历史”按钮，这个按钮可以在编辑页面时找到。
查看历史日志的另一种方法是将/_history附加到你的页面。例如，github.com/axilleas/github-essentials-v2/wiki/Home 变成 github.com/axilleas/github-essentials-v2/wiki/Home/_history。
这是我的首页日志的样子：
从前面的截图中，你可以获得很多有用的信息。你可以看到，进行更改的人的用户名首先出现在历史表格中。在这个例子中，只有我的用户名，但在有许多协作者的 Wiki 中，你可以很容易地看出是谁做了什么更改。接下来，你会看到提交信息，这非常有用，因为你可以一眼看出更改的内容。第三列是关于更改时间的，最后还有更改的提交 SHA。
现在，让我们利用恢复功能，当事情变得不顺利时。首先，创建一个新页面，保存它，然后删除它。我们无法查看该特定页面的历史记录，因为它已经不再存在，所以我们需要前往主历史页面，它是所有页面的母体。由于此页面是隐藏的，你需要手动将/_history添加到你的主 Wiki 页面后面。
为了恢复更改，你需要使用“比较修订”按钮。你可以选择恢复一个或两个修订版本：
你可以通过默认的 GitHub 提交信息与自定义提交信息进行区分，因为默认信息遵循Created/Updated/Destroyed Title of page (language)的格式，其中language是用于创建该页面的标记语言。
在这里，我们选择了两个提交，但由于它们在提交历史中是连续的，因此只选择最后一个也一样。就像是在比较git show HEAD和git diff sha2 sha1之间的更改，其中sha2是最后一次提交的SHA，sha1是之前的那个。diff是相同的。
点击比较修订按钮后，我们将看到此次提交所引入的更改：
让我们通过点击回退更改按钮恢复被删除的页面。在写这本书的时候，每次我尝试回退删除页面时，都会出现 500 内部服务器错误。尽管出现了错误，但回到历史页面，你会看到回退操作实际上已经执行，并且被删除的页面被从“死而复生”：
你可以看到，回退的提交消息引用了分别创建和删除该页面的两个提交。
有时，由于冲突，你将无法比较两个修订版本并回退。在这种情况下，GitHub 会用一条消息警告你：此补丁无法回退。
这就是关于 GitHub 维基的所有知识。接下来，我们将重点关注如何使用 GitHub 提供的工具来管理代码发布。
管理代码版本
在软件管理的世界中，几乎每一款软件都有一个版本号。这是一个宣告软件随时间演化的方式，通常包括功能增强或 bug 修复。GitHub 利用 Git 的强大功能，提供了一个简单的界面来发布你版本化的软件。
创建发布
在 GitHub 中，发布的概念与 Git 标签紧密相关。你可以在更改分支的相同菜单中查看现有的标签（如果有的话），如下图所示：
如果你访问发布页面并且还没有创建标签，你将被提示创建一个。创建发布将自动创建一个标签。
让我们点击创建新发布按钮。接下来将出现以下页面：
你只需填写标签版本名称框中的内容，其他的都是可选的。如果你提供的标签名称已经存在，你将看到标签名称重复的提示。
你的标签名称可以是任何自定义值，但强烈推荐遵循语义版本控制方案。简要介绍一下语义版本控制：发布号由三个数字组成，数字之间用点分隔，形式为MAJOR.MINOR.PATCH。你应当依此进行递增：
-
MAJOR版本用于进行不兼容的 API 更改 -
MINOR版本用于以向后兼容的方式添加功能 -
PATCH版本用于进行向后兼容的 bug 修复
你可以在semver.org/查看更多内容。
一个很好的命名标签的方式是匹配现有的里程碑。从上一章中我们已经有了一个v0.5的里程碑，因此让我们也将新标签命名为v0.5。开始输入标签名，如果该标签不存在，你会看到“Excellent! This tag will be created from the target when you publish this release message”。
你可以从下拉菜单中选择目标分支或提交，正如以下截图所示：
如果选择了某个分支，将会创建一个指向该分支最新提交的标签。如果你选择进入“最近提交”标签页，可以从多个最近的提交中选择来创建标签。
为了方便我们的示例，选择master分支并输入版本标题。你可以选择性地（但推荐）添加一个描述，说明这个版本的内容。我喜欢把描述当作写一篇博客文章，解释该版本发生了哪些变化。
当然，你可以像在 GitHub 中的几乎任何地方一样使用 Markdown，并使用预览按钮查看渲染效果：
如果你认为一切都已准备好，点击发布版本按钮。你随时都可以编辑任何版本，因此不用担心错过什么。以下截图解释了关于发布的所有信息：
如果没有提供版本标题，标签名将会显示出来。同样，如果没有提供描述，标签的最新提交信息将会显示出来。
编辑版本
要编辑版本，你可以点击版本页面中发布旁边的“编辑发布”按钮，或者直接访问该版本并点击“编辑”。
从命令行推送标签
现在，让我们看看当标签已经存在时，GitHub 会如何反应。我对文件做了一些更改，并从命令行创建了一个新标签。最后，我将这个标签推送到 GitHub，如下所示：
git checkout master
echo "0.5.1" > version.txt
git add version.txt
git commit -m "Release 0.5.1"
git push origin master
如果你现在访问标签页面，将会看到新标签位于我们之前创建的标签上方。在版本页面中，点击“草稿新版本”。我们将选择一个已有的标签，因此在标签版本字段中输入v0.5.1。GitHub 发现该标签已存在，因此通知我们这是一个已有标签：
为其添加一个标题和简短描述，然后发布它。由于v0.5.1标签指向的是最新提交而非之前的发布，因此它现在被标记为“最新发布”。
标记为预发布
一个不错的小装饰功能是，你可以将版本标记为预发布，这意味着你可以告知用户该版本尚未准备好用于生产环境，但他们仍然可以下载并测试它。我们将创建一个develop分支的预发布版本，其中包含master分支尚不存在的新提交：
git checkout master
git checkout -b develop
echo "0.6rc1" > version.txt
git add version.txt
git commit -m "0.6 pre-release"
git push origin develop
从develop分支创建一个新版本，并命名为v0.6rc1。这次，通过勾选相关选项将其标记为预发布：
发布后，版本页面将如下所示：
创建发布草稿
如果你在每次发布时提供详细描述，可能会发现草稿功能非常有用。你可以在反复编辑发布内容并添加所需信息后，将其保存为草稿。这样，在需要发布时，你就可以节省更多时间。
若要制作发布草稿，不要点击“发布版本”，而是点击“保存草稿”按钮。返回到发布页面，你可以看到你刚刚创建的草稿版本：
你可以随时编辑它，当你准备好发布时，只需点击“公开发布”。若要删除草稿，点击“丢弃草稿”按钮。
由于你正在处理草稿，因此不必担心更改版本标签或其他信息。草稿只能由具有写权限的用户查看，因此在发布之前，它不会向公众显示。
上传你自己的文件
有时你可能需要为各种操作系统提供预编译的二进制文件。对于你的 Android 应用程序，它可能是 apk 文件；对于 Windows，是 msi 或 exe；对于 Debian，是 deb；对于 RedHat，是 rpm，等等。
创建发布时，底部会出现一个窗口，提示你附加任何二进制文件。在这里，我上传了一个测试文件 github-essentials.zip，如以下截图所示：
你可以上传多个文件，但请注意，GitHub 对每个文件的上传大小限制为 2 GB。成功上传新的二进制文件并发布版本后，你可以看到你手动附加的文件以及 GitHub 为你发布的源代码：
提示和技巧
这里有个小提示，可以通过 atom feed 获取新版本发布的通知。同时，在你熟悉 Git 的过程中，你会很高兴知道，你可以在本地编辑项目的 wiki。
通过 atom feed 订阅新版本发布
如果你习惯于订阅博客的动态以获取最新的新闻，那么你会很高兴知道你可以订阅以接收 GitHub 上新版本发布的通知。
只需访问发布页面，并在 URL 后面添加 .atom。例如，github.com/diaspora/diaspora/releases 变为 github.com/diaspora/diaspora/releases.atom。酷吧？
本地编辑 wiki
如 wiki 提交历史部分所述，每个 wiki 都是一个独立的 git 仓库。因此，你可以克隆它，在本地进行更改，并推送回 GitHub。
它由 gollum Ruby 库提供支持，我们将安装并使用它在本地预览 wiki。
安装 gollum
gollum 库被打包为 Ruby gem，安装它的最简单和最快方法是按照官方 wiki 条目 github.com/gollum/gollum/wiki/Installation 进行操作。你可能能够避免全局安装它，但这不在本指南的范围之内。
克隆 wiki 并在浏览器中查看预览
回到我们的 wiki 页面，你应该注意到下载链接。每个 wiki 仓库都有一个被绿色标记的远程 URL，如下图所示；它本质上是主 Git 仓库的 URL，后面加上 .wiki：
使用这个 URL 克隆 wiki；然后，在该仓库中运行 gollum 命令：
git clone https://github.com/axilleas/github-essentials-v2.wiki.git
cd github-essentials-v2.wiki
gollum
尽管没有明确说明，你也可以使用 Git 协议而不是 HTTP 克隆 wiki。
如果你看到类似以下的输出，那么 gollum 将成功运行，并且你可以在 0.0.0.0:4567 上预览 wiki：
[2015-07-26 01:09:34] INFO WEBrick 1.3.1
[2015-07-26 01:09:34] INFO ruby 2.1.6 (2015-04-13) [x86_64-linux]
== Sinatra (v1.4.6) has taken the stage on 4567 for development with backup from WEBrick
[2015-07-26 01:09:34] INFO WEBrick::HTTPServer#start: pid=20826 port=4567
界面应该与你熟悉的 GitHub wiki 相似。让我们做一些修改。
本地修改并推送到 GitHub
现在你已经有了一个运行中的 wiki 实例，你可以像在 GitHub 上一样在浏览器中进行修改，或者使用 vim 或 emacs 等编辑器直接编辑文件。
既然你已经知道如何在浏览器中编辑 wiki，我们就用一个编辑器来修改 Installation.md 文件。编辑完成后，保存文件并提交到 Git。花一点时间使用 git log 查看日志，并与 GitHub 上的提交历史进行对比（在 https://github.com/<username>/<repository>/wiki/_history）。
现在将更改推送回 GitHub，然后再次访问历史页面。新提交应该在那里，并显示新的更改。
如果你想使用其他标记语言编写，而不是 Markdown，请参阅 github.com/gollum/gollum#installation 中的说明，了解如何安装所需的 gems。
总结
在这一章中，你了解了文档的重要性，以及 GitHub 如何允许你为每个项目托管一个基于 Markdown 的 wiki。创建、删除、编辑和恢复页面应该已经是你熟悉的术语了。
你问发布版和标签之间的关系是什么？好吧，如果你读了本章的第二部分，你应该已经知道它们之间的联系以及如何创建发布版并将其分发给公众。
在下一章，你将看到如何管理组织和团队。继续阅读，了解如何利用协作的力量。
第三章：管理组织和团队
在第二章，使用 Wiki 和管理代码版本控制中，我们探讨了如何使用 GitHub 提供的内置 Wiki 为你的项目编写文档，并了解了如何通过 GitHub 发布来管理代码版本。
了解何时在你的命名空间下托管项目，何时在组织下托管项目非常重要。通过组织，你可以创建团队，并为在其下托管的不同仓库中的人提供不同的访问级别。
在本章中，我们将讲解如何创建一个组织、邀请成员并授予他们访问组织下托管的仓库的权限。你将学会如何创建团队并将组织成员与团队以及仓库关联起来。
我们将涵盖以下内容：
-
用户和组织之间的区别
-
组织角色和仓库权限级别
-
创建组织
-
全局成员权限
-
仓库
-
团队
-
人员标签
-
组织设置
用户和组织之间的区别
除了只能由你自己使用的用户帐户外，GitHub 还提供了创建由多个用户管理的组织的功能，正如我们稍后将看到的，你还可以在组织内创建团队。
GitHub 是一个协作平台，因此，流量较大的项目需要一些人来帮助维护。
当然，创建组织的理由可能不止这些。撇开实际原因不谈，当有多个人时，通常会创建组织，这些人每个人在组织托管的项目中都有平等的权利。
例如，你可以看到像 Twitter、Google，甚至是 GitHub 自己这样的知名公司，它们都有组织，在这些组织下托管着多个项目。
组织角色和仓库权限级别
GitHub 允许你为组织中的每个成员选择三种角色之一：所有者、成员和账单管理员。我们不会涉及后者；如果你想了解更多信息，请参考help.github.com/articles/adding-a-billing-manager-to-your-organization/。
所有者拥有对组织的完全访问权限，并处于权限链的最高级别。在组织方面，他们可以邀请和移除成员，创建和移除团队，创建和移除仓库，以及管理所有人员和仓库的权限级别。他们还可以编辑组织设置。
成员通常是新加入组织的默认角色。成员能够做的最少事情是创建新团队，并将现有的团队成员和仓库添加到其中。
仓库的成员访问级别只能由所有者设置。
会员也可以被提升为某个特定团队的“维护者”。拥有此访问权限，他们可以添加和删除团队成员。可以将其视为比作为成员的角色之外的额外隐藏角色。任何创建新团队的人都会被授予该团队的“维护者”角色。
现在，请注意不要将组织权限与仓库权限混淆。仓库可以拥有四种权限：拥有者、管理员、写入和读取。
拥有者是授予组织所有者的最高权限级别。拥有管理员访问权限的人具备拥有者权限，但仅限于特定仓库；您可以对其进行推送、删除、添加或移除团队、更改团队权限级别、添加外部协作者等。这就像在您的个人命名空间下创建一个新仓库。拥有写入权限，您可以向仓库推送；读取权限仅授予读取权限，这意味着只能克隆和拉取。
要查看各个级别权限的完整列表，请访问 GitHub 的文档：help.github.com/articles/repository-permission-levels-for-an-organization/。
现在我们已经讨论了不同的访问级别和权限，让我们来创建我们的第一个组织。
创建组织
为了创建组织，找到顶部标题中头像旁的加号按钮，或直接访问 github.com/organizations/new。
在下一屏幕上，选择一个组织名称并填写账单电子邮件。出于测试目的，您可以填写个人电子邮件，之后如果需要可以更改。对于开源项目，创建组织是免费的，这是默认计划。如果组织将由公司拥有，您需要接受公司服务条款。所有这些选项在下图中进行了总结：
当您输入名称时，GitHub 会在后台检查该名称是否已被占用，如果已被占用，将显示一条消息，提示用户名已被占用。
正如您所注意到的，用户名和组织名不能相同。命名空间必须唯一。
在下一步中，您可以选择邀请一些人加入组织。通过他们的用户名、全名或电子邮件搜索，然后选择他们并点击邀请将他们邀请到您的组织中。完成后，点击完成：
创建后，您首先看到的将是您组织的仪表盘，如下图所示：
在我们深入了解团队、人员和仓库之前，让我们先通过在组织设置中全局设置成员权限来查看一些默认设置。
全局成员权限
在邀请人员和创建仓库之前，让我们先查看两个重要的设置并设置一些默认值。进入设置页面并选择成员权限标签：
如您所见，关于仓库有各种设置。第一个是关于仓库创建的，如果启用，组织中的任何成员都可以在组织命名空间下创建仓库。
如果您希望更加开放，可以启用此选项；如果希望更加严格，可以禁用它。禁用后，只有拥有者能够创建仓库。外部合作者（见成员与外部合作者的区别部分）无论此选项如何，都不能创建任何仓库。
接下来的两个选项是针对具有管理员权限的仓库成员。您可以启用或禁用仓库删除及其可见性状态，以允许他们对拥有管理员权限的仓库执行这些操作。
下一个选项是关于组织内部任何私有仓库的分叉行为。默认情况下，它是禁用的，组织成员将无法分叉私有仓库。
最后的选项是关于组织成员在所有仓库（无论新旧）上的默认仓库权限。您可以选择四个选项：管理员、写入、读取和无权限。无权限是最低的权限，意味着成员只能克隆和拉取公共仓库。拥有读取权限的成员可以克隆和拉取所有仓库，无论是公共还是私有。写入权限意味着除了读取权限，成员还可以向仓库推送内容。最后，管理员权限将赋予每个成员拉取和推送仓库内容的能力，同时还能更改仓库设置。
在本章的其余部分，示例将基于成员能够创建仓库，且默认仓库权限级别为读取，除非另有说明。
我们将在本章稍后探讨其余的设置。
仓库
因此，您新仪表板上的第一个标签是“仓库”，由于当时没有仓库，GitHub 会提示您创建一个。
一旦点击创建新仓库按钮，您将进入一个熟悉的页面。如果您阅读了第一章，简要仓库概述及问题追踪器使用，您会注意到创建仓库时唯一变化的是命名空间。如果我愿意，我也可以通过从下拉菜单中选择，将仓库创建在我的用户名下。
在您填写信息并创建仓库后，您可以从您的计算机上传代码并开始工作。您可能已经注意到，在仓库创建后的登陆页面，GitHub 有一条消息提示您添加团队和合作者：
如果你希望立即授予某些人访问权限，那么你应该选择这个路径。对于我们来说，由于这是一个新组织，我们必须首先了解团队以及它们与外部协作者的区别，并了解在仓库中的不同权限。
团队——一种为你的组织项目提供选择性访问权限的好方法
团队是你控制不同访问级别的方式。接下来，我们将看到如何创建团队并将成员添加到其中。
创建团队
与 GitHub 中的大多数操作一样，你可以通过不同的方式创建团队。最直观的方法是进入“团队”标签，点击“新建团队”按钮：
另一种创建团队的方法是进入组织仓库的设置，在“协作者与团队”标签下，点击“创建新团队”按钮。请注意，只有属于组织命名空间下的仓库才会显示“团队”选项。如果你编辑个人项目，则只能看到“协作者”框。
当你首次创建新团队时，将显示以下表单：
团队名称是必填项，且操作有两个方面。你可以输入可读的文本，包括标点符号和大小写，但请注意，出现在 URL 中的名称将被转换为小写。例如，GitHub Core 会变成 github-core。任何特殊字符都会被去除并转换为短横线（-）。
你可以添加一个可选的描述，并选择该团队是公开可见还是保密。保密团队只对成员和所有者可见。
由于 GitHub 支持嵌套团队，你还可以选择该团队应该隶属于哪个父团队。如果这是你创建的第一个团队，将没有父团队，因此该选项将不可用。
创建团队后，你将进入该团队的页面，查看团队成员以及该团队可以访问的仓库。你可以与团队成员开始讨论，也可以编辑团队设置，例如更改团队名称或删除团队：
邀请成员
创建团队的目的就是让人加入其中。到目前为止，你是该组织唯一的成员；现在，让我们邀请其他人加入团队。
你只能邀请已注册的 GitHub 用户加入团队。
转到“团队”标签，选择你想邀请成员加入的团队。然后转到成员标签，点击“添加成员”。开始输入用户名，GitHub 会自动排序，直到找到正确的用户名：
在选择完成员后，你会看到 GitHub 提示有一个待处理的邀请。如果你点击待处理邀请的链接，会弹出一个对话框，你可以在其中编辑邀请：
默认情况下，您被邀请加入团队时的角色是成员。如果您想将角色改为所有者，您可以编辑邀请，修改角色，并可以选择分配不同的团队。您还可以取消邀请：
只有所有者才能邀请新成员加入团队或组织。一个人必须是组织成员，团队维护者才能将其添加到团队中。
接受邀请
GitHub 会发送一封电子邮件通知被邀请的人关于邀请的事宜。在邮件中，包含了一个链接，点击后会跳转到组织页面，在那里您可以接受邀请，或者您也可以忽略邮件，直接访问组织页面。
这里我作为被邀请的人访问了组织页面，正如您所见，我看到了一个加入组织的提示：
无论如何，最终的页面将显示您是否决定加入该组织，如下所示：
让我们接受邀请并开始作为组织的一员工作。接受后，您将能够看到您可以访问的人员、代码库和团队。
团队成员权限
作为团队的维护者，当您访问团队页面的成员标签时，您可以更改成员的团队访问权限。选中一个或多个团队成员的复选框以更改他们的成员身份。完成后，您会注意到下拉菜单会出现。从中，您可以将选中的成员从团队中移除或更改他们的角色。让我们点击更改角色链接并将角色改为维护者：
在您将某个成员提升为维护者后，他们将拥有更多的权限，并且维护者标签会出现在他们的用户名旁边：
维护者现在可以添加或删除团队成员、编辑团队设置，甚至删除团队。
请求加入团队
有时，某个成员可能希望加入另一个在代码库中拥有更多权限的团队。如果您已经是组织成员，您可以请求加入现有的团队。让我们分步来看一下如何操作。
步骤一 - 作为用户
前往您想要加入的团队，选择“成员”标签页，您会注意到在您还不是成员的团队中会有一个“请求加入”按钮。点击它并等待管理员审核您的请求。
一旦您请求加入团队，所有者或团队维护者将必须接受您的请求。如果您现在重新访问该团队的成员页面，您会看到“取消待处理请求”按钮。这样您就知道您的请求尚未被批准，正如您可能猜到的，您可以取消请求。
步骤二 - 作为所有者或团队维护者
当你请求加入一个团队时，会通过电子邮件通知所有者和团队维护者你的加入请求。作为所有者或团队维护者，访问相关团队的“Members”标签时，你会看到有一个待处理的请求：
点击它并接受或拒绝请求：
将仓库添加到团队
假设组织下已经创建了一个或多个仓库，现在是时候将一个仓库添加到团队，并探索团队在此仓库上的权限了。记住，只有拥有者可以对所有团队执行此操作，而团队维护者只能对他们所维护的团队执行此操作。
有两种方法可以将团队与仓库配对，反之亦然。第一种方法是在团队中搜索仓库，第二种方法是在仓库中搜索团队。
让我们尝试第一个。前往你想要添加仓库的团队，在“Repositories”标签下点击“添加仓库”按钮，并开始输入要添加的仓库名称：
如你所见，这个仓库的默认访问权限是“读取”（Read）。这是我们在全球成员权限部分设置的默认访问权限。无论全局选项如何，你都可以为团队访问的每个仓库设置不同的权限：
团队成员不能更改仓库的访问权限，但可以将仓库从团队中移除。
现在，如果你前往仓库设置中的“Collaborators & teams”标签，你可以看到已添加的团队：
团队讨论
就像在问题中添加评论一样，团队成员可以讨论那些可能不适合直接放在问题中的内容。你可以在团队的首页开始一场讨论：
在开始新的讨论时，你可以选择让整个组织都能看到，或者仅限于团队成员可见。
“People”标签
“People”标签是作为拥有者，你可以管理组织成员权限的地方：
从之前的截图中，你可以看到，作为所有者，你可以更全面地查看组织中成员的情况。让我们来看看这些设置都意味着什么。
2FA 标记表示成员尚未启用双因素认证。从安全角度来看，你希望组织的每个成员都启用 2FA，以防止潜在的账户泄露，导致未经授权的访问组织的仓库。
接下来是组织成员的可见性。每个用户必须为自己设置可见性。设置为私有（Private）可以隐藏你的成员身份，选择公开（Public）则会公开它。如果你公开了，组织的头像将在你的个人资料中显示。
接下来，你可以看到每个成员参与了多少个团队。点击数字会显示具体的团队。
最后是组织角色。只有拥有者才能更改成员的组织角色，你可以通过“更改角色...”链接将其设置为“成员”或“拥有者”：
“管理”按钮将带你进入个人的管理页面。让我们仔细看看。
管理访问级别
选择“管理访问”会将你带到某个人的管理页面：
在左侧框中，你可以看到与“人员”仪表盘中显示的相同信息。从这里，你可以更改成员的角色，甚至将他们从组织中移除，清除他们在组织仓库上的所有权限。外部协作者选项将在下一节中介绍。
在右侧，你可以看到他们可以访问的所有仓库，并且可以管理每个仓库的访问级别。让我们点击“管理访问”按钮来探索这个设置：
根据你在全局设置中的访问权限，如我们在 全局成员权限 部分看到的那样，你可以看到在特定仓库中的访问级别。这些访问级别也来自团队在仓库上拥有的特定权限，如在 将仓库添加到团队 部分探讨过的那样，这些权限可以覆盖全局默认设置。
让我们进行一个测试，将全局设置改为“写入”，看看会发生什么。点击“读取”框下的“成员权限设置”中的“编辑”按钮。然后，将“默认仓库权限”改为“写入”，接受 GitHub 的提示，返回到上一页查看变化：
即使这个人不是授予他们写入权限的团队成员，他们仍然可以拥有对该仓库的写入权限，因为这已经是全局默认设置。同时，请注意“移除写入权限”按钮是灰色的。由于全局默认设置和团队授予的访问权限相同（写入），因此没有必要降低成员的访问级别。
同样，右上角的“移除对该仓库的访问”按钮是灰色的。它的作用是完全移除访问权限，这意味着为了看到这个按钮启用，你必须将全局仓库访问权限设置为“无”。让我们试试看，如下图所示：
移除对该仓库的访问权限将使该人从最初授予他们访问权限的团队中移除。
这就是管理成员对仓库访问权限的全部内容。接下来，我们终于可以看看外部协作者到底是怎么回事了。
成员与外部协作者的区别
顾名思义，外部协作者是没有组织成员身份但有仓库访问权限的人。就像你可以在个人仓库中给予另一个用户写入权限一样，你也可以在不成为成员的情况下，授予他们对个别组织仓库的写入权限。
目前，我们组织之外没有人可以访问任何仓库。如果你访问人员标签下的外部协作者，GitHub 会告诉你目前还没有任何协作者：
让我们通过进入仓库的设置，在协作者与团队标签中添加一个外部协作者：
选择用户后，点击“添加协作者”按钮：
请注意，默认的访问权限是写入权限而不是读取权限，这对于仓库来说是全局设置的。默认的仓库权限仅适用于组织成员，不适用于外部协作者。
一旦用户接受邀请，你可以前往组织的“人员”页面，选择外部协作者。在此页面上，你可以管理协作者的访问权限，甚至邀请他们加入组织。点击齿轮按钮并选择管理来管理他们的访问权限：
这个用户对一个仓库有写入权限，我们可以看到这是一个外部协作者。通过进入“管理访问”，你可以移除该用户对仓库的写入权限，或者完全移除其访问权限：
降级为外部协作者
就像你可以在被邀请时升职为成员一样，你也可以被降级。在“人员”标签下点击用户的用户名来管理他们的访问权限：
当转换为外部协作者时，团队中赋予此人的任何仓库访问权限将被保留。
组织设置
到目前为止，我们只探讨了成员权限设置。让我们通过前往组织的设置页面，查看其余设置。
个人资料
在个人资料页面，你可以更改组织的名称和描述，添加网址和个人资料图片，重命名组织命名空间，甚至删除它：
完成所有这些更改后，你会看到你组织的着陆页会变得更加美观：
安全性
在安全性标签下，你可以要求组织的所有成员启用两因素身份验证，以最大化安全性。
审计日志
如果你曾在 Unix 环境下工作过，你应该知道系统中几乎所有的操作都会被记录在某个地方（通常是在 /var/log/ 下）。同样，GitHub 会将大多数操作记录在所谓的审计日志中。
当我进行所有团队创建、成员管理和仓库示例时，我得到了一个相当大的审计日志：
你可以看到哪个用户执行了什么操作，以及执行该操作的时间。为了更好地探索日志，GitHub 提供了以 CSV 或 JSON 格式提取日志的选项。你甚至可以使用搜索功能来筛选特定事件。
第三方访问
第三方访问是一个高级设置。一些应用程序和许多 Web 应用程序通过与 GitHub 交互并获取关于仓库、团队、用户数据等的信息来实现此功能。GitHub 提供了功能丰富的 API 来实现这一点。
默认情况下，这是被设置为受限的。这意味着，如果作为用户您授权某个应用程序，例如，读取您所有的仓库，它将无法访问组织中的仓库。
如需更多信息，您可以阅读 GitHub 的文档，链接为 help.github.com/articles/about-oauth-app-access-restrictions/。
团队
在团队标签页下，您可以全局启用或禁用团队讨论。
技巧和窍门
这里有一些技巧和窍门，帮助您补充目前为止学到的内容。
如何将一个仓库转移到组织的命名空间
有时，您的仓库可能更适合放在组织的名下。在这种情况下，您可以将其转移到组织的命名空间。只有当您至少是该组织的成员时，才可以将仓库转移到组织下。
进入您的项目设置，在“危险区域”部分，您会看到一个转移按钮：
弹出框会出现，要求您确认并提供仓库的名称和您希望转移的组织名称：
如果您是该组织的成员，在下一步，您可以选择是否希望其他团队也能访问该仓库：
准备就绪后，点击转移按钮。GitHub 会通知您转移可能需要几分钟时间，但如果仓库相对较小且只有少数协作者，转移将会瞬间完成。如果您仔细观察您的仪表板中的仓库列表，您会注意到，您之前的仓库现在已经在其名称前加上了组织的命名空间。
如果您进入仓库的设置，在协作者与团队标签下，您会看到您被列在协作者中。在这种情况下，访问权限设置为写入，这是默认的全局值：
如果您将仓库转移到您不是其所有者的组织中，您可能会失去先前在该仓库中的管理员权限。您可以随时请求组织所有者授予您访问权限。
如何将用户帐户转换为组织帐户
基于“用户与组织之间的区别”部分提到的原因，您可能想将个人帐户转换为组织帐户。您可以在用户的设置中的组织标签页下轻松完成此操作。
然后，您可以点击将用户名转为组织帐户按钮。请确保这是您想要的操作，因为此操作不可逆。
在下一步，你需要选择一个组织的所有者。开始输入名字，当名字出现时，选择它并点击“选择”。最后，点击“创建组织”以启动转换过程。
提及团队
在问题和拉取请求中吸引团队注意的一个很酷的方式是提及整个团队。你可以使用以下语法来实现这一点：@organization/team。例如，要吸引文档团队的所有人的注意，你可以这样写：@github-essentials/documentation。只有组织的成员和所有者可以提及团队。
创建一个问题并看看这个功能是如何运作的。前往你所在组织的仓库，创建一个新问题并尝试提及一个团队：
如果你是团队的一员或拥有者，你将收到一封电子邮件和一个通知，通知会出现在github.com/notifications页面：
自动完成的结果仅限于仓库合作者和线程中的其他参与者，因此这不是一个完整的全局搜索。
仪表板中的组织动态
当你在github.com的首页时，你可以看到你仓库的仪表板活动以及你关注的人员。有时候，当你是多个组织的成员时，信息可能会显得杂乱无章，因此你可能更希望将活动过滤到一个组织。
只需从下拉菜单中选择你希望过滤的组织，你将只看到该组织的活动。如果你愿意，你还可以通过页面底部的 Atom 订阅链接订阅新闻源：
总结
就是这样！恭喜你完成了这一章节。现在你应该已经熟悉了几乎所有的组织功能。创建团队、邀请成员、以及管理仓库访问权限应该变得更加简单。
如果你觉得难以跟上，我建议你只是尝试操作一下，创建一个测试组织，再次浏览这一章节。坦白说，这一章节就是这么写出来的。我创建了一个组织，一个第二个测试用户，通过反复试验，这一章节才诞生。鉴于 GitHub 在测试版中发布了新的组织功能，我做了大量测试。我认为最终结果是值得的。
在下一章，我们将探索 GitHub 最强大的功能：协作与拉取请求。
第四章：使用 GitHub 工作流进行协作
在第三章，管理组织和团队中，我们探讨了如何创建和管理组织和团队，这将进一步帮助你与他人协作。
GitHub 是一个出色的协作工具，因此，它基于其提供的功能和 Git 的强大能力创建了一个工作流。它将这个工作流命名为 GitHub 工作流(guides.github.com/introduction/flow)。
在这一章中，我们将学习如何使用分支和拉取请求，它们是 GitHub 最强大的功能。以下是我们将要讨论的内容：
-
学习拉取请求
-
同行评审与内联评论
-
合并拉取请求
-
提示与技巧
学习拉取请求
拉取请求是 GitHub 最重要的功能之一，它让 GitHub 发展成今天的样子。它在 2008 年初被引入，并且从那时起在项目中得到了广泛应用。
尽管项目设置中的其他所有功能（例如问题和维基）都可以被禁用，但拉取请求始终是启用的。
为什么拉取请求是一个强大的工作工具
无论你是在进行一个只有你自己参与的个人项目，还是在一个有来自全球各地贡献者的大型开源项目中，使用拉取请求（pull requests）肯定能让你的工作变得更加轻松。
可以将拉取请求看作是提交的块，而 GitHub 的用户界面帮助你清晰地可视化即将合并到默认分支或你选择的分支的内容。拉取请求可以通过增强的不同视图进行审查。你可以通过 GitHub 上的一个简单按钮轻松地撤销它们，并且在合并之前可以进行测试，前提是仓库中启用了 CI 服务。
CI 代表 持续集成。有关更多细节，你可以参考 GitHub 集成的应用程序，github.com/marketplace/category/continuous-integration。
分支与拉取请求之间的联系
分支与拉取请求之间有一种特殊的联系。在这种联系中，如果你在仓库中推送一个新分支，GitHub 会自动显示一个按钮来创建新的拉取请求。正如我们在接下来的章节中将探讨的，这与 GitHub 工作流紧密相关，GitHub 使用一些特殊的术语来描述从分支和到分支。根据 GitHub 的文档：
Base 分支是你认为应该应用更改的地方，Head 分支是你希望被应用的分支。
所以，在 GitHub 的术语中，head 是你的分支，而 base 是你希望合并到的分支。
在项目中直接创建分支 – 共享代码库模型
GitHub 称之为共享仓库模型，这是指你将新分支直接推送到源仓库。从那里，你可以通过比较分支来创建新的拉取请求，正如我们将在接下来的章节中看到的那样。
当然，要能够推送到仓库，你必须是该仓库的所有者或合作者；换句话说，你必须拥有写权限。
在你的分叉中创建分支——分叉和拉取模型
分叉的仓库与它们的父仓库之间有一种关系，GitHub 用这种关系来比较它们的分支。分叉和拉取模型通常用于那些没有写权限但希望贡献的项目。
在分叉一个仓库后，你将分支推送到你的分叉，并在父仓库中创建一个拉取请求，要求其维护者合并这些更改。这是为开源项目贡献代码时常用的做法。你不会直接访问他们的仓库，但由于它是开源的，你可以分叉该公共仓库并在自己的副本上进行工作。
如何创建并提交拉取请求
有很多方法可以发起创建拉取请求，我们将在接下来的章节中看到。
最常见的方法是将分支推送到你的仓库，并让 GitHub 的界面引导你。我们首先来探索这个选项。
使用“比较并发起拉取请求”按钮
每当新分支被推送到仓库时，GitHub 会显示一个快速按钮来创建拉取请求。实际上，你将被带到比较页面，正如我们将在下一节中探讨的那样，不过有些值已经为你填写好了。
比如说，我们可以创建一个名为add-gitignore的新分支，在这个分支上我们将添加一个.gitignore文件，内容如下：
git checkout -b add-gitignore
echo 'password' > .gitignore
git add .gitignore
git commit -m 'Add .gitignore'
git push origin add-gitignore
接下来，前往你的仓库主页，你会注意到“比较并发起拉取请求”按钮：
从这里开始，如果你点击这个按钮，你将被带到比较页面。请注意，我是按照共享仓库模型将分支推送到我的仓库，因此 GitHub 会这样欢迎我：
如果我使用分叉和拉取仓库模型会发生什么呢？为此，我创建了另一个用户来分叉我的仓库，并按照相同的步骤添加一个名为add-gitignore-2的新分支，并做出相同的更改。从这里开始，当你将分支推送到你的分叉时，无论你是在你的分叉页面还是在父仓库页面，都会看到“比较并发起拉取请求”按钮。
如果你访问你的分叉，界面会是这样的：
如果你访问父仓库，以下截图将会出现：
在最后的这种情况下，你可以看到这个分支来自哪个用户（axil42:add-gitignore-2）。
无论哪种情况，当使用分叉和拉取模型时，点击“比较并发起拉取请求”按钮将带你到比较页面，页面上有略微不同的选项：
由于你正在跨分叉进行比较，因此有更多的细节。特别是，你可以看到基础分叉和分支，以及你拥有的头部分叉和分支。
GitHub 会将你仓库中设置的默认分支视为你想要合并到的分支（基础分支），当“创建拉取请求”按钮出现时。
在提交之前，让我们看看你可以用来创建拉取请求的另外两种选项。如果你愿意，可以跳到 提交拉取请求 部分。
直接使用比较功能
如上一节所述，比较与拉取请求按钮会带你进入比较页面，并提供一些预定义的值。该按钮在你推送新分支后会出现，并且只会出现短暂的时间。在本节中，我们将看到如何直接使用比较功能来创建拉取请求。
你可以通过点击仓库主页面上分支下拉列表旁的“新建拉取请求”按钮来访问比较功能：
这非常强大，因为你可以在分叉之间进行比较，或者在同一仓库中几乎比较任何东西——分支、标签、单个提交和时间范围。
当你进入比较页面时，默认页面如下；你开始时是将你的默认分支与 GitHub 进行比较，提出一个最近创建的分支列表供选择并进行比较：
为了进行比较，基础分支的提交必须早于你要比较的提交。
在这里，如果我选择 add-gitignore 分支，GitHub 会将其与 master 进行比较，并显示出差异，同时提示它可以无冲突地合并到基础分支中。最后，你可以创建拉取请求：
请注意，我在自己的仓库中使用了比较功能。当在一个是其他仓库分支的仓库中进行比较时，比较功能会略有变化，并且自动包含更多选项，正如我们在上一节中所看到的那样。
如你所注意到的，新建拉取请求快捷按钮只是手动使用比较功能的快捷方式。如果你想对比较的仓库和分支有更多细致的控制，请直接使用比较功能。
使用 GitHub 网页编辑器
到目前为止，我们已经看到了启动拉取请求的两种最知名的方法。还有第三种方式：使用 GitHub 完全提供的网页编辑器。这对于那些不太熟悉 Git 和终端的人非常有用，也可以被更高级的 Git 用户用来快速提出变更。
一如既往地，根据你使用的模型（共享仓库或分叉与拉取），流程会稍有不同。让我们首先探索使用网页编辑器的共享仓库模型流程，也就是编辑你拥有的仓库中的文件。
共享仓库模型
首先，确保你在你希望从中分支的分支上；然后，前往你希望修改的文件，点击带有铅笔图标的编辑按钮：
对该文件进行所需的更改，添加适当的提交信息，并选择“创建新分支”，并为新分支命名。默认情况下，分支名称为 username-patch-i，其中 username 是你的用户名，i 是从 1 开始递增的整数。连续对文件的编辑会创建 username-patch-1、username-patch-2 等分支。在我们的例子中，我决定为该分支取一个自己喜欢的名字：
准备好后，点击“提议文件更改”按钮。从这一刻起，分支会随你所做的文件编辑而创建。即使你关闭下一页，你的更改也不会丢失。我们暂时跳过拉取请求提交，来看一下分支与拉取请求模型是如何工作的。
分支与拉取请求模型
在分支与拉取请求模型中，你会将仓库进行分叉，并从你在分叉仓库中所做的更改提交拉取请求。在使用网页编辑器的情况下，需要注意的是，为了让 GitHub 自动识别你希望在父仓库中执行拉取请求，你必须从父仓库启动网页编辑器，而不是从你的分叉仓库启动。在以下截图中，你可以看到在这种情况下发生了什么：
GitHub 会通知你在你的仓库（分支）中创建一个新的分支，并包含新更改，以便提交拉取请求。点击“提议文件更改”按钮会带你进入提交拉取请求的表单：
与共享仓库模型相反，现在你可以看到被比较的基础仓库/分支。同时，注意到新分支的默认名称是 patch-i，其中 i 是递增的整数。在我们的例子中，这是第一个创建的分支，因此它被命名为 patch-1。
如果你希望能够自由命名分支，应该按照前述部分的共享仓库模型说明进行操作。按照这种方式，在你有写权限的分叉仓库中编辑文件，添加自己喜欢的分支名称，点击“提议文件更改”按钮以创建分支，然后在要求创建拉取请求时取消操作。然后你可以使用“新建拉取请求”快捷按钮，或直接使用比较功能向父仓库提议拉取请求。
使用网页编辑器时需要考虑的最后一件事是一次只能编辑一个文件的限制。如果你希望在 GitHub 为你首次编辑文件时创建的同一分支上进行更多更改，你必须先切换到该分支，然后再进行后续更改。如何切换分支？只需从下拉菜单中选择它，如下截图所示：
提交拉取请求
到目前为止，我们已经探索了启动拉取请求的各种方式。在本节中，我们将最终提交它。
拉取请求表单与创建新问题时的表单是相同的。更多详细信息，请参阅第一章，问题追踪器的简要概述与使用，以及学习如何使用问题追踪器的强大优势部分。
如果你对要发起拉取请求的仓库有写入权限，那么你就可以设置标签、里程碑和指派人。
拉取请求的标题会自动填写为该分支的最后一次提交消息，或者如果有多个提交，它会填写分支名。在任何情况下，你都可以根据需要进行修改。在以下截图中，你可以看到标题是从分支名称中获取的，GitHub 已经去除了特殊字符。从某种意义上来说，标题变得更具人性化：
如果需要，你可以添加可选的描述和图片。准备好后，点击创建拉取请求按钮。在接下来的部分中，我们将探讨同行评审如何工作，并最终合并拉取请求。
同行评审和内联评论
拉取请求的酷之处在于你可以清晰地看到即将合并的内容。你只会看到重要的变更，最棒的是你可以围绕这些变更展开讨论。
在前一部分，我们提交了拉取请求，以便进行审查并最终合并。假设我们正在与一个团队合作，他们加入进来讨论这些更改。让我们首先检查拉取请求的布局。
拉取请求的布局
每个拉取请求大致如下所示：
从前面的截图中，你可以看到拉取请求的具体编号。它就像是仓库中的标识符，并且与问题的计数没有分开。问题和拉取请求共享相同的 ID 计数器。所以，在上面的例子中，尽管这是我们的第一个拉取请求，但它被编号为#6；前面的五个是问题：
然后，会显示该拉取请求的状态（已打开）以及谁想要将多少次提交合并到哪个分支，来自哪个其他分支：
在我们刚才描述的信息下方，有四个标签：对话、提交、检查和更改的文件。在“对话”中，除了我们在接下来截图中看到的评论外，GitHub 还会添加与该拉取请求相关的事件信息。你可以看到动作和发生的时间。例如，看看下面的截图；即使是小的变更，如添加标签，也会被记录下来：
“对话”（Conversation）选项卡也是最终决策的地方。这里有合并拉取请求的按钮，你可以看到按钮的状态。如果按钮是绿色的，表示更改的文件与仓库中的文件没有冲突：
最后，评论表单与我们在第一章中探讨的“问题追踪器”是一样的，简要的仓库概览与问题追踪器的使用。你可以在这里留下关于拉取请求的任何评论。
提交（Commits）选项卡显示了该分支中的提交以及尚未合并到目标分支的提交。例如，update-readme分支有两个提交在master分支中不存在。GitHub 按时间顺序显示提交记录，并附带其他信息，如作者是谁，并提供提交的链接：
“检查”（Checks）选项卡专门用于与 GitHub 的 API 交互的外部服务，可以对拉取请求执行检查。可以是一个持续集成（CI）服务，用于测试代码，或者是一个检查拉取请求是否符合某些准则的服务。我们不会详细讨论这个内容，因为它是一个非常广泛的领域，超出了本书的范围，但你可以在 GitHub 的文档中了解更多内容，网址是help.github.com/articles/about-status-checks/#checks.
最后，“更改的文件”（Files changed）选项卡显示了此拉取请求中已更改的文件。有两种方式可以查看提交的差异。默认的方式是以统一方式查看更改，将新增和删除的内容显示在同一页面，如下图所示：
请注意，对于每个新增的行，GitHub 会用绿色背景色标记。相反，如果你删除了一些行，它们将以粉红色显示。这个练习留给你自己完成。
另一种方式是选择“拆分”（Split），GitHub 会以并排视图显示差异。在“Diff 设置”（Diff settings）下拉菜单下，有一个选项可以选择在拆分模式下查看更改。选择它并点击“应用”（Apply），然后重新加载页面以使更改生效：
在下一节中，我们将进一步探讨“更改的文件”选项卡，因为审核过程就是在这里进行的。
审核过程
为了让审核过程更容易跟进，处理大量提交和更改文件时有几个有用的功能。
“更改来源”（Changes from）下拉菜单很有用，如果你想查看某个单一提交或一系列提交所引入的更改：
旁边的“跳转到”（Jump to）下拉菜单列出了所有已更改的文件，您可以选择并跳转到其中一个文件：
当只有两个文件时，这看起来可能有些冗余，但如果有十几个文件，这个功能就非常强大，因为你不需要手动滚动页面寻找你要的内容。
此外，当你向下滚动长页面时，这个菜单会变得固定，以免你需要滚动回到页面顶部：
GitHub 支持内联评论，因此你可以在每一行已更改的代码下留下评论，如在“文件更改”标签中看到的那样。当你将鼠标悬停在某一行时，你会看到一个交叉图标，如下图所示；点击它，评论表单将会出现：
在写评论时，你可以选择立即提交为单条评论，或者开始一个审查。当你开始一个审查时，评论会被提交，但不会通知仓库成员。这样，你可以批量提交评论，并一次性通知提交拉取请求的人。以下示例中，提议修改的文件上有两条评论：
请注意，它们处于待处理状态，等待最终提交以供审查。一旦你准备好结束审查，可以点击评论下方的“完成审查”按钮，或者使用“审查更改”下拉菜单。
从这里开始，你有三个选择。第一个是仅仅评论，并且不要求提交者做任何其他事情。第二个选择是批准更改并留下反馈。最后一个选择是请求更改，通常是在你评论的行中。你可以选择性地留下审查总结，并点击提交审查。
在差异上有一些评论和请求更改后，我们可以看到几件事情。首先，内联评论会计入整体对话，因此“对话”标签应显示该数量。此外，由于请求了更改，这一点会在底部的拉取请求小部件中显示：
作为拉取请求的提交者，你可以点击查看审查链接，查看审查评论，或者点击驳回审查，如果你认为已经处理了所有评论。在后者的情况下，你需要添加一个评论，说明你的操作理由。
修正错误
到目前为止，我们已经看到对话是如何开始的，但如果你所做的更改需要一些调整才能被视为准备好合并时会发生什么呢？
在这种情况下，你可以将新的提交推送到与拉取请求关联的分支，GitHub 会接收这些更改并进行修正。新更改会显示出来，并且可以进一步反馈。在审查过程部分，我的恶魔双胞胎用户 axil42 提出了一个关于提交了错误行的担忧。现在我们将做一个新的提交并推送到 update-readme 分支，看看会发生什么：
git checkout update-readme
sed -i 's/Test change/For more info, check the wiki/' README.md # replace text
git add README.md
git commit -m 'Correct line in README.md'
git push origin update-readme
返回到 GitHub，发生了三项更改。首先，另一个提交被添加到了“提交”标签。然后，在“文件更改”标签中，由于评论依赖的那一行被删除，评论不再显示。相反，你可以看到在“对话”标签中，这个特定的讨论被标记为过时：
如果您在最后一个提交推送时恰好处于“已更改文件”选项卡，GitHub 会通知您关于更改的内容，并提示您刷新页面：
合并拉取请求
在对话进行后，做出了更改，并且同行评审按照预期工作，所以现在是最终合并拉取请求的时候了。
如果您没有合并拉取请求的权限，您应该看到以下结果：
另一方面，具有写入权限的所有者或协作者也可以合并拉取请求。在这种情况下，您应该看到绿色的“合并拉取请求”按钮。点击旁边的箭头，您可以在合并之前选择合并方法。共有三种选项，默认的方式是创建一个合并提交。选择您需要的方式，然后点击合并：
按下这个按钮并不会立即合并，而是会再给您一次确认的机会：
这个合并的提交信息是加粗的部分，而下面可以编辑的则是扩展的提交信息，默认情况下会抓取拉取请求的标题。在扩展的提交信息中，您可以引用带有特殊含义的问题编号。请在本章的技巧与窍门部分中阅读更多内容，了解如何通过拉取请求自动关闭问题。
一旦合并完成，您会看到绿色的图标变为紫色。这表示拉取请求已被合并。
合并拉取请求后删除/恢复分支
为了保持一切整洁，GitHub 提供了一个简单的按钮，可以在拉取请求合并后删除已合并的分支：
完成删除后，GitHub 会将其作为一个操作事件。如果您改变了主意，您可以随时使用“恢复分支”按钮将已删除的分支恢复，如下图所示：
回退一个拉取请求
有时候您可能想回退一个拉取请求，GitHub 使这一操作变得非常简单。合并完成后，合并操作旁边会有一个“回退”按钮：
按下这个按钮会创建一个新的拉取请求，其中包含与之前拉取请求相反的提交。
技巧与窍门
到目前为止，我们已经探索了大部分拉取请求的功能。接下来我们来看看一些进一步发挥其功能的方式。
通过提交信息关闭问题
在第一章，简要的仓库概述与问题追踪器的使用部分，您学习了如何在问题追踪器中引用问题。扩展此功能，您可以在提交信息中引用问题编号，以便在提交合并到默认分支时关闭一些问题。
为了触发此操作，你需要使用一些关键词。例如，提交消息中的 Closes #42 会在该提交与默认分支合并时关闭问题 42。
根据 GitHub 文档，以下关键词将通过提交消息关闭一个问题：
-
关闭
-
关闭
-
已关闭
-
修复
-
修复
-
已修复
-
解决
-
解决
-
已解决
以一个开放的问题为例，假设如下所示，并记下它的编号，这里是 2：
然后，进行一次提交，在其消息中使用前面提到的关键词，并引用前述问题编号。我们将遵循本章所学的 GitHub 流程，所以首先创建一个新分支：
git checkout master
git checkout -b fix-issue-2
为了举例说明，我修改了仓库中的一个文件，并提交了以下内容：
git commit -m 'Demo example of closing issues. Closes #2'
git push origin fix-issue-2
然后，打开一个新的拉取请求来合并我们刚刚创建的分支，并按照本章所学进行合并。
回到问题跟踪器，你将不再看到问题#2在打开的问题中。相反，去查看已关闭的问题，你会发现问题#2已经关闭。GitHub 提供了所有必要的信息：
欲了解更多关于通过提交消息关闭问题的信息，请查看 GitHub 的文档：help.github.com/articles/closing-issues-using-keywords/。
拉取请求中的任务列表
提交拉取请求时的一个很棒的功能是任务列表。一个进行中的拉取请求意味着你正在处理一个特定的功能/错误等等，但有许多更改不能一次性提交，而且你还需要有人在你进行时进行同行评审。
在这种情况下，你会发现任务列表非常实用。我们来创建一个拉取请求，并在描述框中添加以下内容：
- [ ] First item
- [ ] Second item
- [ ] Third item
- [ ] Fourth nested item
- [ ] Fifth nested item
- [x] Sixth item , closes #2 (marked as resolved)
结果将是一个带有复选框的列表，你可以在完成任务时手动勾选/取消勾选这些项目：
如果你前往拉取请求跟踪器查看概览，你将看到任务列表中显示以下拉取请求：
这对于交叉引用也有效，由于我们在任务列表中引用了问题 2，这将会记录在该问题中：
任务列表也可以存在于问题中。
正在下载拉取请求的差异
对于补丁和差异文件的忠实粉丝，GitHub 提供了一个很棒的功能，你可以查看并下载拉取请求所引入的更改，格式为补丁文件。只需在拉取请求的 URL 后加上 .patch 后缀。例如， github.com/github-essentials/github-essentials-v2/pull/6 就会变成 github.com/github-essentials/github-essentials-v2/pull/6.patch。这个文件的内容包括拉取请求的所有提交。
您的所有开放拉取请求的全球列表
在顶部搜索栏旁边，有一个名为“拉取请求”的链接，点击后会带您到一个页面，您可以在该页面找到所有打开的拉取请求。直接访问github.com/pulls以查看此页面。
使用网页编辑器添加 LICENSE 文件
就像您可以编辑已经存在的文件一样，您也可以创建新文件。在这种情况下，我们想要添加一个许可证文件，GitHub 提供了多种选择方式。在您的仓库首页，点击“代码”选项卡下的“创建新文件”按钮：
在下一页中，输入 LICENSE，以便出现“选择一个许可证模板”按钮：
点击它，然后从 GitHub 提供的选项中选择一个许可证。完成后，点击“审查并提交”：
在下一步中，您需要将更改直接提交到默认分支，或者创建一个拉取请求。一旦更改合并，如果您导航到仓库的主页，您将看到一个指向您刚刚提交的许可证文件的链接：
这里有一个彩蛋。您可以使用英国式的 LICENCE 或美国式的 LICENSE。GitHub 足够聪明，能够识别这种语言差异，实际上它甚至不在乎字母的大小写。值得一提的是，输入 LiCENce 或 liCEnSe 仍然被视为相同！最后，单词 copying 也被视为许可证的同义词，因此之前的示例同样适用于这个词。
使用网页编辑器创建新目录
除了创建新文件，您还可以通过网页编辑器创建新目录。只需点击创建新文件按钮，像我们在之前选择许可证的技巧中演示的那样，然后输入以斜杠（/）结尾的目录名称。您可以根据需要重复此过程。
唯一的警告是空目录不会被 Git 识别，进而也不会被 GitHub 识别，因此如果您希望提交此更改，必须在目录中添加一个文件。
总结
在这一章中，我们探讨了 GitHub 工作流以及执行拉取请求的各种方式，以及 GitHub 提供的多种功能，使得这一工作流更加顺畅。这就是大多数开源项目在有几十个贡献者参与时的工作方式。
在下一章中，我们将学习如何制作仅托管在 GitHub 上的漂亮静态网页，并了解 GitHub 为每个项目提供的分析工具。
第五章：GitHub Pages 和网络分析
在本章中，你将学习如何围绕你的项目构建网页，这些网页将免费托管在 GitHub 上，并使用 Jekyll（一个静态站点生成器）或你提供的 HTML 页面。
在继续探索 GitHub 功能时，接下来是可视化仓库数据的功能。GitHub 实现了一些很棒的功能，例如可以描绘提交活动、仓库的流量情况以及在网络图中的提交历史等图表。
我们将讨论以下内容：
-
GitHub Pages
-
网络分析
-
提示与技巧
让我们开始吧！
GitHub Pages
2008 年底，GitHub 宣布了 GitHub Pages (github.com/blog/272-github-pages)，一个静态网站托管服务。近年来，静态网站数量大幅增加，而 GitHub 在其中起到了重要作用。静态网站是由 HTML、CSS 和 JavaScript 编写的网页构成的，不包含 PHP、Ruby 或 Python 等服务器端代码，也不需要数据库。
为了在 GitHub Pages 上创建一个功能性的网站，你必须遵循一些约定。让我们详细看看如何创建这些页面。
创建用户或组织页面
对于用户和组织，必须创建一个名为username.github.io的仓库，其中 username 是你的用户名或组织名称，文件必须推送到 master 分支。
创建一个以你的用户名命名的新空仓库。创建后，在本地克隆它并添加一个测试的 index.html 页面（将 username 替换为你的用户名）：
git clone git@github.com:username/username.github.io.git
cd username.github.io
echo 'Welcome to my first page!' > index.html
git add index.html
git commit -m 'Add the first webpage'
git push -u origin master
上传完成后，访问 https://username.github.io（其中 username 是你的用户名），查看结果。
就这样！你可以开始编写自己的 HTML 页面并推送到 GitHub。更改几乎是即时生效的。
创建项目页面
项目页面与用户/组织页面有所不同；你的网站源文件可以存放在以下三种位置之一：gh-pages 分支、master 分支，或 master 分支中的 docs 目录。你可以在仓库的设置中的 GitHub Pages 选项下选择你想使用的一个。
对于项目页面，如果仓库中有一个名为 gh-pages 的分支，那么它的 HTML 内容会被 GitHub 自动提供。最终，项目页面将通过 https://<username>.github.io/<repositoryname> 进行访问。
在这里，我将在 github-essentials 仓库中创建一个 gh-pages 分支，创建一个新的 index.html 文件，并提交并推送到 gh-pages 分支：
git checkout -b gh-pages
echo 'Welcome to my first project page!' > index.html
git add index.html
git commit -m 'Add index.html page'
git push origin gh-pages
一旦 index.html 被上传，它会立即在你页面的 URL 下渲染。由于我上传的是在我的用户名（axilleas）下的 github-essentials 仓库，我知道 URL 会是 axilleas.github.io/github-essentials。
虽然你可以手动修改项目网站的内容，但 GitHub 提供了一个更好的自动化方法，可以一次性更新你的网页内容。请阅读以下章节，了解如何实现这一点。
选择一个主题来样式化你的页面
GitHub Pages 发布约四年后，GitHub 宣布新增了另一个功能——GitHub 页面生成器。
这是为你的项目快速搭建网站的一种简单方法，只需要几次点击。在每个仓库的设置中，有一个 GitHub Pages 部分，并有一个选择主题的选项：
当你选择选择一个主题时，GitHub 会帮助你根据 README.md 文件创建一个单一的 HTML 页面，提供多种漂亮的布局供你选择，并有互动式的逐步指导。此操作仅适用于 gh-pages 或 master 分支中存在的 README.md 文件。如果 README.md 文件不存在，GitHub 会在你第一次选择主题时为你创建一个。
网站内容的格式是用 Markdown 编写的，我们在第二章《使用 Wiki 和管理代码版本控制》中探讨过。你可以使用它的标记语言定义标题和列表，添加链接等。
当你进入主题选择器时，你将能够从现有的布局中进行选择。每种布局都有一个固定的模式，布局中有指向你的仓库 URL 和 ZIP 或 TAR 文件下载的链接和按钮。准备好后，点击选择主题，几秒钟内网站布局就会改变：
从现在开始，每次你更改 README.md 文件时，网站内容会自动更新发布。
每次选择主题时，一个 _config.yml 文件会被提交到你的仓库中，里面包含当前使用的主题信息。
如果你访问提交页面，你可以看到 GitHub 提供了一些关于你网站构建的有用信息。点击绿色勾选图标会带你进入网站：
现在，既然你的网站已经上线，接下来我们来看看如何使用你自己的自定义域名。
使用自定义域名
你可以使用与 user/org GitHub 页面关联的自定义域名，而不是使用经典的 GitHub Pages URL。这意味着你可以告诉 GitHub，当有人访问 www.mydomain.rocks 时，它将显示在 username.github.io 下发布的内容。
首先，在您的 DNS 提供商处创建一个 CNAME 记录，将www.mydomain.rocks指向username.github.io。然后，进入您的仓库的username.github.io设置 > GitHub Pages，在 Custom domain 下添加您的域名，并点击保存。从现在起，每次访问username.github.io时，您将被重定向到www.mydomain.rocks。同样，username.github.io/repository-name下的项目页面也会被重定向到www.mydomain.rocks/repository-name。请注意，您的自定义域名将自动通过 HTTPS 提供服务。如果没有设置强制 HTTPS 选项，请确保您已设置：
使用www子域名作为您的自定义域名，相比仅使用mydomain.com或其他子域名（如blog.mydomain.com），有一些优势。特别是，这样您会自动使用 GitHub 的 CDN，并且免受 DoS 攻击的威胁。有关可以使用的域名类型的更多信息，请访问 GitHub 的文档：help.github.com/articles/about-supported-custom-domains/。
现在让我们探索如何利用静态站点生成器的强大功能，为您的网站创建更多内容。
介绍 Jekyll
到目前为止，我们已经学习了如何通过推送 HTML 文件或使用 GitHub 主题生成器为项目页面手动创建网页。然而，还有一种更复杂的方式可以构建您的网站。
每天，越来越多的人开始使用静态网站来处理他们的个人项目，甚至一些公司也用它来作为他们的主站点或博客平台。与使用服务器端语言（如 PHP）构建的站点相比，静态站点更快、更安全。另一方面，手动维护一个静态站点并完全手动更新其内容是一个繁琐的任务。
由于这些原因，出现了所谓的静态站点生成器：它们是使用模板、标记语言和配置文件的应用程序，并将这些转换为纯 HTML 页面。
GitHub Pages 使用 Jekyll，它是用 Ruby 编写的静态站点生成器，是最顶尖的开源静态站点生成器之一(www.staticgen.com/)。
要使用 Jekyll，您需要访问终端。
安装 Jekyll
要安装 Jekyll，请参考其文档：jekyllrb.com/docs/installation/。如果遇到任何问题，请务必访问他们的故障排除指南：jekyllrb.com/docs/troubleshooting/#installation-problems。
安装完成后，您可以通过在终端中运行jekyll来检查是否安装成功。您应该看到类似如下的输出：
jekyll 3.8.2 -- Jekyll is a blog-aware, static site generator in Ruby
Usage:
jekyll <subcommand> [options]
Options:
-s, --source [DIR] Source directory (defaults to ./)
-d, --destination [DIR] Destination directory (defaults to ./_site)
--safe Safe mode (defaults to false)
-p, --plugins PLUGINS_DIR1[,PLUGINS_DIR2[,...]] Plugins directory (defaults to ./_plugins)
--layouts DIR Layouts directory (defaults to ./_layouts)
--profile Generate a Liquid rendering profile
-h, --help Show this message
-v, --version Print the name and version
-t, --trace Show the full backtrace when an error occurs
Subcommands:
docs
import
build, b Build your site
clean Clean the site (removes site output and metadata file) without building.
doctor, hyde Search site and print specific deprecation warnings
help Show the help message, optionally for a given subcommand.
new Creates a new Jekyll site scaffold in PATH
new-theme Creates a new Jekyll theme scaffold
serve, server, s Serve your site locally
使用 Jekyll 定制您的页面
现在我们将创建一个新的基础站点，这是由Jekyll提供的，以便开始在其上进行构建。可以使用jekyll new path/to/site命令来实现：
jekyll new website
进入新创建的目录并列出文件：
cd website
ls -la
你应该能看到以下目录和文件：
.gitignore
404.html
Gemfile
Gemfile.lock
_config.yml
_posts/
about.md
index.md
现在，让我们在本地构建站点，看看效果如何：
jekyll serve --watch
打开浏览器，访问 http://127.0.0.1:4000，你应该能看到默认的 Jekyll 模板网站：
–watch 选项启用了文件的自动生成，这样你就不需要每次都停止和启动服务器。然而，如果你编辑了 _config.yml，你必须通过停止并重新运行 jekyll serve 命令来重启服务器。
从此以后，你可以开始在新网站上进行修改。首先，试着编辑 _config.yml 文件并更改一些选项。更改标题、描述和电子邮件后，停止并重新启动 Jekyll，以查看更改效果。
当你对更改满意时，便可以将文件推送到 GitHub 仓库的 master 分支（用于用户/组织页面），或者 gh-pages 分支（用于项目页面）。对于一个全新的项目，你需要在 website 目录中初始化一个新的 Git 仓库；或者，对于一个现有项目，你需要将 Jekyll 生成的所有文件移动到现有仓库中。
在下面的示例中，我将假设是从零开始创建一个新的用户页面。首先，你需要在 GitHub 上创建一个新的空的 username.github.io 仓库。接下来，在 website 目录中，输入以下命令：
git init
git add .
git commit -m 'Init commit using Jekyll'
git remote add origin git@github.com:username/username.github.io.git
git push origin master
几秒钟后，GitHub 应该会构建该站点，你可以访问你的用户页面 username.github.io 来确认一切正常。
对于项目页面，确保 _config.yml 文件中的 baseurl 设置为 /repository-name/，否则 CSS 文件将无法正确加载。
阅读更多关于 Jekyll 的信息
如你所见，我们只设置了 Jekyll 开发的基础。欲了解详细文档，请参考 Jekyll 官方网站 jekyllrb.com/docs/home/。你可以在 github.com/jekyll/jekyll/wiki/sites 找到一些使用 Jekyll 的站点。
其他有用的文章当然包括 GitHub 关于 Jekyll 的帮助页面：
网站分析
由于 GitHub 的特性，一个仓库包含大量的元数据，比如提交记录、贡献者、贡献的内容、贡献者的数量、分支的数量，甚至是不同文件的站点引用。
GitHub 提供了一些有用的图表和数据，你可以从中推导出你需要的信息，所有这些都在一个仓库的 Insights 标签页下。让我们来看看其中的内容。
Pulse
Pulse 是一个仓库活动的概览。默认显示的是过去一周的数据，但你可以通过右侧的下拉菜单选择更改时间范围，选择 24 小时、3 天、1 周或 1 个月。
在这里，你可以获得合并和开放的拉取请求（pull request），以及开放和关闭的问题的高层次概览，此外还有该期间的主要提交者：
贡献者 – 添加/删除
在贡献者标签下，你可以查看项目的前 100 名贡献者的概览。该图表是通过仓库的默认分支的数据创建的，展示了从项目开始到当前的所有提交：
默认筛选条件是提交次数。如果你想查看谁做出了最多的添加或删除，可以通过右侧的“筛选贡献”下拉菜单切换筛选条件：
数据可以通过选择图表中的特定时间段来进一步微调。例如，要查看 2015 到 2016 年之间的贡献数据，你可以执行以下操作：
社区资料
在社区标签下，有一个清单，列出了你应该在你的仓库中拥有的最重要的内容，以便让外部贡献者更友好地参与。你可以从下面的截图中看到，已经有了README文件、贡献指南(help.github.com/articles/setting-guidelines-for-repository-contributors/)和许可证文件(help.github.com/articles/adding-a-license-to-a-repository/)，但是缺少行为规范文件(help.github.com/articles/adding-a-code-of-conduct-to-your-project/)。
在这种情况下，GitHub 会帮助你添加一个：
提交随时间变化
提交标签显示的是过去一年中的提交活动。在上方的条形图中，你可以查看每周的提交次数；如果点击其中一条柱状图，下面显示的图表会展示该周每天的提交次数：
代码频率
“代码频率”标签显示的是每周的代码添加和删除：
依赖关系图
在“依赖关系图”标签下，你可以看到项目的依赖关系以及依赖的库。在写本文时，GitHub 只支持 Ruby 和 JavaScript，并检查你的仓库中是否包含Gemfile和package.json文件。如果找到了，它会扫描并列出所有依赖项，以及它们的依赖项：
除了依赖关系列表，GitHub 还会在你使用的某个库发现漏洞时通知你。有关安全警告的更多信息，请阅读 help.github.com/articles/about-security-alerts-for-vulnerable-dependencies/。
网络
网络图表展示了主仓库及其分叉的分支历史。你可以点击并拖动图表，或者使用键盘箭头查看更早的历史。要查看另一个分叉如何偏离其父仓库，点击所有者名称，你将被转到那个仓库的网络图表。
最后，你可以点击小圆点，你将被转到该特定的提交：
如果一个项目有很多分叉，GitHub 将无法渲染网络图表。
Forks
Forks 标签，顾名思义，展示了你的仓库的分叉列表：
流量
流量标签是唯一只能由项目所有者或团队成员查看的标签。仓库的流量越大，可探索的数据也越多。通常，关于流量的信息会保留大约两周。
在第一个图表中，你可以看到一个仓库在该期间被克隆了多少次。将鼠标悬停在圆点上，你可以清晰地看到 GitHub 所称的克隆和独立克隆者的数量，每天都有：
同样，你可以查看过去两周的总浏览量，以及你的仓库有多少独立访客：
在这些图表的正下方是引用站点和流行内容。点击一个站点将带你到另一个页面，其中实际链接会显示。搜索引擎和 GitHub 自身的搜索被排除在外：
小贴士和技巧
下一个技巧是使用一些高级技术，这些技术利用了 GitHub API。
使用 Github Pages 的元数据与 Jekyll
GitHub 在使用 Jekyll 创建 GitHub Pages 时提供了一些元数据。这意味着你可以在 Jekyll 模板中添加某些关键词，这些关键词将自动渲染。
例如，你可以添加 {{ site.github.project_title }} 变量，GitHub 会自动填充项目标题。
按照本章的 Jekyll 介绍 部分中的示例，我们将向 Jekyll 网站添加一个新帖子。
首先，进入仓库目录，确保你在 master 分支并且是最新的：
git checkout master
git pull origin master
接下来，复制默认帖子以便作为参考（你网站中的日期将有所不同）：
cp _posts/2018-06-02-welcome-to-jekyll.markdown _posts/2018-06-02-testing-github-metadata-with-jekyll.markdown
然后，打开新文件并移除所有内容，保留以下内容：
---
layout: post
title: "Welcome to Jekyll!"
date: 2018-06-02 11:42:46 +0200
categories: jekyll update
---
编辑它使其如下所示：
---
layout: post
title: "Testing GitHub metadata with Jekyll"
date: 2018-06-02 00:00:00
categories: jekyll github
---
The name of this project is {{ site.github.project_title }} and owned by
{{site.github.owner_name}}.
提交你的更改并推送：
git add .
git commit -m "Add new post"
git push origin master
几秒钟后，帖子将出现在首页，并且其内容将被渲染变量填充：
你可以在help.github.com/articles/repository-metadata-on-github-pages/了解更多内容。
总结
在本章中，我们学习了 GitHub Pages 的目的以及上传内容的各种方式。对 Jekyll 的简要介绍希望能为进一步阅读和使用这个酷炫的静态网站生成器提供基础。
我们还介绍了 GitHub 提供的各种可视化图表和工具，这些都是每个仓库的一部分。
在第六章，《探索用户和仓库设置》中，我们将深入探讨用户和仓库设置。
第六章：探索用户和仓库设置
在本章中，我们将探讨用户和仓库的最重要设置。您可以通过许多方式来个性化您在 GitHub 上的体验，并通过许多设置来改变您与团队成员共同工作的特定工作流程。
作为用户，您可以在用户设置页面上设置很多信息，例如关联多个电子邮件到您的账户，添加多个 SSH 密钥，并设置双因素认证。
同样地，一些仓库的功能可以通过其设置页面进行设置。例如，您可以启用或禁用 wiki 页面，或完全禁用问题跟踪器。
在本章中，我们将涵盖以下内容：
-
用户设置
-
仓库设置
-
小贴士
用户设置
您可以通过网页界面（在您头像的下拉列表中）访问您的用户设置页面，也可以直接访问 github.com/settings/profile：
例如，这是我的设置首页的样子：
我们将分析 GitHub 提供的最重要的设置。
个人资料
在个人设置下，您可以看到各种可以根据自己喜好自定义的选项。
个人资料设置是您可以填写个人信息以便他人了解您是谁的地方。可以把它看作社交。毕竟，GitHub 是极客们的 Facebook。
所有的个人资料信息都是可选填写的。您可以通过访问您的用户名页面 https://github.com/<username> 查看它会是什么样子。
设置多个电子邮件
每次提交都关联有一个电子邮件地址，GitHub 使用您在本地 Git 配置中设置的电子邮件地址来关联提交与您的 GitHub 账户。您可以向您的账户添加任意数量的电子邮件地址，但只能有一个主要地址。这是 GitHub 将向您发送任何通知的地址，并且在通过网页界面编辑和提交文件时将使用这个地址。
您可以通过访问 github.com/settings/emails 来添加或删除电子邮件并更改主要地址。在这个区域，您还可以选择是否将您的主要电子邮件地址显示给公众。如果您决定保持电子邮件地址的私密性，GitHub 将根据您的用户名分配一个电子邮件：<username>@users.noreply.github.com，这将在您通过浏览器编辑文件时使用。
在以下截图中，您可以看到当您有多个电子邮件时页面是什么样子的：
管理您的 SSH 密钥
GitHub 在使用 Git 时提供了两种用户认证方式。您可以使用 Git over HTTP 或 Git over SSH。有关 Git 协议的详细解释，请访问 git-scm.com/book/ch4-1.html。
使用 HTTP 方式的 Git 时，每次进行更改都必须提供您的用户名和密码，除非您在 Git 中缓存了 GitHub 密码。有关更多详细信息，请参阅文章 help.github.com/articles/caching-your-github-password-in-git/。
推荐且更安全的方式是使用 Git 通过 SSH。其概念是，您创建一个个人独特的 SSH 密钥对，将公钥上传到您的 GitHub 个人资料。您可以根据需要重复此过程，因为 GitHub 允许您将多个 SSH 密钥与帐户关联。这样，您可以为笔记本电脑使用一把密钥，为台式机或服务器使用另一把密钥。
要使用 Git 通过 SSH，仓库的远程 URL 必须如下所示：git@github.com:USERNAME/REPOSITORY.git。
在您的设置选项卡下，有 SSH 密钥选项。您可以通过 GitHub 用户界面导航到此选项，或直接访问 github.com/settings/keys。添加 SSH 公钥时，您必须为其指定一个标题，以便您记住此密钥的来源。在密钥区域，您粘贴公钥的内容。如您所见，GitHub 还提供了一些有用的信息，例如密钥的指纹、添加时间和最后使用时间：
您不能编辑密钥。如果您想设置一个不同的标题，您需要删除旧的密钥并重新添加它。
设置双因素认证
设置双因素认证为您的帐户提供额外的安全保护。仅使用密码登录可能容易受到安全威胁，因为攻击者只需要一条信息即可。
通过在您的手机或平板电脑上生成额外的认证代码来完成此操作。如果使用智能手机，您需要安装一个能够处理基于时间的一次性密码（TOTP）技术的应用程序。如果您在寻找开源应用程序，可以查看github.com/andOTP/andOTP。
要查看支持的应用程序列表，您可以阅读 Wikipedia 的文章 en.wikipedia.org/wiki/Time-based_Onetime_Password_Algorithm#Client_implementations。
如果您没有智能手机，GitHub 也可以通过短信发送认证代码。由于涉及传送费用，因此支持的国家/地区是有限的。查看您的国家/地区是否在此列表中：help.github.com/articles/countries-where-sms-authentication-is-supported/#supported-countries-for-sms-authentication。
您可以在安全页面启用双因素认证（2FA）。直接访问github.com/settings/security并按下“设置双因素认证”按钮以开始设置 2FA。选择任一方法并按照屏幕上的指示操作。
设置完 2FA 后，如果访问安全页面，在您的设置下，您将看到 2FA 已启用：
在安全页面，确保点击链接保存您的恢复代码，并按照屏幕上的说明下载并将恢复代码保存在安全的位置。这些恢复代码共有 16 个，它们可以帮助您在某些情况下无法访问账户时恢复账户。如果手机丢失或被盗，它们能派上用场。每个恢复代码只能使用一次，您可以通过点击生成新恢复代码来生成新的一组代码。请保管好它们，最好将其加密存储在像 KeepassX 这样的应用程序中。
现在，每次您第一次从浏览器登录 GitHub 时，除了常规的用户名和密码外，您还需要输入从智能手机应用生成的授权代码或 16 个恢复代码中的一个。
仓库设置
在仓库级别有很多设置可以调整。要访问这些设置，请查找扳手图标：
更改仓库主页上显示的默认分支
仓库主页的默认分支是master。然而，有时您可能希望根据工作流程更改默认分支，正如我们在第四章，使用 GitHub 工作流进行协作中所看到的那样。
比如，假设 master 分支是您推送被认为是稳定且经过充分测试的代码，而另有一个名为 develop 的分支用于日常推送和测试新功能。根据这个假设，develop 分支的更新频率要高于 master 分支。从实际角度来看，您希望项目显得活跃；在首页显示一个每天都会更新的分支会更具吸引力。
在这种情况下，您可以前往仓库的设置 > 分支页面，并从下拉列表中选择您希望设为默认的分支：
选择后，点击更新并接受 GitHub 提供的提示。
当某人第一次克隆该仓库时，Git 会检出通过项目设置所设定的默认分支。
启用/禁用 Wiki
在第二章，使用 Wiki 和管理代码版本控制中，我们深入解释了为什么 Wiki 对项目是一个强大的资产。然而，也有一些情况下不需要使用 Wiki；例如，您可能会使用外部 Wiki。
GitHub 提供了三种关于 Wiki 可见性的选项：
-
启用 Wiki 并将其设为公开，使每个人都能拥有写入权限（默认设置）
-
启用 Wiki，但只有所有者和协作者具有写入权限（仅限协作者编辑）
-
完全禁用 Wiki
第一个行为是默认行为。您可以在“设置 > 选项”中的“功能”部分找到这些设置。
启用/禁用问题跟踪器
尽管 GitHub 的问题跟踪器是一个强大的协作和错误报告工具，但有时您可能希望使用其他跟踪器，如 Redmine、Jira 或 Bugzilla。
在这种情况下，GitHub 的问题跟踪器可以被禁用，这样您就不会在多个地方进行跟踪并失去控制。可以通过“设置 > 选项”中的“功能”部分实现。
即使禁用了问题功能，已创建的问题仍然会保留。只需重新启用问题功能，您的问题跟踪器将恢复如初。
添加协作者
通过添加协作者，您授予仓库的推送访问权限。一个仓库可以有多个协作者，没有数量限制。
访问设置中的“协作者”标签，开始输入用户的姓名，自动补全功能会智能地为您提供正在搜索的用户：
转移所有权 – 用户到组织
每个仓库都在命名空间下创建，无论是用户还是组织。在极少数情况下，如果您希望将仓库转移给另一个用户，可以在仓库设置中进行此操作。由于此操作被视为危险，因此您会在红色代码块中找到此设置，强调该任务的重要性。
基本上，转移有四种类型：
-
用户到用户
-
用户到组织
-
组织到用户
-
组织到组织
为了初始化转移，您必须提供仓库的名称和新所有者的用户名/组织名以确认：
点击“我明白”后，转移此仓库，会向新所有者发送一封确认邮件。新所有者确认后，过程将完成。
删除仓库
您可以通过点击“删除此仓库”按钮删除仓库及其所有设置，按钮位于“危险区域”下。请注意，这是一个破坏性操作，会清除您的仓库、问题跟踪器、任何拉取请求、Wiki，以及与之相关的所有内容。
按下“灾难按钮”后，系统会弹出一个确认框要求确认。出于安全原因，您必须提供仓库的名称以确认。下图中可以看到，除非提供正确的名称，否则删除按钮将处于不可用状态：
提示与技巧
您知道根据您所属的组织可以使用不同的电子邮件地址吗？您知道您的仓库占用了多少磁盘空间吗？如果不知道，请阅读以下章节，了解如何执行这些操作。
查找仓库的大小
如果你想知道你的仓库变得多大，可以访问github.com/settings/repositories查看。记住，GitHub 也计算.git目录的大小，因此如果你有成千上万的提交，仓库的大小会大于其实际大小（实际大小指的是你在 GitHub 上看到的文件大小）。
例如，在写这本书时，diaspora仓库的大小似乎是 102 MB：
如果我删除.git目录，大小会小得多。让我们通过以下命令来测试一下：
git clone https://github.com/diaspora/diaspora
du -sh diaspora
rm -rf diaspora/.git
du -sh diaspora
删除.git目录后，大小降至几乎 14 MB！
微调电子邮件通知
如果你是多个组织的成员，可能希望为涉及某个特定组织拥有的仓库的通知使用不同的电子邮件。你可以通过访问github.com/settings/notifications来实现；在自定义路由下，选择你希望接收通知的电子邮件。
摘要
完成本章后，你应该已经准备好填写详细信息，以建立一个公开的个人资料，任何有兴趣了解你的人都可以查看。你的账户属于你自己，因此应尽可能保障安全。到目前为止，你应该已经按照步骤通过 2FA 保障账户安全，确保自己稍微安全一些。
你还学习了如何配置仓库的设置，包括默认分支的设置以及启用或禁用诸如问题跟踪器和维基等功能。另一个需要记住的事情是如何向你的项目添加协作者，以及在需要时如何转移项目的所有权。
这些是需要考虑的最重要的设置，涉及用户和项目的设置，到了最后你应该感觉自己更有智慧了。
浙公网安备 33010602011771号