Translate 10-git-internals refs

book/10-git-internals/sections/refs.asc

@@ -1,11 +1,11 @@
 [[_git_refs]]
-=== Git References
+=== Git 引用
 
-You can run something like `git log 1a410e` to look through your whole history, but you still have to remember that `1a410e` is the last commit in order to walk that history to find all those objects.
-You need a file in which you can store the SHA-1 value under a simple name so you can use that pointer rather than the raw SHA-1 value.
+你可以借助类似于 `git log 1a410e` 这样的命令来浏览完整的提交历史。但是，为了能遍历那段历史并查看全部提交记录，你仍然必须记住 `1a410e` 是最后一个提交记录（的 SHA-1 值）。
+你需要一个能把 SHA-1 值映射为一个简单的名字的文件，这样你就可以用那个名字指针来代替原始的 SHA-1 值了。
 
-In Git, these are called ``references'' or ``refs;'' you can find the files that contain the SHA-1 values in the `.git/refs` directory.
-In the current project, this directory contains no files, but it does contain a simple structure:
+在 Git 里，这样的文件被称为“引用（references，或缩写为 refs）”；你可以在 `.git/refs` 目录下找到这类含有 SHA-1 值的文件。
+在目前的项目中，这个目录暂时没有包含任何文件，但它包含了一个简单的目录结构：
 
 [source,console]
 ----
@@ -16,14 +16,14 @@ $ find .git/refs
 $ find .git/refs -type f
 ----
 
-To create a new reference that will help you remember where your latest commit is, you can technically do something as simple as this:
+从技术上讲，为了创建一个能帮助你记忆最后一个提交记录所在位置的新引用，你只要简单地做如下操作：
 
 [source,console]
 ----
 $ echo "1a410efbd13591db07496601ebc7a059dd55cfe9" > .git/refs/heads/master
 ----
 
-Now, you can use the head reference you just created instead of the SHA-1 value in your Git commands:
+现在，你已经可以在你的 Git 命令中使用刚刚创建的指向最近那个提交记录的引用来代替相应的 SHA-1 值了：
 
 [source,console]
 ----
@@ -33,23 +33,23 @@ cac0cab538b970a37ea1e769cbbde608743bc96d second commit
 fdf4fc3344e67ab068f836878b6c4951e3b15f3d first commit
 ----
 
-You aren't encouraged to directly edit the reference files.
-Git provides a safer command to do this if you want to update a reference called `update-ref`:
+我们不提倡直接编辑引用文件。
+如果你想更新某个引用，Git 提供了一个更加安全的命令 `update-ref` 来完成此事：
 
 [source,console]
 ----
 $ git update-ref refs/heads/master 1a410efbd13591db07496601ebc7a059dd55cfe9
 ----
 
-That's basically what a branch in Git is: a simple pointer or reference to the head of a line of work.
-To create a branch back at the second commit, you can do this:
+基本上，这就是 Git 分支的本质：一个指向一系列提交记录的头部（即最近一次提交）的简单指针（或者说引用）。
+若想回到第二个提交上并创建一个分支，你可以这么做：
 
 [source,console]
 ----
 $ git update-ref refs/heads/test cac0ca
 ----
 
-Your branch will contain only work from that commit down:
+你的分支将只包含从那个提交开始往前追溯的记录：
 
 [source,console]
 ----
@@ -58,49 +58,49 @@ cac0cab538b970a37ea1e769cbbde608743bc96d second commit
 fdf4fc3344e67ab068f836878b6c4951e3b15f3d first commit
 ----
 
-Now, your Git database conceptually looks something like this:
+至此，你的 Git 数据库从概念上看起来像这样：
 
-.Git directory objects with branch head references included.
-image::images/data-model-4.png[Git directory objects with branch head references included.]
+.包含分支引用的 Git 目录对象。
+image::images/data-model-4.png[包含分支引用的 Git 目录对象。]
 
-When you run commands like `git branch (branchname)`, Git basically runs that `update-ref` command to add the SHA-1 of the last commit of the branch you're on into whatever new reference you want to create.
+基本上，当你运行类似于 `git branch (branchname)` 这样的命令时，Git 会调用 `update-ref` 命令把当前所在分支最后一个提交记录对应的 SHA-1 值添加到你想要创建的任何新引用中。
 
 [[_the_head]]
-==== The HEAD
+==== HEAD 引用
 
-The question now is, when you run `git branch (branchname)`, how does Git know the SHA-1 of the last commit?
-The answer is the HEAD file.
+现在的问题是，当你执行 `git branch (branchname)` 时，Git 如何知道最后一次提交的 SHA-1 值呢？
+答案是 HEAD 文件。
 
-The HEAD file is a symbolic reference to the branch you're currently on.
-By symbolic reference, we mean that unlike a normal reference, it doesn’t generally contain a SHA-1 value but rather a pointer to another reference.
-If you look at the file, you'll normally see something like this:
+HEAD 文件是一个符号引用（symbolic reference），它指向目前你所在的分支。
+通常，所谓符号引用并不像普通引用那样包含一个 SHA-1 值，而是一个指向另一个引用的指针。
+如果查看对应的文件内容，一般而言你看到的类似这样：
 
 [source,console]
 ----
 $ cat .git/HEAD
 ref: refs/heads/master
 ----
 
-If you run `git checkout test`, Git updates the file to look like this:
+如果你执行 `git checkout test`，Git 会更新该文件，使其看起来像这样：
 
 [source,console]
 ----
 $ cat .git/HEAD
 ref: refs/heads/test
 ----
 
-When you run `git commit`, it creates the commit object, specifying the parent of that commit object to be whatever SHA-1 value the reference in HEAD points to.
+当你执行 `git commit`，Git 会创建一个提交对象，并将 HEAD 引用内的那个引用所指向的任何 SHA-1 值设置为该提交对象的父提交。
 
-You can also manually edit this file, but again a safer command exists to do so: `symbolic-ref`.
-You can read the value of your HEAD via this command:
+你同样可以手动编辑该文件，然而，再一次地，存在一个更安全的命令来完成此事：`symbolic-ref`。
+你可以借助此命令来查看 HEAD 引用对应的值：
 
 [source,console]
 ----
 $ git symbolic-ref HEAD
 refs/heads/master
 ----
 
-You can also set the value of HEAD:
+你同样可以设置 HEAD 引用的值：
 
 [source,console]
 ----
@@ -109,48 +109,48 @@ $ cat .git/HEAD
 ref: refs/heads/test
 ----
 
-You can't set a symbolic reference outside of the refs style:
+你不能把符号引用设置为一个不符合引用格式的值：
 
 [source,console]
 ----
 $ git symbolic-ref HEAD test
 fatal: Refusing to point HEAD outside of refs/
 ----
 
-==== Tags
+==== 标签引用
 
-We just finished discussing Git's three main object types, but there is a fourth.
-The tag object is very much like a commit object – it contains a tagger, a date, a message, and a pointer.
-The main difference is that a tag object generally points to a commit rather than a tree.
-It's like a branch reference, but it never moves – it always points to the same commit but gives it a friendlier name.
+前文我们刚讨论过 Git 的三种主要对象类型，事实上这里还有第四种。
+标签对象（tag object）非常类似于一个提交对象——它包含一个标签创建者信息，一个日期，一段注释信息，以及一个指针。
+主要的区别在于，标签对象通常指向一个提交对象，而不是一个树对象。
+它像是一个永不移动的分支引用——它永远指向同一个提交对象，只不过给这个提交对象加上一个更友好的名字罢了。
 
-As discussed in <<_git_basics_chapter>>, there are two types of tags: annotated and lightweight.
-You can make a lightweight tag by running something like this:
+正如 <<_git_basics_chapter>> 中所讨论的那样，存在两种类型的标签：含注解的标签和轻量级标签。
+你可以像这样创建一个轻量级标签：
 
 [source,console]
 ----
 $ git update-ref refs/tags/v1.0 cac0cab538b970a37ea1e769cbbde608743bc96d
 ----
 
-That is all a lightweight tag is – a reference that never moves.
-An annotated tag is more complex, however.
-If you create an annotated tag, Git creates a tag object and then writes a reference to point to it rather than directly to the commit.
-You can see this by creating an annotated tag (`-a` specifies that it's an annotated tag):
+这就是轻量级标签的全部内容——一个固定的引用。
+另一方面，一个含注解的标签则更复杂一些。
+如果你创建一个含注解的标签，Git 会创建一个标签对象，并记录一个引用来指向该标签对象，而不是直接指向提交对象。
+你可以通过创建一个含注解的标签来验证这个过程（`-a` 选项指定了要创建的是一个含注解的标签）：
 
 [source,console]
 ----
 $ git tag -a v1.1 1a410efbd13591db07496601ebc7a059dd55cfe9 -m 'test tag'
 ----
 
-Here's the object SHA-1 value it created:
+下面是上述过程所建标签对象的 SHA-1 值：
 
 [source,console]
 ----
 $ cat .git/refs/tags/v1.1
 9585191f37f7b0fb9444f35a9bf50de191beadc2
 ----
 
-Now, run the `cat-file` command on that SHA-1 value:
+现在对该 SHA-1 值运行 `cat-file` 命令：
 
 [source,console]
 ----
@@ -163,23 +163,23 @@ tagger Scott Chacon <[email protected]> Sat May 23 16:48:58 2009 -0700
 test tag
 ----
 
-Notice that the object entry points to the commit SHA-1 value that you tagged.
-Also notice that it doesn't need to point to a commit; you can tag any Git object.
-In the Git source code, for example, the maintainer has added their GPG public key as a blob object and then tagged it.
-You can view the public key by running this in a clone of the Git repository:
+我们注意到，object 条目指向你打了标签的那个提交对象所对应的 SHA-1 值。
+另外要注意的是，标签对象并非必须指向某个提交对象；你可以对任意类型的 Git 对象打标签。
+例如，在 Git 源码（的 Git 版本库）中，项目维护者将他们的 GPG 公钥添加为一个 blob 对象，然后对这个对象打了一个标签。
+你可以克隆一个 Git 源码版本库，然后通过执行下面的命令来在这个版本库中查看上述公钥：
 
 [source,console]
 ----
 $ git cat-file blob junio-gpg-pub
 ----
 
-The Linux kernel repository also has a non-commit-pointing tag object – the first tag created points to the initial tree of the import of the source code.
+Linux 内核版本库同样有一个不指向提交对象的标签对象——首个被创建的标签对象所指向的是最初被引入版本库的那份内核源码所对应的树对象。
 
-==== Remotes
+==== 远程引用
 
-The third type of reference that you'll see is a remote reference.
-If you add a remote and push to it, Git stores the value you last pushed to that remote for each branch in the `refs/remotes` directory.
-For instance, you can add a remote called `origin` and push your `master` branch to it:
+你将看到的第三种引用类型是远程引用（remote reference）。
+如果你添加了一个远程版本库并对其执行过推送操作，Git 会记录下最近一次推送操作时每一个分支所对应的值，并保存在 `refs/remotes` 目录下。
+例如，你可以添加一个叫做 `origin` 的远程版本库，然后把你的 `master` 分支推送上去：
 
 [source,console]
 ----
@@ -193,14 +193,14 @@ To [email protected]:schacon/simplegit-progit.git
   a11bef0..ca82a6d  master -> master
 ----
 
-Then, you can see what the `master` branch on the `origin` remote was the last time you communicated with the server, by checking the `refs/remotes/origin/master` file:
+此时，如果你查看 `refs/remotes/origin/master` 文件，可以发现 `origin` 远程版本库的 `master` 分支所对应的 SHA-1 值，就是最近一次你与服务器通信时（本地 `master` 分支所对应）的 SHA-1 值：
 
 [source,console]
 ----
 $ cat .git/refs/remotes/origin/master
 ca82a6dff817ec66f44342007202690a93763949
 ----
 
-Remote references differ from branches (`refs/heads` references) mainly in that they're considered read-only.
-You can `git checkout` to one, but Git won't point HEAD at one, so you'll never update it with a `commit` command.
-Git manages them as bookmarks to the last known state of where those branches were on those servers.
+远程引用和分支（位于 `refs/heads` 目录下的引用）之间最主要的区别在于，远程引用是只读的。
+虽然你可以 `git checkout` 到某个远程引用，但是 Git 并不会将 HEAD 引用指向该远程引用。因此，你永远不能通过 `commit` 命令来更新远程引用。
+Git 将这些远程引用作为记录远程服务器上各分支最后已知位置状态的书签来管理。

status.json

@@ -103,7 +103,7 @@
       "sections/objects.asc": 0,
       "sections/packfiles.asc": 0,
       "sections/plumbing-porcelain.asc": 100,
-      "sections/refs.asc": 0,
+      "sections/refs.asc": 100,
       "sections/refspec.asc": 0,
       "sections/transfer-protocols.asc": 0
     },