Fork仓库

在版本控制术语中，如果你 “fork” 一个仓库，则是指复制它。特别是当你 fork 属于别人的仓库时，你将制作他们仓库的完全一样的副本，之后这个副本便变成你的。

“fork” 的概念也不同于”克隆”。在克隆仓库时，你也会获得完全一样的仓库副本，但克隆发生在本地计算机上，并且克隆的是远程仓库。当你 fork 仓库时，会创建远程仓库的一份新副本。新副本也是一个远程仓库，但它现在属于你。

fork 不在命令行上执行；也不存在 git fork 命令。

修改克隆的仓库

当我们尝试通过 git clone 克隆别人的仓库到本地后，修改其中的文件并提交，然后将本地仓库再推送到远程仓库时，会出现类似如下内容：

由于我不是仓库所有者，所以我没有权限自动向远程仓库添加我的更改。也就是说，如果一个仓库不属于你的帐户，那么你便不具有修改它的权限。

这里 fork 就要派上用场了！你不能直接修改原仓库，但如果你将仓库 fork 到自己的帐户中，便拥有完全控制权了。

如上图所示，fork 项目后你的 GitHub 配置文件名称旁边会显示新的项目名称。此外名称下面还会说明原始项目所在的位置。现在你可以 fork GitHub 上的任何公共仓库 - 即你可以将仓库复制到自己的帐户中，并对获得的副本拥有完全控制权。

fork 推送/拉取

fork 是一种在托管服务上完成的操作，如 GitHub。fork 仓库会创建与原始仓库完全相同的副本，并将该副本移动到你的帐户。你对 fork 的仓库拥有完全控制权。修改 fork 的仓库不会更改原始仓库。

查看现有工作

我们可以使用非常强大的 git log 命令，查明其他开发者所做工作的详细信息。

使用 git shortlog 按作者对 commit 分组

它显示了按作者字母顺序排序的人名所有 commit。在上面的截图中，我们可以看到：

• Abby Armada 在仓库中添加了一个 commit
• Addy Osmani 添加了八个 commit
• Adriano Caheté 添加了一个 commit
• Akshay Iyer 添加了一个 commit

如果我们只想看到每个开发者的 commit 数量，我们可以添加几个选项：用 -s 仅显示 commit 的数量（而不是每个 commit 的消息），以及用 -n 来按数量排序（而不是按作者姓名的字母顺序）。

$ git shortlog -s -n

如果我们只想看到 Addy Osmani 的这八个 commit 呢？

使用 --author 选项筛选 commit

另一种显示某个作者所有 commit 的方法是使用常规的 git log 命令，但包含 --author 选项来筛选所述作者的 commit 。

$ git log --author="Addy Osmani"

注意，在上面开发者姓名列表中，我们看到了 “Paul Irish” 和 “Paul Lewis”，如果我们运行下面的命令：

$ git log --author=Paul

这将显示所有姓名以 "Paul" 开头的作者的 commit。所以它将显示 Paul Irish 和 Paul Lewis 的 commit 。

注意上一个命令中使用的引号。如果它不加引号，像 git log --author=Paul Lewis，就无法正常运行。如果不加引号，Git 会认为 Lewis 不是 "author" 选项的一部分，从而导致错误。

使用 --grep 选项筛选 commit

在讲解“按搜索内容筛选 commit”这部分之前，我认为我需要强调一下编写好的描述性提交说明的重要性。编写描述性提交说明，会使你之后能很轻松地搜索提交说明，找到你想要的东西。

那么这些详细信息为何重要呢？一方面，你将能更容易地回头查看对仓库所做的更改，其他人也更容易查看更改。另一方面是你将能根据当前说明或描述区域中的信息筛选 commit 。

另外记住，如果提交说明不足以解释 commit 的内容，则你可以在描述区域中提供关于该 commit 用途的详细说明。

我们可以使用 --grep 选项筛选 commit 。以筛选提到 “bug” 一词的 commit ：

$ git log --grep=bug
$ git log --grep bug

注意，空格在这里也是一个问题。如果你尝试搜索包含多个词且单词之间有空格的内容，则需要将空格也包含在引号内。例如，要搜索 unit tests，你需要使用以下命令 git log --grep="unit tests"。

Grep 是一个模式匹配工具，如果你运行 git log --grep "fort"，那么 Git 将显示顺序包含字符 f、o、r、t 的 commit 。

有关 Grep 的更多信息

确定任务

假设你正在使用某个第三方库构建一个项目。如果在使用此第三方库时遇到 bug 或拼写错误，该怎么办？

通过向原项目的维护者发送一个请求，将你的代码更改包含在其中，请求维护者将这些更改拉取到原项目中。这种请求称为“拉取请求”（Pull Request）。

但是，你如何以原项目维护者能接受的方式实际对项目做出贡献，并使他最终合并你的更改？记住，你要做的第一件事，是在项目中寻找一个名为 CONTRIBUTING.md 的文件。

CONTRIBUTING.md 文件

CONTRIBUTING.md 文件的名称特别采用全大写，以方便查找。此文件列出了你要为项目做出贡献时所应遵循的信息。在开始任何开发工作之前，应先找到此文件。

GitHub Issues

注意，这里说的”Issues（问题）”并不代表实际存在错误，它可以是需要对项目进行的任何改变。GitHub 的问题跟踪器相当高级。每个问题都可以：

• 应用一个或多个标签
• 被分配给个人
• 确定一个里程碑（例如问题将由下一个主要版本解决）

但问题跟踪器最重要的一个方面在于，每个问题都可以有自己的评论区，使开发者围绕这个问题展开对话。

Issue 的另一个很棒的功能在于：

• 你可以订阅（Subscribe）某个 Issue ，这样你便会获得新评论和代码更改的通知
• 你可以就具体变更与项目维护者持续交流

在向某个文件贡献任何内容之前，请查看 CONTRIBUTING.md 中的说明。然后查看项目的 Issue，看是否有哪些与你要贡献的内容类似。如果有，则订阅该 Issue 并阅读现有的对话，看你是否可以提供帮助。如果你查看了 Issues 列表，没有看到与你要做的事情类似的内容，那么你可以创建自己的新 Issue（New issue）。

New Issue 页

新建问题页好的一点在于，如果项目有 CONTRIBUTING.md 文件，它会在页面顶部显示一个提醒，要求你查看有关如何为项目做贡献的准则。点击”guidelines for contributing”链接，可以转至 CONTRIBUTING.md 文件。

与编写描述性的提交说明一样，你在创建问题时，要给它一个信息丰富的标题，简要说明你想要做的事情。然后，在评论部分，提供大量关于此更改的详细信息，可以是你为什么认为此更改有必要，也可以是它如何改进项目。

特性分支

组织你想贡献给项目的一系列 commit 或更改的最佳方法，是将它们全部放在一个特性分支上。我说的特性分支是什么意思呢？与主分支不同，主分支是保存整个项目的所有 commit 的默认分支，而特性分支仅保存单个概念或单个更改区域的 commit 。

例如，如果登录某个网站的登录表单有问题，则解决此特定问题的分支名称可以叫做：

• login
• login-bug
• signup-bug
• login-form-bug
• 等等。

要记住的一点是，有时项目会对特性分支的命名有特定要求。例如，如果一个分支将要解决错误修复，那么许多项目会要求添加一个 bugfix- 前缀。回到我们处理登录表单错误的分支，它得被命名为 bugfix-login-form。所以一定要阅读 CONTRIBUTING.md 文件，确定项目是否对特性分支的命名提供了特别说明。

一般实践

编写清晰、描述性的提交说明。你的分支名称和提交说明描述得越清楚，项目维护者用于询问你的代码的用途，或者自己去深入了解代码的时间就越少。项目维护者需要做的工作越少，将你的更改纳入项目的速度就越快。

使用短小而明确的 commit。不要进行大量 commit，记录 10 多个文件和数百行代码的更改。最好频繁多次地进行小的 commit，只记录很少数量的文件和代码更改。

更新 README，如果你添加的任何代码更改会使项目发生极大的变化，则应更新 README 文件以向其他人说明此更改。