diff --git a/C-git-commands.asc b/C-git-commands.asc index 2f498659..12c1ffb1 100644 --- a/C-git-commands.asc +++ b/C-git-commands.asc @@ -34,6 +34,40 @@ Git 做的很多工作都有一个默认方式。 最后，基本上 <> 整个章节都是针对此命令的。 +[[_core_editor]] +==== git config core.editor 命令 + +就像 <> 里的设置指示，很多编辑器可以如下设置： + +.详细的 `core.editor` 设置命令列表 +[cols="1,2",options="header"] +|============================== +|编辑器 | 设置命令 +|Atom |`git config --global core.editor "atom --wait"` +|BBEdit (Mac, with command line tools) |`git config --global core.editor "bbedit -w"` +|Emacs |git config --global core.editor emacs +|Gedit (Linux) |`git config --global core.editor "gedit --wait --new-window"` +|Gvim (Windows 64-bit) |`git config --global core.editor "'C:/Program Files/Vim/vim72/gvim.exe' --nofork '%*'"` (Also see note below) +|Kate (Linux) |`git config --global core.editor "kate"` +|nano |`git config --global core.editor "nano -w"` +|Notepad (Windows 64-bit) |`git config core.editor notepad` +|Notepad++ (Windows 64-bit) |git config --global core.editor "'C:/Program Files/Notepad++/notepad++.exe' -multiInst -notabbar -nosession -noPlugin" (Also see note below) +|Scratch (Linux)|`git config --global core.editor "scratch-text-editor"` +|Sublime Text (macOS) |`git config --global core.editor "/Applications/Sublime\ Text.app/Contents/SharedSupport/bin/subl --new-window --wait"` +|Sublime Text (Windows 64-bit) |`git config --global core.editor "'C:/Program Files/Sublime Text 3/sublime_text.exe' -w"` (Also see note below) +|Textmate |`git config --global core.editor "mate -w"` +|Textpad (Windows 64-bit) |`git config --global core.editor "'C:/Program Files/TextPad 5/TextPad.exe' -m` (Also see note below) +|Vim |`git config --global core.editor "vim"` +|VS Code |`git config --global core.editor "code --wait"` +|WordPad |`git config --global core.editor '"C:\Program Files\Windows NT\Accessories\wordpad.exe"'"` +|Xi | `git config --global core.editor "xi --wait"` +|============================== + +[NOTE] +==== +如果你在 64 位 Windows 系统上安装了 32 位的文本编辑器，它会被安装在 `C:\Program Files (x86)\` 而不是上面表格所写的 `C:\Program Files\` 。 +==== + ==== git help `git help` 命令用来显示任何命令的 Git 自带文档。 diff --git a/book/01-introduction/sections/basics.asc b/book/01-introduction/sections/basics.asc index 97f09d81..066e769a 100644 --- a/book/01-introduction/sections/basics.asc +++ b/book/01-introduction/sections/basics.asc @@ -94,7 +94,7 @@ Git 仓库目录是 Git 用来保存项目的元数据和对象数据库的地 这些从 Git 仓库的压缩数据库中提取出来的文件，放在磁盘上供你使用或修改。 暂存区域是一个文件，保存了下次将提交的文件列表信息，一般在 Git 仓库目录中。 -有时候也被称作``索引''，不过一般说法还是叫暂存区域。 +有时候也被称作“索引”，不过一般说法还是叫暂存区域。 基本的 Git 工作流程如下： diff --git a/book/02-git-basics/sections/getting-a-repository.asc b/book/02-git-basics/sections/getting-a-repository.asc index a3b243b2..845b7438 100644 --- a/book/02-git-basics/sections/getting-a-repository.asc +++ b/book/02-git-basics/sections/getting-a-repository.asc @@ -48,7 +48,7 @@ $ git commit -m 'initial project version' $ git clone https://github.com/libgit2/libgit2 ---- -这会在当前目录下创建一个名为 ``libgit2'' 的目录，并在这个目录下初始化一个 `.git` 文件夹，从远程仓库拉取下所有数据放入 `.git` 文件夹，然后从中读取最新版本的文件的拷贝。 +这会在当前目录下创建一个名为 “libgit2” 的目录，并在这个目录下初始化一个 `.git` 文件夹，从远程仓库拉取下所有数据放入 `.git` 文件夹，然后从中读取最新版本的文件的拷贝。 如果你进入到这个新建的 `libgit2` 文件夹，你会发现所有的项目文件已经在里面了，准备就绪等待后续的开发和使用。 如果你想在克隆远程仓库的时候，自定义本地仓库的名字，你可以使用如下命令： diff --git a/book/02-git-basics/sections/recording-changes.asc b/book/02-git-basics/sections/recording-changes.asc index 1280f44e..5bb8dc96 100644 --- a/book/02-git-basics/sections/recording-changes.asc +++ b/book/02-git-basics/sections/recording-changes.asc @@ -30,7 +30,7 @@ nothing to commit, working directory clean 这说明你现在的工作目录相当干净。换句话说，所有已跟踪文件在上次提交后都未被更改过。 此外，上面的信息还表明，当前目录下没有出现任何处于未跟踪状态的新文件，否则 Git 会在这里列出来。 最后，该命令还显示了当前所在分支，并告诉你这个分支同远程服务器上对应的分支没有偏离。 -现在，分支名是 ``master'',这是默认的分支名。 +现在，分支名是 “master”,这是默认的分支名。 我们在 <> 会详细讨论分支和引用。 现在，让我们在项目下创建一个新的 README 文件。 diff --git a/book/02-git-basics/sections/remotes.asc b/book/02-git-basics/sections/remotes.asc index 575c98f4..59618df9 100644 --- a/book/02-git-basics/sections/remotes.asc +++ b/book/02-git-basics/sections/remotes.asc @@ -109,7 +109,7 @@ $ git fetch [remote-name] 这个命令会访问远程仓库，从中拉取所有你还没有的数据。 执行完成后，你将会拥有那个远程仓库中所有分支的引用，可以随时合并或查看。 -如果你使用 `clone` 命令克隆了一个仓库，命令会自动将其添加为远程仓库并默认以 ``origin'' 为简写。 +如果你使用 `clone` 命令克隆了一个仓库，命令会自动将其添加为远程仓库并默认以 “origin” 为简写。 所以，`git fetch origin` 会抓取克隆（或上一次抓取）后新推送的所有工作。 必须注意 `git fetch` 命令会将数据拉取到你的本地仓库 - 它并不会自动合并或修改你当前的工作。 当准备好时你必须手动将其合并入你的工作。 diff --git a/book/02-git-basics/sections/tagging.asc b/book/02-git-basics/sections/tagging.asc index 88fdd8b1..5495fcbd 100644 --- a/book/02-git-basics/sections/tagging.asc +++ b/book/02-git-basics/sections/tagging.asc @@ -139,7 +139,7 @@ a6b4c97498bd301d84096da251c98a07c7723e65 beginning write support 8a5cbc430f1a9c3d00faaeffd07798508422908a updated readme ---- -现在，假设在 v1.2 时你忘记给项目打标签，也就是在 ``updated rakefile'' 提交。 +现在，假设在 v1.2 时你忘记给项目打标签，也就是在 “updated rakefile” 提交。 你可以在之后补上标签。 要在那个提交上打标签，你需要在命令的末尾指定提交的校验和（或部分校验和）: diff --git a/book/02-git-basics/sections/undoing.asc b/book/02-git-basics/sections/undoing.asc index b095608a..2b1d2972 100644 --- a/book/02-git-basics/sections/undoing.asc +++ b/book/02-git-basics/sections/undoing.asc @@ -52,7 +52,7 @@ Changes to be committed: modified: CONTRIBUTING.md ---- -在 ``Changes to be committed'' 文字正下方，提示使用 `git reset HEAD ...` 来取消暂存。 +在 “Changes to be committed” 文字正下方，提示使用 `git reset HEAD ...` 来取消暂存。 所以，我们可以这样来取消暂存 `CONTRIBUTING.md` 文件： [source,console] diff --git a/book/03-git-branching/sections/basic-branching-and-merging.asc b/book/03-git-branching/sections/basic-branching-and-merging.asc index 0346b227..b78a30ad 100644 --- a/book/03-git-branching/sections/basic-branching-and-merging.asc +++ b/book/03-git-branching/sections/basic-branching-and-merging.asc @@ -268,7 +268,7 @@ Normal merge conflict for 'index.html': Hit return to start merge resolution tool (opendiff): ---- -如果你想使用除默认工具（在这里 Git 使用 `opendiff` 做为默认的合并工具，因为作者在 Mac 上运行该程序）外的其他合并工具，你可以在 ``下列工具中（one of the following tools）'' 这句后面看到所有支持的合并工具。 +如果你想使用除默认工具（在这里 Git 使用 `opendiff` 做为默认的合并工具，因为作者在 Mac 上运行该程序）外的其他合并工具，你可以在 “下列工具中（one of the following tools）” 这句后面看到所有支持的合并工具。 然后输入你喜欢的工具名字就可以了。 [NOTE] diff --git a/book/03-git-branching/sections/nutshell.asc b/book/03-git-branching/sections/nutshell.asc index 02534570..649fd2e9 100644 --- a/book/03-git-branching/sections/nutshell.asc +++ b/book/03-git-branching/sections/nutshell.asc @@ -37,7 +37,7 @@ Git 的默认分支名字是 `master`。 [NOTE] ==== -Git 的 ``master'' 分支并不是一个特殊分支。(((master))) +Git 的 “master” 分支并不是一个特殊分支。(((master))) 它就跟其它分支完全没有区别。 之所以几乎每一个仓库都有 master 分支，是因为 `git init` 命令默认创建它，并且大多数人都懒得去改动它。 ==== @@ -85,7 +85,7 @@ f30ab (HEAD, master, testing) add feature #32 - ability to add new 98ca9 initial commit of my project ---- -正如你所见，当前 ``master'' 和 ``testing'' 分支均指向校验和以 `f30ab` 开头的提交对象。 +正如你所见，当前 “master” 和 “testing” 分支均指向校验和以 `f30ab` 开头的提交对象。 [[r_switching_branches]] ==== 分支切换 diff --git a/book/03-git-branching/sections/rebasing.asc b/book/03-git-branching/sections/rebasing.asc index 76b7ab2e..3eca7f71 100644 --- a/book/03-git-branching/sections/rebasing.asc +++ b/book/03-git-branching/sections/rebasing.asc @@ -183,7 +183,7 @@ image::images/perils-of-rebasing-4.png[你将相同的内容又合并了一次 如果团队中的某人强制推送并覆盖了一些你所基于的提交，你需要做的就是检查你做了哪些修改，以及他们覆盖了哪些修改。 实际上，Git 除了对整个提交计算 SHA-1 校验和以外，也对本次提交所引入的修改计算了校验和—— -即 ``patch-id''。 +即 “patch-id”。 如果你拉取被覆盖过的更新并将你手头的工作基于此进行变基的话，一般情况下 Git 都能成功分辨出哪些是你的修改，并把它们应用到新分支上。 diff --git a/book/03-git-branching/sections/remote-branches.asc b/book/03-git-branching/sections/remote-branches.asc index 8bdd9109..8d37d3fe 100644 --- a/book/03-git-branching/sections/remote-branches.asc +++ b/book/03-git-branching/sections/remote-branches.asc @@ -20,10 +20,10 @@ Git 也会给你一个与 origin 的 `master` 分支在指向同一个地方的本地 `master` 分支，这样你就有工作的基础。 [NOTE] -.``origin'' 并无特殊含义 +.“origin” 并无特殊含义 ==== -远程仓库名字 ``origin'' 与分支名字 ``master'' 一样，在 Git 中并没有任何特别的含义一样。 -同时 ``master'' 是当你运行 `git init` 时默认的起始分支名字，原因仅仅是它的广泛使用，``origin'' 是当你运行 `git clone` 时默认的远程仓库名字。 +远程仓库名字 “origin” 与分支名字 “master” 一样，在 Git 中并没有任何特别的含义一样。 +同时 “master” 是当你运行 `git init` 时默认的起始分支名字，原因仅仅是它的广泛使用，“origin” 是当你运行 `git clone` 时默认的远程仓库名字。 如果你运行 `git clone -o booyah`，那么你默认的远程分支名字将会是 `booyah/master`。(((origin))) ==== @@ -37,7 +37,7 @@ image::images/remote-branches-1.png[克隆之后的服务器与本地仓库。] image::images/remote-branches-2.png[本地与远程的工作可以分叉。] 如果要同步你的工作，运行 `git fetch origin` 命令。 -这个命令查找 ``origin'' 是哪一个服务器（在本例中，它是 `git.ourcompany.com`），从中抓取本地没有的数据，并且更新本地数据库，移动 `origin/master` 指针指向新的、更新后的位置。 +这个命令查找 “origin” 是哪一个服务器（在本例中，它是 `git.ourcompany.com`），从中抓取本地没有的数据，并且更新本地数据库，移动 `origin/master` 指针指向新的、更新后的位置。 .`git fetch` 更新你的远程仓库引用 image::images/remote-branches-3.png[`git fetch` 更新你的远程仓库引用。] @@ -80,9 +80,9 @@ To https://github.com/schacon/simplegit ---- 这里有些工作被简化了。 -Git 自动将 `serverfix` 分支名字展开为 `refs/heads/serverfix:refs/heads/serverfix`，那意味着，``推送本地的 serverfix 分支来更新远程仓库上的 serverfix 分支。'' +Git 自动将 `serverfix` 分支名字展开为 `refs/heads/serverfix:refs/heads/serverfix`，那意味着，“推送本地的 serverfix 分支来更新远程仓库上的 serverfix 分支。” 我们将会详细学习 <> 的 `refs/heads/` 部分，但是现在可以先把它放在儿。 -你也可以运行 `git push origin serverfix:serverfix`，它会做同样的事 - 相当于它说，``推送本地的 serverfix 分支，将其作为远程仓库的 serverfix 分支'' +你也可以运行 `git push origin serverfix:serverfix`，它会做同样的事——也就是说“推送本地的 serverfix 分支，将其作为远程仓库的 serverfix 分支” 可以通过这种格式来推送本地分支到一个命名不相同的远程分支。 如果并不想让远程仓库上的分支叫做 `serverfix`，可以运行 `git push origin serverfix:awesomebranch` 来将本地的 `serverfix` 分支推送到远程仓库上的 `awesomebranch` 分支。 @@ -92,7 +92,7 @@ Git 自动将 `serverfix` 分支名字展开为 `refs/heads/serverfix:refs/heads 如果你正在使用 HTTPS URL 来推送，Git 服务器会询问用户名与密码。 默认情况下它会在终端中提示服务器是否允许你进行推送。 -如果不想在每一次推送时都输入用户名与密码，你可以设置一个 ``credential cache''。 +如果不想在每一次推送时都输入用户名与密码，你可以设置一个 “credential cache”。 最简单的方式就是将其保存在内存中几分钟，可以简单地运行 `git config --global credential.helper cache` 来设置它。 想要了解更多关于不同验证缓存的可用选项，查看 <>。 @@ -130,7 +130,7 @@ Switched to a new branch 'serverfix' ==== 跟踪分支 (((branches, tracking)))(((branches, upstream))) -从一个远程跟踪分支检出一个本地分支会自动创建所谓的 ``跟踪分支''（它跟踪的分支叫做 ``上游分支''）。 +从一个远程跟踪分支检出一个本地分支会自动创建所谓的“跟踪分支”（它跟踪的分支叫做“上游分支”）。 跟踪分支是与远程分支有直接关系的本地分支。 如果在一个跟踪分支上输入 `git pull`，Git 能自动地识别去哪个服务器上抓取、合并到哪个分支。 @@ -184,7 +184,7 @@ $ git branch -vv testing 5ea463a trying something new ---- -这里可以看到 `iss53` 分支正在跟踪 `origin/iss53` 并且 ``ahead'' 是 2，意味着本地有两个提交还没有推送到服务器上。 +这里可以看到 `iss53` 分支正在跟踪 `origin/iss53` 并且 “ahead” 是 2，意味着本地有两个提交还没有推送到服务器上。 也能看到 `master` 分支正在跟踪 `origin/master` 分支并且是最新的。 接下来可以看到 `serverfix` 分支正在跟踪 `teamone` 服务器上的 `server-fix-good` 分支并且领先 3 落后 1，意味着服务器上有一次提交还没有合并入同时本地有三次提交还没有推送。 最后看到 `testing` 分支并没有跟踪任何远程分支。 diff --git a/book/04-git-server/sections/git-daemon.asc b/book/04-git-server/sections/git-daemon.asc index ad3b3e55..be8ec24b 100644 --- a/book/04-git-server/sections/git-daemon.asc +++ b/book/04-git-server/sections/git-daemon.asc @@ -1,7 +1,7 @@ === Git 守护进程 (((serving repositories, git protocol))) -接下来我们将通过 ``Git'' 协议建立一个基于守护进程的仓库。 +接下来我们将通过 “Git” 协议建立一个基于守护进程的仓库。 对于快速且无需授权的 Git 数据访问，这是一个理想之选。 请注意，因为其不包含授权服务，任何通过该协议管理的内容将在其网络上公开。 diff --git a/book/04-git-server/sections/gitlab.asc b/book/04-git-server/sections/gitlab.asc index e16e94fa..a494821a 100644 --- a/book/04-git-server/sections/gitlab.asc +++ b/book/04-git-server/sections/gitlab.asc @@ -21,18 +21,18 @@ image::images/bitnami.png[Bitnami GitLab 虚拟机登录界面。] 无论如何，跟着 GitLab 社区版的 readme 文件一步步来，你可以在这里找到它 https://gitlab.com/gitlab-org/gitlab-ce/tree/master[] 。 在这里你将会在主菜单中找到安装 GitLab 的帮助，一个可以在 Digital Ocean 上运行的虚拟机，以及 RPM 和 DEB 包（都是测试版）。 -这里还有 ``非官方'' 的引导让 GitLab 运行在非标准的操作系统和数据库上，一个全手动的安装脚本，以及许多其他的话题。 +这里还有 “非官方” 的引导让 GitLab 运行在非标准的操作系统和数据库上，一个全手动的安装脚本，以及许多其他的话题。 ==== 管理 GitLab 的管理界面是通过网络进入的。 将你的浏览器转到已经安装 GitLab 的 主机名或 IP 地址，然后以管理员身份登录即可。 默认的用户名是 `admin@local.host`，默认的密码是 `5iveL!fe`（你会得到类似 请登录后尽快更换密码 的提示）。 -登录后，点击主栏上方靠右位置的 ``Admin area'' 图标进行管理。 +登录后，点击主栏上方靠右位置的 “Admin area” 图标进行管理。 [[rgitlab_menu]] -.GitLab 主栏的 ``Admin area'' 图标。 -image::images/gitlab-menu.png[GitLab 主栏的 ``Admin area'' 图标。] +.GitLab 主栏的 “Admin area” 图标。 +image::images/gitlab-menu.png[GitLab 主栏的 “Admin area” 图标。] ===== 使用者 @@ -46,9 +46,9 @@ GitLab 上的用户指的是对应协作者的帐号。 image::images/gitlab-users.png[.GitLab 用户管理界面。] 移除一个用户有两种方法。 -``屏蔽（Blocking）'' 一个用户阻止他登录 GitLab 实例，但是该用户命名空间下的所有数据仍然会被保存，并且仍可以通过该用户提交对应的登录邮箱链接回他的个人信息页。 +“屏蔽（Blocking）” 一个用户阻止他登录 GitLab 实例，但是该用户命名空间下的所有数据仍然会被保存，并且仍可以通过该用户提交对应的登录邮箱链接回他的个人信息页。 -而另一方面，``销毁（Destroying）'' 一个用户，会彻底的将他从数据库和文件系统中移除。 +而另一方面，“销毁（Destroying）” 一个用户，会彻底的将他从数据库和文件系统中移除。 他命名空间下的所有项目和数据都会被删除，拥有的任何组也会被移除。 这显然是一个更永久且更具破坏力的行为，所以很少用到这种方法。 @@ -63,7 +63,7 @@ image::images/gitlab-users.png[.GitLab 用户管理界面。] image::images/gitlab-groups.png[GitLab组 管理界面。] 每一个组都有许多用户与之关联，每一个用户对组中的项目以及组本身的权限都有级别区分。 -权限的范围从 ``访客''（仅能提问题和讨论） 到 ``拥有者''（完全控制组、成员和项目）。 +权限的范围从 “访客”（仅能提问题和讨论） 到 “拥有者”（完全控制组、成员和项目）。 权限的种类太多以至于难以在这里一一列举，不过在 GitLab 的管理界面上有帮助链接。 ===== 项目 @@ -75,7 +75,7 @@ image::images/gitlab-groups.png[GitLab组 管理界面。] 每一个项目都有一个可视级别，控制着谁可以看到这个项目页面和仓库。 如果一个项目是 _私有_ 的，这个项目的拥有者必须明确授权从而使特定的用户可以访问。 一个 _内部_ 的项目可以被所有登录的人看到，而一个 _公开_ 的项目则是对所有人可见的。 -注意，这种控制既包括 git ``fetch'' 的使用也包括对项目 web 用户界面的访问。 +注意，这种控制既包括 git “fetch” 的使用也包括对项目 web 用户界面的访问。 ===== 钩子 @@ -86,10 +86,10 @@ GitLab 在项目和系统级别上都支持钩子程序。 ==== 基本用途 你想要在 GitLab 做的第一件事就是建立一个新项目。 -这通过点击工具栏上的 ``+'' 图标完成。 +这通过点击工具栏上的 “+” 图标完成。 你会被要求填写项目名称，也就是这个项目所属的命名空间，以及它的可视层级。 绝大多数的设定并不是永久的，可以通过设置界面重新调整。 -点击 ``Create Project''，你就完成了。 +点击 “Create Project”，你就完成了。 项目存在后，你可能会想将它与本地的 Git 版本库连接。 每一个项目都可以通过 HTTPS 或者 SSH 连接，任意两者都可以被用来配置远程 Git。 @@ -114,13 +114,13 @@ web 用户界面提供了几个有用的获取版本库信息的网页。 ==== 一起工作 在一个 GitLab 项目上一起工作的最简单方法就是赋予协作者对 git 版本库的直接 push 权限。 -你可以通过项目设定的 ``Members（成员）'' 部分向一个项目添加写作者，并且将这个新的协作者与一个访问级别关联（不同的访问级别在 <> 中已简单讨论）。 -通过赋予一个协作者 ``Developer（开发者）'' 或者更高的访问级别，这个用户就可以毫无约束地直接向版本库或者向分支进行提交。 +你可以通过项目设定的 “Members（成员）” 部分向一个项目添加写作者，并且将这个新的协作者与一个访问级别关联（不同的访问级别在 <> 中已简单讨论）。 +通过赋予一个协作者 “Developer（开发者）” 或者更高的访问级别，这个用户就可以毫无约束地直接向版本库或者向分支进行提交。 另外一个让合作更解耦的方法就是使用合并请求。 它的优点在于让任何能够看到这个项目的协作者在被管控的情况下对这个项目作出贡献。 可以直接访问的协作者能够简单的创建一个分支，向这个分支进行提交，也可以开启一个向 `master` 或者其他任何一个分支的合并请求。 -对版本库没有推送权限的协作者则可以 ``fork'' 这个版本库（即创建属于自己的这个库的副本），向 _那个_ 副本进行提交，然后从那个副本开启一个到主项目的合并请求。 +对版本库没有推送权限的协作者则可以 “fork” 这个版本库（即创建属于自己的这个库的副本），向 _那个_ 副本进行提交，然后从那个副本开启一个到主项目的合并请求。 这个模型使得项目拥有者完全控制着向版本库的提交，以及什么时候允许加入陌生协作者的贡献。 在 GitLab 中合并请求和问题是一个长久讨论的主要部分。 diff --git a/book/04-git-server/sections/smart-http.asc b/book/04-git-server/sections/smart-http.asc index c518d165..9f3d5f5c 100644 --- a/book/04-git-server/sections/smart-http.asc +++ b/book/04-git-server/sections/smart-http.asc @@ -54,7 +54,7 @@ ScriptAlias /git/ /usr/lib/git-core/git-http-backend/ ---- 这需要你创建一个包含所有合法用户密码的 `.htaccess` 文件。 -以下是一个添加 ``schacon'' 用户到此文件的例子： +以下是一个添加 “schacon” 用户到此文件的例子： [source,console] ---- diff --git a/book/05-distributed-git/sections/contributing.asc b/book/05-distributed-git/sections/contributing.asc index f5262889..d8576fb1 100644 --- a/book/05-distributed-git/sections/contributing.asc +++ b/book/05-distributed-git/sections/contributing.asc @@ -60,7 +60,7 @@ image::images/git-diff-check.png[`git diff --check` 的输出。] Git 项目要求一个更详细的解释，包括做改动的动机和它的实现与之前行为的对比 - 这是一个值得遵循的好规则。 在这些信息中使用现在时态祈使语气也是一个好想法。 换句话说，使用命令。 -使用 ``Add tests for.'' 而不是 ``I added tests for'' 或 ``Adding tests for,''。 +使用 “Add tests for” 而不是 “I added tests for” 或 “Adding tests for”。 这里是一份最初由 Tim Pope 写的模板： [source,text] @@ -95,7 +95,7 @@ Git 项目有一个良好格式化的提交信息 - 尝试在那儿运行 `git l (((contributing, private small team))) 你可能会遇到的最简单的配置是有一两个其他开发者的私有项目。 -``私有'' 在这个上下文中，意味着闭源 - 不可以从外面的世界中访问到。 +“私有” 在这个上下文中，意味着闭源 - 不可以从外面的世界中访问到。 你和其他的开发者都有仓库的推送权限。 在这个环境下，可以采用一个类似使用 Subversion 或其他集中式的系统时会使用的工作流程。 @@ -510,7 +510,7 @@ $ git commit 你可能会想要使用 `rebase -i` 来将工作压缩成一个单独的提交，或者重排提交中的工作使补丁更容易被维护者审核 - 查看 <> 了解关于交互式变基的更多信息。 ==== -当你的分支工作完成后准备将其贡献回维护者，去原始项目中然后点击 ``Fork'' 按钮，创建一份自己的可写的项目派生仓库。 +当你的分支工作完成后准备将其贡献回维护者，去原始项目中然后点击 “Fork” 按钮，创建一份自己的可写的项目派生仓库。 然后需要添加这个新仓库 URL 为第二个远程仓库，在本例中称作 `myfork`： [source,console] @@ -688,7 +688,7 @@ index 76f47bc..f9815f1 100644 如果在 `---` 行与补丁开头（`diff --git` 行）之间添加文本，那么开发者就可以阅读它；但是应用补丁时会排除它。 为了将其邮寄到邮件列表，你既可以将文件粘贴进电子邮件客户端，也可以通过命令行程序发送它。 -粘贴文本经常会发生格式化问题，特别是那些不会合适地保留换行符与其他空白的 ``更聪明的'' 客户端。 +粘贴文本经常会发生格式化问题，特别是那些不会合适地保留换行符与其他空白的 “更聪明的” 客户端。 幸运的是，Git 提供了一个工具帮助你通过 IMAP 发送正确格式化的补丁，这可能对你更容易些。 我们将会演示如何通过 Gmail 发送一个补丁，它正好是我们所知最好的邮件代理；可以在之前提到的 Git 源代码中的 `Documentation/SubmittingPatches` 文件的最下面了解一系列邮件程序的详细指令。 diff --git a/book/05-distributed-git/sections/distributed-workflows.asc b/book/05-distributed-git/sections/distributed-workflows.asc index 12f37f65..aba41b4f 100644 --- a/book/05-distributed-git/sections/distributed-workflows.asc +++ b/book/05-distributed-git/sections/distributed-workflows.asc @@ -37,7 +37,7 @@ John 完成了他的修改并推送到服务器。 (((workflows, integration manager))) Git 允许多个远程仓库存在，使得这样一种工作流成为可能：每个开发者拥有自己仓库的写权限和其他所有人仓库的读权限。 -这种情形下通常会有个代表``官方''项目的权威的仓库。 +这种情形下通常会有个代表“官方”项目的权威的仓库。 要为这个项目做贡献，你需要从该项目克隆出一个自己的公开仓库，然后将自己的修改推送上去。 接着你可以请求官方仓库的维护者拉取更新合并到主项目。 维护者可以将你的仓库作为远程仓库添加进来，在本地测试你的变更，将其合并入他们的分支并推送回官方仓库。 diff --git a/book/06-github/sections/1-setting-up-account.asc b/book/06-github/sections/1-setting-up-account.asc index 425deb25..ef0ae065 100644 --- a/book/06-github/sections/1-setting-up-account.asc +++ b/book/06-github/sections/1-setting-up-account.asc @@ -2,7 +2,7 @@ (((GitHub, user accounts))) 你所需要做的第一件事是创建一个免费账户。 -直接访问 https://github.com[]，选择一个未被占用的用户名，提供一个电子邮件地址和密码，点击写着``Sign up for GitHub''的绿色大按钮即可。 +直接访问 https://github.com[]，选择一个未被占用的用户名，提供一个电子邮件地址和密码，点击写着“Sign up for GitHub”的绿色大按钮即可。 .GitHub 注册表单。 image::images/signup.png[GitHub 注册表单。] @@ -30,15 +30,15 @@ GitHub 的付费计划可以让你拥有一定数目的私有项目，不过本 （如果你没有公钥，参考 <>。） 使用窗口右上角的链接打开你的账户设置： -.``Account settings''链接。 -image::images/account-settings.png[``Account settings''链接。] +.“Account settings”链接。 +image::images/account-settings.png[“Account settings”链接。] -然后在左侧选择``SSH keys''部分。 +然后在左侧选择“SSH keys”部分。 -.``SSH keys''链接。 -image::images/ssh-keys.png[``SSH keys''链接。] +.“SSH keys”链接。 +image::images/ssh-keys.png[“SSH keys”链接。] -在这个页面点击“`Add an SSH key`”按钮，给你的公钥起一个名字，将你的 `~/.ssh/id_rsa.pub` （或者自定义的其它名字）公钥文件的内容粘贴到文本区，然后点击``Add key''。 +在这个页面点击“`Add an SSH key`”按钮，给你的公钥起一个名字，将你的 `~/.ssh/id_rsa.pub` （或者自定义的其它名字）公钥文件的内容粘贴到文本区，然后点击“Add key”。 [NOTE] ==== @@ -50,10 +50,10 @@ image::images/ssh-keys.png[``SSH keys''链接。] ==== 头像 下一步，如果愿意的话，你可以将生成的头像换成你喜欢的图片。 -首先，来到``Profile''标签页（在``SSH Keys''标签页上方），点击``Upload new picture''。 +首先，来到“Profile”标签页（在“SSH Keys”标签页上方），点击“Upload new picture”。 -.``Profile''链接。 -image::images/your-profile.png[``Profile''链接。] +.“Profile”链接。 +image::images/your-profile.png[“Profile”链接。] 我们选择了本地磁盘上的一个 Git 图标，上传之后还可以对其进行裁剪。 @@ -81,7 +81,7 @@ image::images/email-settings.png[添加所有邮件地址。] ==== 两步验证 -最后，为了额外的安全性，你绝对应当设置两步验证，简写为 ``2FA''。 +最后，为了额外的安全性，你绝对应当设置两步验证，简写为 “2FA”。 两步验证是一种用于降低因你的密码被盗而带来的账户风险的验证机制，现在已经变得越来越流行。 开启两步验证，GitHub 会要求你用两种不同的验证方法，这样，即使其中一个被攻破，攻击者也不能访问你的账户。 @@ -90,6 +90,6 @@ image::images/email-settings.png[添加所有邮件地址。] .Security 标签页中的 2FA image::images/2fa-1.png[Security 标签页中的 2FA] -点击``Set up two-factor authentication''按钮，会跳转到设置页面。该页面允许你选择是要在登录时使用手机 app 生成辅助码（一种``基于时间的一次性密码''），还是要 GitHub 通过 SMS 发送辅助码。 +点击“Set up two-factor authentication”按钮，会跳转到设置页面。该页面允许你选择是要在登录时使用手机 app 生成辅助码（一种“基于时间的一次性密码”），还是要 GitHub 通过 SMS 发送辅助码。 选择合适的方法后，按照提示步骤设置 2FA，你的账户会变得更安全，每次登录 GitHub 时都需要提供除密码以外的辅助码。 diff --git a/book/06-github/sections/3-maintaining.asc b/book/06-github/sections/3-maintaining.asc index 4e29f4c9..8d3b1a4b 100644 --- a/book/06-github/sections/3-maintaining.asc +++ b/book/06-github/sections/3-maintaining.asc @@ -8,20 +8,20 @@ 让我们创建一个版本库来分享我们的项目。 通过点击面板右侧的“New repository”按钮，或者顶部工具条你用户名旁边的 `+` 按钮来开始我们的旅程。 参见 <>。 -.这是 ``Your repositories''区域. -image::images/newrepo.png[``Your repositories'' 区域.] +.这是 “Your repositories” 区域. +image::images/newrepo.png[“Your repositories” 区域.] [[r_new_repo_dropdown]] -.这是 ``New repository'' 下拉列表. -image::images/new-repo.png[``new repository'' 下拉列表.] +.这是 “New repository” 下拉列表. +image::images/new-repo.png[“new repository” 下拉列表.] -这会带你到 ``new repository'' 表单: +这会带你到 “new repository” 表单: -.这是 ``new repository'' 表单. -image::images/newrepoform.png[``new repository'' 表单。] +.这是 “new repository” 表单. +image::images/newrepoform.png[“new repository” 表单。] 这里除了一个你必须要填的项目名，其他字段都是可选的。 -现在只需要点击 ``Create Repository'' 按钮，Duang!!! – 你就在 GitHub 上拥有了一个以 `/` 命名的新仓库了。 +现在只需要点击 “Create Repository” 按钮，Duang!!! – 你就在 GitHub 上拥有了一个以 `/` 命名的新仓库了。 因为目前暂无代码，GitHub 会显示有关创建新版本库或者关联到一个已有的 Git 版本库的一些说明。 我们不会在这里详细说明此项，如果你需要复习，去看 <>。 @@ -39,19 +39,19 @@ HTTP URL 与你贴到浏览器里查看项目用的地址是一样的。 ==== 添加合作者 -如果你想与他人合作，并想给他们提交的权限，你需要把他们添加为 ``Collaborators''。 +如果你想与他人合作，并想给他们提交的权限，你需要把他们添加为 “Collaborators”。 如果 Ben，Jeff，Louise 都在 GitHub 上注册了，你想给他们推送的权限，你可以将他们添加到你的项目。 -这样做会给他们 ``推送'' 权限，就是说他们对项目和 Git 版本库都有读写的权限。 +这样做会给他们 “推送” 权限，就是说他们对项目和 Git 版本库都有读写的权限。 -点击边栏底部的 ``Settings'' 链接。 +点击边栏底部的 “Settings” 链接。 .版本库设置链接. image::images/reposettingslink.png[版本库设置链接.] -然后从左侧菜单中选择 ``Collaborators'' 。 -然后，在输入框中填写用户名，点击 ``Add collaborator.'' +然后从左侧菜单中选择 “Collaborators” 。 +然后，在输入框中填写用户名，点击 “Add collaborator.” 如果你想授权给多个人，你可以多次重复这个步骤。 -如果你想收回权限，点击他们同一行右侧的 ``X'' +如果你想收回权限，点击他们同一行右侧的 “X” .版本库合作者. image::images/collaborators.png[版本库合作者.] @@ -63,7 +63,7 @@ image::images/collaborators.png[版本库合作者.] 合并请求可以来自仓库副本的一个分支，或者同一仓库的另一个分支。 唯一的区别是 fork 过来的通常是和你不能互相推送的人，而内部的推送通常都可以互相访问。 -作为例子，假设你是 ``tonychacon'' ，你创建了一个名为 ``fade'' 的 Arduino 项目. +作为例子，假设你是 “tonychacon” ，你创建了一个名为 “fade” 的 Arduino 项目. [[r_email_notifications]] ===== 邮件通知 @@ -105,8 +105,8 @@ image::images/maint-03-email-resp.png[邮件回复] 一旦代码符合了你的要求，你想把它合并进来，你可以把代码拉取下来在本地进行合并，也可以用我们之前提到过的 `git pull ` 语法，或者把 fork 添加为一个 remote，然后进行抓取和合并。 -对于很琐碎的合并，你也可以用 GitHub 网站上的 ``Merge'' 按钮。 -它会做一个 ``non-fast-forward'' 合并，即使可以快进（fast-forward）合并也会产生一个合并提交记录。 +对于很琐碎的合并，你也可以用 GitHub 网站上的 “Merge” 按钮。 +它会做一个 “non-fast-forward” 合并，即使可以快进（fast-forward）合并也会产生一个合并提交记录。 就是说无论如何，只要你点击 merge 按钮，就会产生一个合并提交记录。 你可以在 <> 看到，如果你点击提示链接，GitHub 会给你所有的这些信息。 @@ -128,7 +128,7 @@ image::images/maint-02-merge.png[合并按钮] 为了展示这个，我们要用到一个叫做 `ls-remote` 的低级命令（通常被叫做“plumbing”，我们会在 <> 读到更多相关内容）。 这个命令在日常 Git 操作中基本不会用到，但在显示服务器上有哪些引用（reference）时很管用。 -如果在我们之前用过的 ``blink'' 版本库上使用这个命令，我们会得到一个版本库里所有的分支，标签和其它引用（reference）的列表。 +如果在我们之前用过的 “blink” 版本库上使用这个命令，我们会得到一个版本库里所有的分支，标签和其它引用（reference）的列表。 [source,console] ---- @@ -176,7 +176,7 @@ Git 高高兴兴去执行，下载构建那个引用需要的所有内容，然 fetch = +refs/heads/*:refs/remotes/origin/* ---- -以 `fetch =` 开头的行是一个 ``refspec.'' +以 `fetch =` 开头的行是一个 “refspec.” 它是一种把 remote 的名称映射到你本地 `.git` 目录的方法。 这一条（就是上面的这一条）告诉 Git，“remote 上 `refs/heads` 下面的内容在我本地版本库中都放在 `refs/remotes/origin` 。” 你可以把这一段修改一下，添加另一个 refspec： @@ -213,7 +213,7 @@ Switched to a new branch 'pr/2' ---- 你的鹰眼系统会发现在 refspec 的 remote 部分的结尾有个 `head` 。 -在 GitHub 那边也有一个 `refs/pull/#/merge` 引用，它代表的是如果你在网站上按了 ``merge'' 按钮对应的提交记录。 +在 GitHub 那边也有一个 `refs/pull/#/merge` 引用，它代表的是如果你在网站上按了 “merge” 按钮对应的提交记录。 这甚至让你可以在按按钮之前就测试这个合并。 @@ -225,7 +225,7 @@ Switched to a new branch 'pr/2' 如果你看到一个合并请求在向正确的方向发展，然后你想在这个合并请求上做一些修改或者你不太确定这是个好主意，或者你没有目标分支的推送权限，你可以直接在合并请求上开启一个合并请求。 当你开启一个合并请求时，在页面的顶端有一个框框显示你要合并到哪个分支和你从哪个分支合并过来的。 -如果你点击那个框框右边的 ``Edit'' 按钮，你不仅可以改变分支，还可以选择哪个 fork。 +如果你点击那个框框右边的 “Edit” 按钮，你不仅可以改变分支，还可以选择哪个 fork。 [[r_pr_targets]] .手工修改合并请求的目标. @@ -248,22 +248,22 @@ image::images/maint-05-mentions.png[提醒] 这意味着把人们拉进会话中要比让他们投票有效率得多。 对于 GitHub 上的合并请求，人们经常把他们团队或公司中的其它人拉来审查问题或合并请求。 -如果有人收到了合并请求或问题的提醒，他们会＂订阅＂它，后面有新的活动发生他们都会持续收到提醒。 +如果有人收到了合并请求或问题的提醒，他们会“订阅”它，后面有新的活动发生他们都会持续收到提醒。 如果你是合并请求或者问题的发起方你也会被订阅上，比如你在关注一个版本库或者你评论了什么东西。 -如果你不想再收到提醒，在页面上有个 ``Unsubscribe'' 按钮，点一下就不会再收到更新了。 +如果你不想再收到提醒，在页面上有个 “Unsubscribe” 按钮，点一下就不会再收到更新了。 .取消订阅一个问题或合并请求. image::images/maint-06-unsubscribe.png[取消订阅] ==== 通知页面 -当我们在这提到特指 GitHub 的 ``notifications'' ，指的是当 GitHub 上有事件发生时，它通知你的方式，这里有几种不同的方式来配置它们。 -如果你打开配置页面的 ``Notification center'' 标签，你可以看到一些选项。 +当我们在这提到特指 GitHub 的 “notifications” ，指的是当 GitHub 上有事件发生时，它通知你的方式，这里有几种不同的方式来配置它们。 +如果你打开配置页面的 “Notification center” 标签，你可以看到一些选项。 .通知中心选项. image::images/maint-07-notifications.png[通知中心] -有两个选项，通过＂邮件(Email)＂和通过＂网页(Web)＂，你可以选用一个或者都不选或者都选。 +有两个选项，通过“邮件(Email)”和通过“网页(Web)”，你可以选用一个或者都不选或者都选。 ==== 网页通知 @@ -308,10 +308,10 @@ X-GitHub-Recipient-Address: tchacon@example.com 这里有一些有趣的东西。 如果你想高亮或者转发这个项目甚至这个合并请求相关的邮件，`Message-ID` 中的信息会以 `///` 的格式展现所有的数据。 -例如，如果这是一个问题(issue)，那么 `` 字段就会是 ``issues'' 而不是 ``pull'' 。 +例如，如果这是一个问题(issue)，那么 `` 字段就会是 “issues” 而不是 “pull” 。 `List-Post` 和 `List-Unsubscribe` 字段表示如果你的邮件客户端能够处理这些，那么你可以很容易地在列表中发贴或取消对这个相关帖子的订阅。 -那会很有效率，就像在页面中点击静音按钮或在问题／合并请求页面点击 ``Unsubscribe'' 一样。 +那会很有效率，就像在页面中点击静音按钮或在问题／合并请求页面点击 “Unsubscribe” 一样。 值得注意的是，如果你同时打开了邮件和网页通知，那么当你在邮件客户端允许加载图片的情况下阅读邮件通知时，对应的网页通知也将会同时被标记为已读。 @@ -354,7 +354,7 @@ image::images/maint-09-contrib.png[贡献注意事项] ===== 改变默认分支 -如果你想用 ``master'' 之外的分支作为你的默认分支，其他人将默认会在这个分支上开启合并请求或进行浏览，你可以在你版本库的设置页面的 "options" 标签下修改。 +如果你想用 “master” 之外的分支作为你的默认分支，其他人将默认会在这个分支上开启合并请求或进行浏览，你可以在你版本库的设置页面的 "options" 标签下修改。 [[r_default_branch]] .改变项目的默认分支. @@ -364,7 +364,7 @@ image::images/maint-10-default-branch.png[默认分支] ===== 移交项目 -如果你想把一个项目移交给 GitHub 中的另一个人或另一个组织，还是设置页面的这个 ＂options＂标签下有一个 ``Transfer ownership'' 选项可以用来干这个。 +如果你想把一个项目移交给 GitHub 中的另一个人或另一个组织，还是设置页面的这个 “options” 标签下有一个 “Transfer ownership” 选项可以用来干这个。 [[r_transfer_project]] .把项目移交给另一个 GitHub 用户或组织。 diff --git a/book/06-github/sections/4-managing-organization.asc b/book/06-github/sections/4-managing-organization.asc index b4db8998..6d29da4a 100644 --- a/book/06-github/sections/4-managing-organization.asc +++ b/book/06-github/sections/4-managing-organization.asc @@ -11,8 +11,8 @@ 我们可以很简单地创建一个组织，只需要点击任意 GitHub 页面右上角的“+”图标，在菜单中选择“New organization”即可。 -.``New organization''菜单项 -image::images/neworg.png[``New organization''菜单项] +.“New organization”菜单项 +image::images/neworg.png[“New organization”菜单项] 首先你必须提供组织的名称和组织的主要联系邮箱。 然后，如果你希望的话，也可以邀请其他用户作为共同拥有人。 diff --git a/book/06-github/sections/5-scripting.asc b/book/06-github/sections/5-scripting.asc index c8e85c3d..20f686ff 100644 --- a/book/06-github/sections/5-scripting.asc +++ b/book/06-github/sections/5-scripting.asc @@ -13,7 +13,7 @@ GitHub 仓库管理中的钩子与服务区块是 GitHub 与外部系统交互 首先我们来看一下服务。 钩子与服务整合都可以在仓库的设置区块中找到，就在我们之前添加协作者与改变项目的默认分支的地方。 -在 ``Webhooks and Services'' 标签下你会看到与 <> 类似的内容。 +在 “Webhooks and Services” 标签下你会看到与 <> 类似的内容。 [[r_services_hooks]] .服务与钩子配置区域 @@ -22,13 +22,13 @@ image::images/scripting-01-services.png[服务与钩子] 有许多可以选择的服务，大多数是整合到其他的商业与开源系统中。 它们中的大多数是为了整合持续集成服务、BUG 与问题追踪系统、聊天室系统与文档系统。 我们将会通过设置一个非常简单的例子来介绍。 -如果从 ``Add Service'' 选择 ``email''，会得到一个类似 <> 的配置屏幕。 +如果从 “Add Service” 选择 “email”，会得到一个类似 <> 的配置屏幕。 [[r_service_config]] .电子邮件服务配置 image::images/scripting-02-email-service.png[电子邮件服务] -在本例中，如果我们点击 ``Add service'' 按钮，每次有人推送内容到仓库时，指定的电子邮件地址都会收到一封邮件。 +在本例中，如果我们点击 “Add service” 按钮，每次有人推送内容到仓库时，指定的电子邮件地址都会收到一封邮件。 服务可以监听许多不同类型的事件，但是大多数只监听推送事件然后使用那些数据做一些事情。 如果有一个正在使用的系统想要整合到 GitHub，应当先检查这里看有没有已有的可用的服务整合。 @@ -42,7 +42,7 @@ GitHub 仓库钩子是非常简单的。 通常做这件事的方式是可以设置一个小的 web 服务来监听 GitHub 钩子请求然后使用收到的数据做一些事情。 -为了启用一个钩子，点击 <> 中的 ``Add webhook'' 按钮。 +为了启用一个钩子，点击 <> 中的 “Add webhook” 按钮。 这会将你引导至一个类似 <> 的页面。 [[r_web_hook]] @@ -50,7 +50,7 @@ GitHub 仓库钩子是非常简单的。 image::images/scripting-03-webhook.png[Web 钩子配置] Web 钩子的设置非常简单。 -大多数情况下只需要输入一个 URL 与一个密钥然后点击 ``Add webhook''。 +大多数情况下只需要输入一个 URL 与一个密钥然后点击 “Add webhook”。 有几个选项可以指定在哪个事件时想要 GitHub 发送请求 -- 默认的行为是只有当某人推送新代码到仓库的任一分支时的 `push` 事件获得一个请求。 让我们看一个设置处理 web 钩子的 web 服务的小例子。 @@ -122,7 +122,7 @@ image::images/scripting-04-webhook-debug.png[Web 钩子调试信息] 可以做的最基本的事情是向一个不需要授权的接口上发送一个简单的 GET 请求。 该接口可能是一个用户或开源项目的只读信息。 -例如，如果我们想要知道更多关于名为 ``schacon'' 的用户信息，我们可以运行类似下面的东西： +例如，如果我们想要知道更多关于名为 “schacon” 的用户信息，我们可以运行类似下面的东西： [source,javascript] ---- @@ -171,10 +171,10 @@ hs_err_pid* 这里提供了几种授权方式。 你可以使用仅需用户名与密码的基本授权，但是通常更好的主意是使用一个个人访问令牌。 -可以从设置页的 ``Applications'' 标签生成访问令牌。 +可以从设置页的 “Applications” 标签生成访问令牌。 [[r_access_token]] -.从设置页的 ``Applications'' 标签生成访问令牌。 +.从设置页的 “Applications” 标签生成访问令牌。 image::images/scripting-05-access-token.png[访问令牌] 它会询问这个令牌的作用域与一个描述。 @@ -278,8 +278,8 @@ end 希望这相当容易做。 在这个 web 钩子处理器中我们浏览刚刚推送上来的每一个提交，在提交信息中查找字符串 'Signed-off-by' 并且最终使用 HTTP 向 `/repos///statuses/` API 接口发送一个带有状态的 POST 请求。 -在本例中可以发送一个状态（'success', 'failure', 'error'）、一个发生了什么的描述信息、一个用户可以了解更多信息的目标 URL 与一个 ``context'' 以防一个单独的提交有多个状态。 -例如，一个测试服务可以提供一个状态与一个类似这样的验证服务也可能提供一个状态 -- ``context'' 字段是用来区别它们的。 +在本例中可以发送一个状态（'success', 'failure', 'error'）、一个发生了什么的描述信息、一个用户可以了解更多信息的目标 URL 与一个 “context” 以防一个单独的提交有多个状态。 +例如，一个测试服务可以提供一个状态与一个类似这样的验证服务也可能提供一个状态 -- “context” 字段是用来区别它们的。 如果某人在 GitHub 中打开了一个新的 Pull Request 并且这个钩子已经设置，会看到类似 <> 的信息。 @@ -287,7 +287,7 @@ end .通过 API 的提交状态 image::images/scripting-07-status.png[提交状态] -现在可以看到一个小的绿色对勾标记在提交信息中有 ``Signed-off-by'' 的提交旁边，红色的对勾标记在作者忘记签名的提交旁边。 +现在可以看到一个小的绿色对勾标记在提交信息中有 “Signed-off-by” 的提交旁边，红色的对勾标记在作者忘记签名的提交旁边。 也可以看到 Pull Request 显示在那个分支上的最后提交的状态，如果失败的话会警告你。 如果对测试结果使用这个 API 那么就不会不小心合并某些未通过测试的最新提交。 diff --git a/book/07-git-tools/sections/bundling.asc b/book/07-git-tools/sections/bundling.asc index 43ac8478..21918ea9 100644 --- a/book/07-git-tools/sections/bundling.asc +++ b/book/07-git-tools/sections/bundling.asc @@ -3,7 +3,7 @@ 虽然我们已经了解了网络传输 Git 数据的常用方法（如 HTTP，SSH 等），但还有另外一种不太常见却又十分有用的方式。 -Git 可以将它的数据 ``打包'' 到一个文件中。 +Git 可以将它的数据“打包”到一个文件中。 这在许多场景中都很有用。 有可能你的网络中断了，但你又希望将你的提交传给你的合作者们。 可能你不在办公网中并且出于安全考虑没有给你接入内网的权限。 diff --git a/book/07-git-tools/sections/searching.asc b/book/07-git-tools/sections/searching.asc index 7a073470..6bc95a48 100644 --- a/book/07-git-tools/sections/searching.asc +++ b/book/07-git-tools/sections/searching.asc @@ -57,7 +57,7 @@ date.c: if (gmtime_r(&time, tm)) { 在这里我们可以看到在 date.c 文件中有 `match_multi_number` 和 `match_digit` 两个函数调用了 `gmtime_r`。 你还可以使用 `--and` 标志来查看复杂的字符串组合，也就是在同一行同时包含多个匹配。 -比如，我们要查看在旧版本 1.8.0 的 Git 代码库中定义了常量名包含 ``LINK'' 或者 ``BUF_MAX'' 这两个字符串所在的行。 +比如，我们要查看在旧版本 1.8.0 的 Git 代码库中定义了常量名包含 “LINK” 或者 “BUF_MAX” 这两个字符串所在的行。 这里我们也用到了 `--break` 和 `--heading` 选项来使输出更加容易阅读。 diff --git a/book/07-git-tools/sections/stashing-cleaning.asc b/book/07-git-tools/sections/stashing-cleaning.asc index 1a509e21..28e8cbae 100644 --- a/book/07-git-tools/sections/stashing-cleaning.asc +++ b/book/07-git-tools/sections/stashing-cleaning.asc @@ -225,7 +225,7 @@ Dropped refs/stash@{0} (f0dfc4d5dc332d1cee34a634182e168c4efc3359) 使用 `git clean -f -d` 命令来移除工作目录中所有未追踪的文件以及空的子目录。 `-f` 意味着 '强制' 或 “确定移除”。 -如果只是想要看看它会做什么，可以使用 `-n` 选项来运行命令，这意味着 ``做一次演习然后告诉你 _将要_ 移除什么''。 +如果只是想要看看它会做什么，可以使用 `-n` 选项来运行命令，这意味着 “做一次演习然后告诉你 _将要_ 移除什么”。 [source,console] ---- @@ -256,7 +256,7 @@ Would remove tmp/ ---- 如果不知道 `git clean` 命令将会做什么，在将 `-n` 改为 `-f` 来真正做之前总是先用 `-n` 来运行它做双重检查。 -另一个小心处理过程的方式是使用 `-i` 或 ``interactive'' 标记来运行它。 +另一个小心处理过程的方式是使用 `-i` 或 “interactive” 标记来运行它。 这将会以交互模式运行 clean 命令。 diff --git a/book/A-git-in-other-environments/sections/guis.asc b/book/A-git-in-other-environments/sections/guis.asc index 3dbd2488..d02a6b35 100644 --- a/book/A-git-in-other-environments/sections/guis.asc +++ b/book/A-git-in-other-environments/sections/guis.asc @@ -7,7 +7,7 @@ Git 的原生环境是终端。 有一点请注意，不同的界面是为不同的工作流程设计的。 一些客户端的作者为了支持某种他认为高效的工作流程，经过精心挑选，只显示了 Git 功能的一个子集。 -每种工具都有其特定的目的和意义，从这个角度来看，不能说某种工具比其它的``更好''。 +每种工具都有其特定的目的和意义，从这个角度来看，不能说某种工具比其它的“更好”。 还有请注意，没有什么事情是图形界面客户端可以做而命令行客户端不能做的；命令行始终是你可以完全操控仓库并发挥出全部力量的地方。 ==== `gitk` 和 `git-gui` @@ -59,9 +59,9 @@ image::images/git-gui.png[`git-gui` 提交工具。] 你可以通过右击某一区块或行从而将这一区块或行放入暂存区。 右侧窗口的下方是写日志和执行操作的地方。 -在文本框中键入日志然后点击 ``提交'' 就和执行 `git commit` 的效果差不多。 -如果你想要修订上一次提交, 可以选中``修订'' 按钮，上次一提交的内容就会显示在 ``暂存区''。 -然后你就可以简单的对修改进行暂存和取消暂存操作，更新提交日志，然后再次点击 ``提交'' 用这个新的提交来覆盖上一次提交。 +在文本框中键入日志然后点击“提交”就和执行 `git commit` 的效果差不多。 +如果你想要修订上一次提交, 可以选中“修订”按钮，上次一提交的内容就会显示在“暂存区”。 +然后你就可以简单的对修改进行暂存和取消暂存操作，更新提交日志，然后再次点击“提交”用这个新的提交来覆盖上一次提交。 `gitk` 和 `git-gui` 就是针对某种任务设计的工具的两个例子。 它们分别为了不同的目的（即查看历史和制作提交）而进行了精简，略去了用不到的功能。 @@ -81,13 +81,13 @@ image::images/github_mac.png[GitHub Mac 客户端。] image::images/github_win.png[GitHub Windows 客户端。] 我们在设计的时候就努力将二者的外观和操作体验都保持一致，因此本章会把他们当做同一个产品来介绍。 -我们并不会详细地介绍该工具的每一个功能（因为它们本身也有文档），但请快速了解一下 ``变更'' 窗口（你大部分时间都会花在使用该窗口上）的以下几点： +我们并不会详细地介绍该工具的每一个功能（因为它们本身也有文档），但请快速了解一下“变更”窗口（你大部分时间都会花在使用该窗口上）的以下几点： -* 左侧是正在追踪的仓库的列表；通过点击左上方的 ``+'' 图标，你可以添加一个需要追踪的仓库（既可以是通过 clone，也可以从本地添加）。 +* 左侧是正在追踪的仓库的列表；通过点击左上方的 “+” 图标，你可以添加一个需要追踪的仓库（既可以是通过 clone，也可以从本地添加）。 * 中间是输入-提交区，你可以在这里输入提交日志，以及选择哪些文件需要被提交。 （在 Windows 上，提交历史就显示在这个区域的下方；在 Mac 上，提交历史有一个单独的窗口） * 右侧是修改查看区，它会告诉你工作目录里哪些东西被修改了（译注：修改模式），或选中的提交里包括了哪些修改（译注：历史模式）。 -* 最后需要熟悉的是右上角的 ``Sync'' 按钮，你主要通过这个按钮来进行网络上的交互。 +* 最后需要熟悉的是右上角的 “Sync” 按钮，你主要通过这个按钮来进行网络上的交互。 [NOTE] ==== @@ -100,7 +100,7 @@ image::images/github_win.png[GitHub Windows 客户端。] GitHub 的 Windows 客户端可以从 https://windows.github.com[] 下载，Mac 客户端可以从 https://mac.github.com[]下载。 第一次打开软件时，它会引导你进行一系列的首次使用设置，例如设置你的姓名和电子邮件，它还会智能地帮你调整一些常用的默认设置，例如凭证缓存和 CRLF 的处理方式。 -它们都是``绿色软件''——如果软件打开发现有更新，下载和安装升级包都是在后台完成的。 +它们都是“绿色软件”——如果软件打开发现有更新，下载和安装升级包都是在后台完成的。 为方便起见它们还打包了一份 Git，也就是说你一旦安装好就再也无需劳心升级的事情了。 Windows 的客户端还提供了快捷方式，可以启动装了 Posh-git 插件的 Powershell，在本章的后面一节我们会详细介绍这方面的内容。 @@ -111,14 +111,14 @@ Windows 的客户端还提供了快捷方式，可以启动装了 Posh-git 插 ===== 推荐的工作流程 安装并配置好以后，你就可以使用 GitHub 客户端来执行一些常见的 Git 任务。 -该工具所推荐的工作流程有时也被叫做 ``GitHub 流''。 +该工具所推荐的工作流程有时也被叫做 “GitHub 流”。 我们在 <> 一节中对此有详细的介绍，其要点是 (a) 你会提交到一个分支；(b) 你需要经常与远程仓库保持同步。 两个平台上的客户端在分支管理上有所不同。 在 Mac 上，创建分支的按钮在窗口的上方： -.Mac 上的``创建分支''按钮。 -image::images/branch_widget_mac.png[Mac 上的``创建分支''按钮。] +.Mac 上的“创建分支”按钮。 +image::images/branch_widget_mac.png[Mac 上的“创建分支”按钮。] 在 Windows 上，你可以通过在分支切换挂件中输入新分支的名称来完成创建： @@ -127,9 +127,9 @@ image::images/branch_widget_win.png[在 Windows 上创建分支。] 分支创建好以后，新建提交就变得非常简单直接了。 现在工作目录中做一些修改，然后切换到 GitHub 客户端窗口，你所做的修改就会显示在那里。 -输入提交日志，选中那些需要被包含在本次提交中的文件，然后点击 ``提交'' 按钮（也可以在键盘上按 ctrl-enter 或 ⌘-enter）。 +输入提交日志，选中那些需要被包含在本次提交中的文件，然后点击“提交”按钮（也可以在键盘上按 ctrl-enter 或 ⌘-enter）。 -``同步'' 功能是你在网络上和其它仓库交互的主要途径。 +“同步”功能是你在网络上和其它仓库交互的主要途径。 push，fetch，merge，和 rebase 在 Git 内部是一连串独立的操作, 而 GitHub 客户端将这些操作都合并成了单独一个功能。 你点击同步按钮时实际上会发生如下这些操作： diff --git a/book/B-embedding-git/sections/jgit.asc b/book/B-embedding-git/sections/jgit.asc index 850534ae..4dd3da6f 100644 --- a/book/B-embedding-git/sections/jgit.asc +++ b/book/B-embedding-git/sections/jgit.asc @@ -93,7 +93,7 @@ String name = cfg.getString("user", null, "name"); 第一行获取一个指向 `master` 引用的指针。 JGit 自动抓取位于 `refs/heads/master` 的 _真正的_ master 引用，并返回一个允许你获取该引用的信息的对象。 你可以获取它的名字 （`.getName()`） ，或者一个直接引用的目标对象 （`.getObjectId()`） ，或者一个指向该引用的符号指针 （`.getTarget()`） 。 -引用对象也经常被用来表示标签的引用和对象，所以你可以询问某个标签是否被 ``削除'' 了，或者说它指向一个标签对象的（也许很长的）字符串的最终目标。 +引用对象也经常被用来表示标签的引用和对象，所以你可以询问某个标签是否被“削除”了，或者说它指向一个标签对象的（也许很长的）字符串的最终目标。 第二行获得以 `master` 引用的目标，它返回一个 ObjectId 实例。 不管是否存在于一个 Git 对象的数据库，ObjectId 都会代表一个对象的 SHA-1 哈希。 diff --git a/book/B-embedding-git/sections/libgit2.asc b/book/B-embedding-git/sections/libgit2.asc index 2bfa9db1..0e17a5ae 100644 --- a/book/B-embedding-git/sections/libgit2.asc +++ b/book/B-embedding-git/sections/libgit2.asc @@ -37,7 +37,7 @@ git_repository_free(repo); 第二段代码使用了一种 rev-parse 语法（要了解更多，请看 <> ）来得到 HEAD 真正指向的提交。 返回类型是一个 `git_object` 指针，它指代位于版本库里的 Git 对象数据库中的某个东西。 -`git_object` 实际上是几种不同的对象的 ``父'' 类型，每个 ``子'' 类型的内存布局和 `git_object` 是一样的，所以你能安全地把它们转换为正确的类型。 +`git_object` 实际上是几种不同的对象的“父”类型，每个“子”类型的内存布局和 `git_object` 是一样的，所以你能安全地把它们转换为正确的类型。 在上面的例子中， `git_object_type(commit)` 会返回 `GIT_OBJ_COMMIT` ，所以转换成 `git_commit` 指针是安全的。 下一段展示了如何访问一个提交的详情。 @@ -112,7 +112,7 @@ Ruby 的代码很好很简洁，另一方面因为 Libgit2 做了大量工作， ==== 高级功能 Libgit2 有几个超过核心 Git 的能力。 -例如它的可定制性：Libgit2 允许你为一些不同类型的操作自定义的``后端''，让你得以使用与原生 Git 不同的方式存储东西。 +例如它的可定制性：Libgit2 允许你为一些不同类型的操作自定义的“后端”，让你得以使用与原生 Git 不同的方式存储东西。 Libgit2 允许为自定义后端指定配置、引用的存储以及对象数据库， 我们来看一下它究竟是怎么工作的。 @@ -136,7 +136,7 @@ error = git_repository_set_odb(odb); // <4> _(注意：这个错误被捕获了，但是没有被处理。我们希望你的代码比我们的更好。)_ -<1> 初始化一个空的对象数据库（ ODB ） ``前端''，它将被作为一个用来做真正的工作的 ``后端'' 的容器。 +<1> 初始化一个空的对象数据库（ ODB ）“前端”，它将被作为一个用来做真正的工作的“后端”的容器。 <2> 初始化一个自定义 ODB 后端。 <3> 为这个前端增加一个后端。 <4> 打开一个版本库，并让它使用我们的 ODB 来寻找对象。 diff --git a/book/introduction.asc b/book/introduction.asc index 8d51ec78..12022a8c 100644 --- a/book/introduction.asc +++ b/book/introduction.asc @@ -34,7 +34,7 @@ 仍在使用 SVN，并且也没有计划改变，此时，你将了解到 Git 不可思议的能力——本章将展示，在你不得不使用 SVN 服务器 的时候如何协同合作。我们还将介绍如何从不同系统导入项目，以便你能够全身心投入 Git 的怀抱。 -*第十章* 深入 Git 阴暗而漂亮的实现细节。现在，你已经知道所有有关 Git 的知识，能够熟练运用 Git 的强大优雅的功能。 +*第十章* 深入 Git 隐晦而漂亮的实现细节。现在，你已经知道所有有关 Git 的知识，能够熟练运用 Git 的强大优雅的功能。 接下来，你可以继续学习 Git 如何存储对象、Git 的对象模型是怎样的、打包文件的细节、服务器协议等更多知识。 本书自始至终都将引用本章的内容，以便你能够在当时就可以深入了解。但是，如果你像我们一样希望深入学习技术细节， 你可能想先阅读第十章。我们将选择权交给你。 diff --git a/ch02-git-basics.asc b/ch02-git-basics.asc index 6375faa0..1c52da85 100644 --- a/ch02-git-basics.asc +++ b/ch02-git-basics.asc @@ -4,7 +4,7 @@ 假如你只能阅读一章来学习 Git，本章就是你的不二选择。 本章内容涵盖你在使用 Git 完成各种工作中将要使用的各种基本命令。 -在学习完本章之后，你应该能够配置并初始化一个仓库（repository）、开始或停止跟踪（track）文件、暂存（stage）或提交（commit)更改。 +在学习完本章之后，你应该能够配置并初始化一个仓库（repository）、开始或停止跟踪（track）文件、暂存（stage）或提交（commit）更改。 本章也将向你演示如何配置 Git 来忽略指定的文件和文件模式、如何迅速而简单地撤销错误操作、如何浏览你的项目的历史版本以及不同提交（commits）间的差异、如何向你的远程仓库推送（push）以及如何从你的远程仓库拉取（pull）文件。 include::book/02-git-basics/sections/getting-a-repository.asc[] diff --git a/ch03-git-branching.asc b/ch03-git-branching.asc index d3991640..5f1c5e60 100644 --- a/ch03-git-branching.asc +++ b/ch03-git-branching.asc @@ -7,7 +7,7 @@ 使用分支意味着你可以把你的工作从开发主线上分离开来，以免影响开发主线。 在很多版本控制系统中，这是一个略微低效的过程——常常需要完全创建一个源代码目录的副本。对于大项目来说，这样的过程会耗费很多时间。 -有人把 Git 的分支模型称为它的``必杀技特性''，也正因为这一特性，使得 Git 从众多版本控制系统中脱颖而出。 +有人把 Git 的分支模型称为它的“必杀技特性”，也正因为这一特性，使得 Git 从众多版本控制系统中脱颖而出。 为何 Git 的分支模型如此出众呢？ Git 处理分支的方式可谓是难以置信的轻量，创建新分支这一操作几乎能在瞬间完成，并且在不同分支之间的切换操作也是一样便捷。 与许多其它版本控制系统不同，Git 鼓励在工作流程中频繁地使用分支与合并，哪怕一天之内进行许多次。 diff --git a/ch04-git-server.asc b/ch04-git-server.asc index 97747aa8..eaab626d 100644 --- a/ch04-git-server.asc +++ b/ch04-git-server.asc @@ -16,7 +16,7 @@ 如果你对架设自己的服务器没兴趣，可以跳到本章最后一节去看看如何申请一个代码托管服务的帐户然后继续下一章，我们会在那里讨论分散式源码控制环境的林林总总。 -一个远程仓库通常只是一个裸仓库（_bare repository_）— 即一个没有当前工作目录的仓库。 +一个远程仓库通常只是一个裸仓库（bare repository）——即一个没有当前工作目录的仓库。 因为该仓库仅仅作为合作媒介，不需要从磁盘检查快照；存放的只有 Git 的资料。 简单的说，裸仓库就是你工程目录内的 `.git` 子目录内容，不包含其他资料。