统一 fork 的译法：将「派生」改为「分叉」

TRANSLATION_NOTES.asc

@@ -1,7 +1,7 @@
 == 翻译注记
 
 本文件记录了词汇表、翻译风格、表达方式、翻译进度以及注意事项等多种内容。
-在派生此仓库前，请认真阅读本文件以协调翻译工作，统一译文风格。
+在分叉此仓库前，请认真阅读本文件以协调翻译工作，统一译文风格。
 
 翻译版的维护者也可按需修改或重写本文件和 README 文件，在其中包含该语言的翻译指南。
 
@@ -135,7 +135,7 @@ fast-forward => 快进
 
 fetch => 抓取
 
-fork => 派生
+fork => 分叉
 
 ==== *G*
 

book/05-distributed-git/sections/contributing.asc

@@ -506,12 +506,12 @@ image::images/managed-team-3.png[合并了 Jessica 的两个主题分支后她
 image::images/managed-team-flow.png[这种管理团队工作流程的基本顺序。]
 
 [[_public_project]]
-==== 派生的公开项目
+==== 分叉的公开项目
 
 (((contributing, public small project)))
 向公开项目做贡献有一点儿不同。
 因为没有权限直接更新项目的分支，你必须用其他办法将工作给维护者。
-第一个例子描述在支持简单派生的 Git 托管上使用派生来做贡献。
+第一个例子描述在支持简单分叉的 Git 托管上，如何通过分叉来做贡献。
 许多托管站点支持这个功能（包括 GitHub、BitBucket、repo.or.cz 等等），许多项目维护者期望这种风格的贡献。
 下一节会讨论偏好通过邮件接受贡献补丁的项目。
 
@@ -535,7 +535,7 @@ $ git commit
 查看 <<ch07-git-tools#_rewriting_history>> 了解关于交互式变基的更多信息。
 ====
 
-当你的分支工作完成后准备将其贡献回维护者，去原始项目中然后点击“Fork”按钮，创建一份自己的可写的项目派生仓库。
+当你的分支工作完成后准备将其贡献回维护者，去原始项目中然后点击“Fork”按钮，创建一份属于自己的可写项目分叉。
 然后需要在本地仓库中将该仓库添加为一个新的远程仓库，在本例中称作 `myfork`：
 
 [source,console]
@@ -557,7 +557,7 @@ $ git push -u myfork featureA
 ----
 
 (((git commands, request-pull)))
-当工作已经被推送到你的派生仓库后，你需要通知原项目的维护者你有想要他们合并的工作。
+当工作已经被推送到你的分叉仓库后，你需要通知原项目的维护者你有想要他们合并的工作。
 这通常被称作一个 *拉取请求（Pull Request）*，你通常可以通过网站生成它——
 GitHub 有它自己的 Pull Request 机制，我们将会在 <<ch06-github#ch06-github>>
 介绍——也可以运行 `git request-pull` 命令然后将随后的输出通过电子邮件手动发送给项目维护者。
@@ -659,7 +659,7 @@ image::images/public-small-3.png[`featureBv2` 工作之后的提交历史。]
 
 工作流程与之前的用例是类似的——你为工作的每一个补丁序列创建主题分支。
 区别是如何提交它们到项目中。
-生成每一个提交序列的电子邮件版本然后邮寄它们到开发者邮件列表，而不是派生项目然后推送到你自己的可写版本。
+生成每一个提交序列的电子邮件版本然后邮寄它们到开发者邮件列表，而不是分叉项目然后推送到你自己的可写版本。
 
 [source,console]
 ----

book/05-distributed-git/sections/distributed-workflows.asc

@@ -59,7 +59,7 @@ Git 允许多个远程仓库存在，使得这样一种工作流成为可能：
 image::images/integration-manager.png[集成管理者工作流。]
 
 (((forking)))
-这是 GitHub 和 GitLab 等集线器式（hub-based）工具最常用的工作流程。人们可以容易地将某个项目派生成为自己的公开仓库，向这个仓库推送自己的修改，并为每个人所见。
+这是 GitHub 和 GitLab 等集线器式（hub-based）工具最常用的工作流程。人们可以容易地将某个项目分叉成为自己的公开仓库，向这个仓库推送自己的修改，并为每个人所见。
 这么做最主要的优点之一是你可以持续地工作，而主仓库的维护者可以随时拉取你的修改。
 贡献者不必等待维护者处理完提交的更新——每一方都可以按照自己的节奏工作。
 

book/05-distributed-git/sections/maintaining.asc

@@ -380,7 +380,7 @@ image::images/large-merges-1.png[管理复杂的一系列接收贡献的平行
 image::images/large-merges-2.png[将贡献的主题分支并入长期整合分支。]
 
 当主题分支最终被并入 `master` 分支后，便会被从版本库中删除掉。
-Git 项目还有一个从上一次发布中派生出来的 `maint` 分支来提供向后移植过来的补丁以供发布维护更新。
+Git 项目还有一个从上一次发布中分叉出来的 `maint` 分支来提供向后移植过来的补丁以供发布维护更新。
 因此，当你克隆 Git 的版本库之后，就会有四个可分别评估该项目开发的不同阶段的可检出的分支，
 检出哪个分支，取决于你需要多新的版本，或者你想要如何进行贡献；
 对于维护者来说，这套结构化的工作流能帮助它们审查新的贡献。

book/06-github/sections/2-contributing.asc

@@ -2,11 +2,11 @@
 
 账户已经建立好了，现在我们来了解一些能帮助你对现有的项目做出贡献的知识。
 
-==== 派生项目
+==== 分叉项目
 
 (((forking)))
-如果你想要参与某个项目，但是并没有推送权限，这时可以对这个项目进行“派生（Fork）”。
-当你“派生”一个项目时，GitHub 会在你的空间中创建一个完全属于你的项目副本，且你对其具有推送权限。
+如果你想要参与某个项目，但是并没有推送权限，这时可以对这个项目进行“分叉（Fork）”。
+当你“分叉”一个项目时，GitHub 会在你的空间中创建一个完全属于你的项目副本，且你对其具有推送权限。
 
 [NOTE]
 ====
@@ -15,10 +15,10 @@
 ====
 
 通过这种方式，项目的管理者不再需要忙着把用户添加到贡献者列表并给予他们推送权限。
-人们可以派生这个项目，将修改推送到派生出的项目副本中，并通过创建拉取请求（Pull Request，简称 PR）来让他们的改动进入源版本库，下文我们会详细说明。
+人们可以分叉这个项目，将修改推送到分叉出的项目副本中，并通过创建拉取请求（Pull Request，简称 PR）来让他们的改动进入源版本库，下文我们会详细说明。
 创建了拉取请求后，就会开启一个可供审查代码的板块，项目的拥有者和贡献者可以在此讨论相关修改，直到项目拥有者对其感到满意，并且认为这些修改可以被合并到版本库。
 
-你可以通过点击项目页面右上角的“Fork”按钮，来派生这个项目。
+你可以通过点击项目页面右上角的“Fork”按钮，来分叉这个项目。
 
 .“Fork”按钮
 image::images/forkbutton.png[“Fork”按钮.]
@@ -36,14 +36,14 @@ GitHub 设计了一个以拉取请求为中心的特殊合作流程。
 
 流程通常如下：
 
-1. 派生一个项目
+1. 分叉一个项目
 2. 从 `master` 分支创建一个新分支
 3. 提交一些修改来改进项目
 4. 将这个分支推送到 GitHub 上
 5. 创建一个拉取请求
 6. 讨论，根据实际情况继续修改
 7. 项目的拥有者合并或关闭你的拉取请求
-8. 将更新后的 `master` 分支同步到你的派生中
+8. 将更新后的 `master` 分支同步到你的分叉中
 
 这基本和 <<ch05-distributed-git#_integration_manager>> 中的一体化管理流程差不多，但是团队可以使用 GitHub 提供的网页工具替代电子邮件来交流和审查修改。
 
@@ -106,7 +106,7 @@ To https://github.com/tonychacon/blink
  * [new branch]      slow-blink -> slow-blink
 ----
 
-<1> 将派生出的副本克隆到本地
+<1> 将分叉出的副本克隆到本地
 <2> 创建出名称有意义的分支
 <3> 修改代码
 <4> 检查改动
@@ -233,7 +233,7 @@ image::images/pr-01-fail.png[拉取请求合并失败]
 如果你看到了像 <<_pr_fail>> 中的画面，你就需要修复你的分支让这个提示变成绿色，这样维护者就不需要再做额外的工作。
 
 你有两种方法来解决这个问题。你可以把你的分支变基到目标分支中去
-（通常是你派生出的版本库中的 `master` 分支），或者你可以合并目标分支到你的分支中去。
+（通常是你分叉出的版本库中的 `master` 分支），或者你可以合并目标分支到你的分支中去。
 
 GitHub 上的大多数的开发者会使用后一种方法，基于我们在上一节提到的理由：
 我们最看重的是历史记录和最后的合并，变基除了给你带来看上去简洁的历史记录，
@@ -309,7 +309,7 @@ Git 的伟大之处就是你可以一直重复以上操作。如果你有一个
 
 我们来看一个例子。假设我们对上个例子中的分支进行了变基，并为此创建一个新的拉取请求，
 现在我们希望能在新的拉取请求中引用旧的拉取请求。
-我们同时希望引用一个派生出的项目中的议题和一个完全不同的项目中的议题，
+我们同时希望引用一个分叉出的项目中的议题和一个完全不同的项目中的议题，
 就可以像 <<_pr_references>> 这样填写描述。
 
 [[_pr_references]]
@@ -335,7 +335,7 @@ image::images/mentions-03-closed.png[拉取请求关闭]
 
 除了议题编号外，你还可以通过使用提交的 SHA-1 来引用提交。
 你必须完整的写出 40 位长的 SHA-1，GitHub 会在评论中自动地产生指向这个提交的链接。
-同样的，你可以像引用议题一样对派生的项目中的提交或者其他项目中的提交进行引用。
+同样的，你可以像引用议题一样对分叉的项目中的提交或者其他项目中的提交进行引用。
 
 ==== GitHub 风格的 Markdown
 
@@ -489,7 +489,7 @@ image::images/markdown-08-drag-drop.png[拖拽插入图片]
 [[_fetch_and_push_on_different_repositories]]
 ==== 让你的 GitHub 公共仓库保持更新
 
-当你派生了一个 GitHub 仓库之后，你的仓库（即你的“派生”）会独立于原仓库而独立。
+当你分叉了一个 GitHub 仓库之后，你的仓库（即你的“分叉”）会独立于原仓库而独立。
 特别地，当原仓库有新的提交时，GitHub 会通知你：
 
 [source,text]
@@ -500,7 +500,7 @@ This branch is 5 commits behind progit:master.
 
 但你的 GitHub 仓库不会被 GitHub 自动更新，这件事必须由你自己来做。还好，这事儿很简单。
 
-第一种方法无需配置。例如，若你从 `https://github.com/progit/progit2.git` 派生了项目，
+第一种方法无需配置。例如，若你从 `https://github.com/progit/progit2.git` 分叉了项目，
 你可以像这样更新你的 `master` 分支：
 
 [source,console]

book/06-github/sections/4-managing-organization.asc

@@ -20,7 +20,7 @@ image::images/neworg.png[“New organization”菜单项]
 完成以上步骤后，你就会拥有一个全新的组织。
 类似于个人帐户，如果组织的所有内容都是开源的，那么你就可以免费使用这个组织。
 
-作为一个组织的拥有者，当你在派生一个版本库的时候，你可以选择把它派生到你的组织的命名空间内。
+作为一个组织的拥有者，当你在分叉一个版本库的时候，你可以选择把它分叉到你的组织的命名空间内。
 当你新建版本库时，你可以把它存放到你的个人帐户或你拥有的组织内。
 同时，你也会自动地“关注”所有这些组织内的新版本库。
 

book/10-git-internals/sections/transfer-protocols.asc

@@ -91,7 +91,7 @@ Git 会首先检查所有列出的替代版本库：
 (empty file)
 ----
 
-如果这返回了一个包含替代版本库 URL 的列表，那么 Git 就会去那些地址检查松散格式对象和文件——这是一种能让派生项目共享对象以节省磁盘的好方法。
+如果这返回了一个包含替代版本库 URL 的列表，那么 Git 就会去那些地址检查松散格式对象和文件——这是一种能让分叉项目共享对象以节省磁盘的好方法。
 然而，在这个例子中，没有列出可用的替代版本库。所以你所需要的对象肯定在某个包文件中。
 要检查服务端有哪些可用的包文件，你需要获取 `objects/info/packs` 文件，这里面有一个包文件列表（它也是通过执行 `update-server-info` 所生成的）：