{"action":"created","comment":{"url":"https://api.github.com/repos/progit/progit2-zh/pulls/comments/35490375","id":35490375,"diff_hunk":"@@ -1,480 +1,480 @@\n [appendix]\n-== Git Commands\n+== Git 命令\n \n-Throughout the book we have introduced dozens of Git commands and have tried hard to introduce them within something of a narrative, adding more commands to the story slowly. However, this leaves us with examples of usage of the commands somewhat scattered throughout the whole book.\n+在这一整本书里我们介绍了大量的 Git 命令，并尽可能的通过讲故事的的方式来介绍它们，慢慢的介绍了越来越多的命令。 但是这导致这些命令的示例用法都散落在在全书的各处。\n \n-In this appendix, we'll go through all the Git commands we addressed throughout the book, grouped roughly by what they're used for. We'll talk about what each command very generally does and then point out where in the book you can find us having used it.\n+在此附录中，我们会将本书中所提到过的命令都过一遍，并根据其用途大致的分类，会大致地讨论每个命的作用，指出在本书中哪些章节使用过。\n \n \n-=== Setup and Config\n+=== 设置与配置 （ Setup and Config ）\n \n-There are two commands that are used quite a lot, from the first invocations of Git to common every day tweaking and referencing, the `config` and `help` commands.\n+有两个命令使用得最多了，从第一次调用 Git 到每天的日常微调及参考，这个两个命令就是： `config` 和  `help` 命令\n \n ==== git config\n \n-Git has a default way of doing hundreds of things. For a lot of these things, you can tell Git to default to doing them a different way, or set your preferences. This invovles everything from telling Git what your name is to specific terminal color preferences or what editor you use. There are several files this command will read from and write to so you can set values globally or down to specific repositories.\n+Git 做的很多工作都有一个默认方式。对于绝大多数工作而言，你可以改变 Git 的默认方式，或者根据你的偏好来设置。这些设置涵盖了所有的事，从告诉 Git 你的名字，到指定偏好的终端颜色，以及你使用的编辑器。此命令会从几个特定的配置文件中读取和写入配置值，以便你可以从全局或者针对特定的仓库来进行设置。\n \n-The `git config` command has been used in nearly every chapter of the book.\n+本书的所有章节几乎都有用到 `git config` 命令。\n \n-In <<_first_time>> we used it to specify our name, email address and editor preference before we even got started using Git.\n+在 <<_first_time>> 一节中，在开始使用 Git 之前，我们用它来指定我们的名字，邮箱地址和编辑器偏好。\n \n-In <<_git_aliases>> we showed how you could use it to create shorthand commands that expand to long option sequences so you don't have to type them every time.\n+在 <<_git_aliases>> 一节中我们展示了如何创建可以展开为长选项序列的短命令，以便你不用每次都输入它们。\n \n-In <<_rebasing>> we used it to make `--rebase` the default when you run `git pull`.\n+在 <<_rebasing>> 一节中，执行 `git pull` 命令时，使用此命令来将 `--rebase` 作为默认选项。\n \n-In <<_credential_caching>> we used it to set up a default store for your HTTP passwords.\n+在 <<_credential_caching>> 一节中，我们使用它来为你的 HTTP 密码设置一个默认的存储区域。\n \n-In <<_keyword_expansion>> we showed how to set up smudge and clean filters on content coming in and out of Git.\n+在 <<_keyword_expansion>> 一节中我们展示了如何设置在 Git 的内容添加和减少时使用的 smudge 过滤器 和 clean 过滤器。\n \n-Finally, basically the entirety of <<_git_config>> is dedicated to the command.\n+最后，基本上 <<_git_config>> 整个章节都是针对此命令的。\n \n-==== git help\n+==== Git 帮助 （git help）\n \n-The `git help` command is used to show you all the documentation shipped with Git about any command. While we're giving a rough overview of most of the more popular ones in this appendix, for a full listing of all of the possible options and flags for every command, you can always run `git help <command>`.\n+`git help` 命令用来显示任何命令的 Git 自带文档。但是我们仅会在此附录中提到大部分最常用的命令，对于每一个命令的完整的可选项及标志列表，你可以随时运行 `git help <command>` 命令来了解。\n \n-We introduced the `git help` command in <<_git_help>> and showed you how to use it to find more information about the `git shell` in <<_setting_up_server>>.\n+我们在 <<_git_help>> 一节中介绍了 `git help` 命令，同时在 <<_setting_up_server>> 一节中给你展示了如何使用它来查找更多关于 `git shell` 的信息。\n \n \n-=== Getting and Creating Projects\n+=== 获取与创建项目 （Getting and Creating Projects）\n \n-There are two ways to get a Git repository. One is to copy it from an existing repository on the network or elsewhere and the other is to create a new one in an existing directory.\n+获取一个 Git 仓库的方式有几种。一种是从网络上或者其他地方拷贝一个现有的仓库，另一种就是在一个目录中创建一个新的仓库。\n \n ==== git init\n \n-To take a directory and turn it into a new Git repository so you can start version controlling it, you can simply run `git init`.\n+你只需要简单地运行 `git init` 就可以将一个目录转变成一个 Git 仓库，这样你就可以开始对它进行版本管理了。\n \n-We first introduce this in [[_getting_a_repo]], where we show creating a brand new repository to start working with.\n+我们一开始在 [[_getting_a_repo]] 一节中介绍了如何创建一个新的仓库来开始工作。\n \n-We talk briefly about how you can change the default branch from ``master'' in <<_remote_branches>>.\n+在 <<_remote_branches>> 一节中我们简单的讨论了如何改变默认分支。\n \n-We use this command to create an empty bare  repository for a server in <<_bare_repo>>.\n+在 <<_bare_repo>> 一节中我们使用此命令来为一个服务器创建一个空的祼仓库。\n \n-Finally, we go through some of the details of what it actually does behind the scenes in <<_plumbing_porcelain>>.\n+最后，我们在 <<_plumbing_porcelain>> 一节中介绍了此命令背后工作的原理的一些细节。\n \n ==== git clone\n \n-The `git clone` command is actually something of a wrapper around several other commands. It creates a new directory, goes into it and runs `git init` to make it an empty Git repository, adds a remote (`git remote add`) to the URL that you pass it (by default named `origin`), runs a `git fetch` from that remote repository and then checks out the latest commit into your working directory with `git checkout`.\n+`git clone` 实际上是一个封装了其他几个命令的命令。它创建了一个新目录，切换到新的目录，然后 `git init` 来初始化一个空的 Git 仓库， 然后为你指定的 URL 添加一个（默认名称为 `origin` 的）远程仓库（`git remote add`），再针对远程仓库执行 `git fetch`，最后通过 `git checkout` 将远程仓库的最新提交检出到本地的工作目录。\n \n-The `git clone` command is used in dozens of places throughout the book, but we'll just list a few interesting places.\n+`git clone` 命令在本书中多次用到，这里只列举几个有意思的地方。\n \n-It's basically introduced and explained in <<_git_cloning>>, where we go through a few examples.\n+在 <<_git_cloning>> 一节中我们通过几个示例详细介绍了此命令。\n \n-In <<_git_on_the_server>> we look at using the `--bare` option to create a copy of a Git repository with no working directory.\n+在 <<_git_on_the_server>> 一节中，我们使用了 `--bare` 选项来创建一个没有任何工作目录的 Git 仓库副本。\n \n-In <<_bundling>> we use it to unbundle a bundled Git repository.\n+在 <<_bundling>> 一节中我们使用它来解包一个打包好的 Git 仓库。\n \n-Finally, in <<_cloning_submodules>> we learn the `--recursive` option to make cloning a repository with submodules a little simpler.\n+最后，在 <<_cloning_submodules>> 一节中我们学习了使用 `--recursive` 选项来让克隆一个带有子模块的仓库变得简单\n \n-Though it's used in many other places through the book, these are the ones that are somewhat unique or where it is used in ways that are a little different.\n+虽然在本书的其他地方都有用到此命令，但是上面这些用法是特例，或者使用方式有点特别。\n \n \n-=== Basic Snapshotting\n+=== 快照基础 Basic Snapshotting\n \n-For the basic workflow of staging content and committing it to your history, there are only a few basic commands.\n+对于基本的暂存内容及提交到你的历史记录中的工作流，只有少数基本的命令。\n \n ==== git add\n \n-The `git add` command adds content from the working directory into the staging area (or ``index'') for the next commit. When the `git commit` command is run, by default it only looks at this staging area, so `git add` is used to craft what exactly you would like your next commit snapshot to look like.\n+`git add` 命令将内容从工作目录添加到暂存区（或称为索引（index）区），以备下次提交。当 `git commit` 命令执行时，默认情况下它只会检查暂存区域，因此 `git add` 是用来确定下一次提交时快照的样子的。\n \n-This command is an incredibly important command in Git and is mentioned or used dozens of times in this book. We'll quickly cover some of the unique uses that can be found.\n+这个命令对于 Git 来说特别的重要，所以在本书中被无数次的提及和使用。我们将快速的过一遍一些可以看到的独特的用法。\n \n-We first introduce and explain `git add` in detail in <<_tracking_files>>.\n+我们在 <<_tracking_files>> 一节中介绍并详细解释了 `git add` 命令。\n \n-We mention how to use it to resolve merge conflicts in <<_basic_merge_conflicts>>.\n+然后，我们在 <<_basic_merge_conflicts>> 一节中提到了如何使用它来解决合并冲突。\n \n-We go over using it to interactively stage only specific parts of a modified file in <<_interactive_staging>>.\n+接下来，我们在 <<_interactive_staging>> 一章中使用它来交互式的暂存一个已修改文件的特定部分。\n \n-Finally, we emulate it at a low level in <<_tree_objects>>, so you can get an idea of what it's doing behind the scenes.\n+最后，在 <<_tree_objects>> 一节中我们在一个低层次中模拟了它的用法，以便你可以了解在这背后发生了什么。\n \n ==== git status\n \n-The `git status` command will show you the different states of files in your working directory and staging area. Which files are modified and unstaged and which are staged but not yet committed. In it's normal form, it also will show you some basic hints on how to move files between these stages.\n+`git status` 命令将为你展示工作区及暂存区域中不同状态的文件。这其中包含了已修改但未暂存，或已经暂存但没有提交的文件。 一般在它显示形式中，会给你展示一些关于如何在这些暂存区域之间移动文件的提示。\n \n-We first cover `status` in <<_checking_status>>, both in it's basic and simplified forms. While we use it throughout the book, pretty much everything you can do with the `git status` command is covered there.\n+首先，我们在 <<_checking_status>> 一节中介绍了 `status` 的基本及简单的形式。虽然我们在全书中都有用到它，但是绝大部分的你能用 `git status` 做的事情都在这一章讲到了。\n \n ==== git diff\n \n-The `git diff` command is used when you want to see differences between any two trees. This could be the difference between your working environment and your staging area (`git diff` by itself), between your staging area and your last commit (`git diff --staged`), or between two commits (`git diff master branchB`).\n+当需要查看任意两棵树的差异时你可以使用 `git diff` 命令。此命令可以查看你工作环境与你的暂存区的差异（`git diff` 默认的做法），你暂存区域与你最后提交之间的差异（`git diff --staged`），或者比较两个提交记录的差异（`git diff master branchB`）\n \n-We first look at the basic uses of `git diff` in <<_git_diff_staged>>, where we show how to see what changes are staged and which are not yet staged.\n+首先，我们在 <<_git_diff_staged>> 一章中研究了 `git diff` 的基本用法，在此节中我们展示了如何查看哪些变化已经暂存了，哪些没有。\n \n-We use it to look for possible whitespace issues before committing with the `--check` option in <<_commit_guidelines>>.\n+在 <<_commit_guidelines>> 一节中,我们在提交前使用 `--check` 选项来检查可能存在的空白字符问题。\n \n-We see how to check the differences between branches more effectively with the `git diff A...B` syntax in <<_what_is_introduced>>.\n+在 <<_what_is_introduced>> 一节中,了解了使用 `git diff A...B` 语法来更有效地比较不同分支之间的差异。\n \n-We use it to filter out whitespace differences with `-w` and how to compare different stages of conflicted files with `--theirs`, `--ours` and `--base` in <<_advanced_merging>>.\n+在 <<_advanced_merging>> 一节中我们使用 `-w` 选项来过滤掉空白字符的差异，及通过 `--theirs`、`--ours` 和 `--base` 选项来比较不同暂存区冲突文件的差异。\n \n-Finally, we use it to effectively compare submodule changes with `--submodule` in <<_starting_submodules>>.\n+最后，在 <<_starting_submodules>> 一节中,我们使用此命令合 `--submodule` 选项来有效的比较子模块的变化。\n \n ==== git difftool\n \n-The `git difftool` command simply launches an external tool to show you the difference between two trees in case you want to use something other than the built in `git diff` command.\n+当你不想使用内置的 `git diff` 命令时。`git difftool` 可以用来简单地启动一个外部工具来为你展示两棵树之间的差异。\n \n-We only briefly mention this in <<_git_difftool>>.\n+我们只在 <<_git_difftool>> 一节中简单的提到了此命令。\n \n ==== git commit\n \n-The `git commit` command takes all the file contents that have been staged with `git add` and records a new permanent snapshot in the database and then moves the branch pointer on the current branch up to it.\n+`git commit` 命令将所有通过 `git add` 暂存的文件内容在数据库中创建一个持久的快照，然后将当前分支上的分支指针移到其之上。\n \n-We first cover the basics of committing in <<_committing_changes>>. There we also demonstrate how to use the `-a` flag to skip the `git add` step in daily workflows and how to use the `-m` flag to pass a commit message in on the command line instead of firing up an editor.\n+首先，我们在 <<_committing_changes>> 一节中涉及了此命令的基本用法。演示了如何在日常的工作流程中通过使用 `-a` 标志来跳过 `git add` 这一步，及如何使用 `-m` 标志通过命令行而不启动一个编辑器来传递提交信息。\n \n-In <<_undoing>> we cover using the `--amend` option to redo the most recent commit.\n+在 <<_undoing>> 一节中我们介绍了使用 `--amend` 选项来重做最后的提交。\n \n-In <<_git_branches_overview>>, we go into much more detail about what `git commit` does and why it does it like that.\n+在 <<_git_branches_overview>>，我们探讨了 `git commit` 的更多细节，及工作原理。\n \n-We looked at how to sign commits cryptographically with the `-S` flag in <<_signing_commits>>.\n+在 <<_signing_commits>> 一节中我们探讨了如何使用 `-S` 标志来为提交签名加密。\n \n-Finally, we take a look at what the `git commit` command does in the background and how it's actually implemented in <<_git_commit_objects>>.\n+最后，在 <<_git_commit_objects>> 一节中，我们了解了 `git commit` 在背后做了什么，及它是如何实现的。\n \n ==== git reset\n \n-The `git reset` command is primarily used to undo things, as you can possibly tell by the verb. It moves around the `HEAD` pointer and optionally changes the `index` or staging area and can also optionally change the working directory if you use `--hard`. This final option makes it possible for this command to lose your work if used incorrectly, so make sure you understand it before using it.\n+`git reset` 命令主要用来根据你传递给动作的参数来执行撤销操作。它可以移动 `HEAD` 指针并且可选的改变 `index` 或者暂存区，如果你使用 `--hard` 参数的话你甚至可以改变工作区。\n \n-We first effectively cover the simplest use of `git reset` in <<_unstaging>>, where we use it to unstage a file we had run `git add` on.\n+首先，我们在 <<_unstaging>> 一节中介绍了 `git reset` 简单高效的用法，用来对执行过 `git add` 命令的文件取消暂存。\n \n-We then cover it in quite some detail in <<_git_reset>>, which is entirely devoted to explaining this command.\n+在 <<_git_reset>> 一节中我们详细介绍了此命令，几乎整节都在解释此命令。\n \n-We use `git reset --hard` to abort a merge in <<_abort_merge>>, where we also use `git merge --abort`, which is a bit of a wrapper for the `git reset` command.\n+在 <<_abort_merge>> 一节中，我们使用 `git reset --hard` 来取消一个合并，同时我们也使用了 `git merge --abort` 命令，它是 `git reset` 的一个简单的封装。\n \n ==== git rm\n \n-The `git rm` command is used to remove files from the staging area and working directory for Git. It is similar to `git add` in that it stages a removal of a file for the next commit.\n+`git rm` 是 Git 用来从工作区，或者暂存区移除文件的命令。在为下一次提交暂存一个移除操作上，它与 `git add` 有一点类似。\n \n-We cover the `git rm` command in some detail in <<_removing_files>>, including recursively removing files and only removing files from the staging area but leaving them in the working directory with `--cached`.\n+我们在 <<_removing_files>> 一节中提到了 `git rm` 的一些细节，包括递归地移除文件，和使用 `--cached` 选项来只移除暂存区域的文件但是保留工作区的文件。\n \n-The only other differing use of `git rm` in the book is in <<_removing_objects>> where we briefly use and explain the `--ignore-unmatch` when running `git filter-branch`, which simply makes it not error out when the file we are trying to remove doesn't exist. This can be useful for scripting purposes.\n+在本书的 <<_removing_objects>> 一节中，介绍了 `git rm` 仅有的几种不同用法，如在执行 `git filter-branch` 中使用和解释了 `--ignore-unmatch` 选项。这对脚本来说很有用。\n \n ==== git mv\n \n-The `git mv` command is a thin convenience command to move a file and then run `git add` on the new file and `git rm` on the old file.\n+`git mv` 命令是一个便利命令，用于移到一个文件并且在新文件上执行`git add`命令及在老文件上执行`git rm`命令。\n \n-We only briefly mention this command in <<_git_mv>>.\n+我们只是在 <<_git_mv>> 一节中简单地提到了此命令。\n \n ==== git clean\n \n-The `git clean` command is used to remove unwanted files from your working directory. This could include removing temporary build artifacts or merge conflict files.\n+`git clean` 是一个用来从工作区中移除不想要的文件的命令。可以是编译的临时文件或者合并冲突的文件。\n \n-We cover many of the options and scenarios in which you might used the clean command in <<_git_clean>>.\n+在 <<_git_clean>> 一节中我们介绍了你可能会使用 `clean` 命令的大量选项及场景。\n \n-=== Branching and Merging\n+=== 分支与合并 （Branching and Merging）\n \n-There are just a handful of commands that implement most of the branching and merging functionality in Git.\n+Git 有几个实现大部的分支及合并功能的实用命令。\n \n ==== git branch\n \n-The `git branch` command is actually something of a branch management tool. It can list the branches you have, create a new branch, delete branches and rename branches.\n+`git branch` 命令实际上是某种程度上的分支管理工具。它可以列出你所有的分支、创建新分支、删除分支及重命名分支。\n \n-Most of <<_git_branching>> is dedicated to the `branch` command and it's used throughout the entire chapter. We first introduce it in <<_create_new_branch>> and we go through most of it's other features (listing and deleting) in <<_branch_management>>.\n+<<_git_branching>> 一节主要是为 `branch` 命令来设计的，它贯穿了整个章节。首先，我们在 <<_create_new_branch>> 一节中介绍了它，然后我们在 <<_branch_management>> 一节中介绍了它的其它大部分特性（列举及删除）。\n \n-In <<_tracking_branches>> we use the `git branch -u` option to set up a tracking branch.\n+在 <<_tracking_branches>> 一节中，我们使用 `git branch -u` 选项来设置一个跟踪分支。\n \n-Finally, we go through some of what it does in the background in <<_git_refs>>.\n+最后，我们在 <<_git_refs>> 一节中讲到了它在背后做一什么。\n \n ==== git checkout\n \n-The `git checkout` command is used to switch branches and  check content out into your working directory.\n+`git checkout` 命令用来切换分支，或者检出内容到工作目录。\n \n-We first encounter the command in <<_switching_branches>> along with the `git branch` command.\n+我们是在 <<_switching_branches>> 一节中第一次认识了命令及 `git branch` 命令。\n \n-We see how to use it to start tracking branches with the `--track` flag in <<_tracking_branches>>.\n+在 <<_tracking_branches>> 一节中我们了解了如何使用 `--track` 标志来开始跟踪分支。\n \n-We use it to reintroduce file conflicts with `--conflict=diff3` in <<_checking_out_conflicts>>.\n+在 <<_checking_out_conflicts>> 一节中，我们用此命令和 `--conflict=diff3` 来重新介绍文件冲突。\n \n-We go into closer detail on it's relationship with `git reset` in <<_git_reset>>.\n+在 <<_git_reset>> 一节中，我们进一步了解了其细节及与 `git reset` 的关系。\n \n-Finally, we go into some implementation detail in <<_the_head>>.\n+最后，我们在 <<_the_head>> 一节中介绍了此命令的一些实现细节。\n \n ==== git merge\n \n-The `git merge` tool is used to merge one or more branches  into the branch you have checked out. It will then advance the current branch to the result of the merge.\n+`git merge` 工具用来合并一个或者多个分支到你已经检出的分支中, 然后它将当前分支指针移动到合并结果上。\n \n-The `git merge` command was first introduced in <<_basic_branching>>. Though it is used in various places in the book, there are very few variations of the `merge` command -- generally just `git merge <branch>` with the name of the single branch you want to merge in.\n+我们首先在 <<_basic_branching>> 一节中介绍了 `git merge` 命令。虽然它在本书的各种地方都有用到，但是 `merge` 命令有几个变种，一般只是 `git merge <branch>` 带上一个你想合并进来的一个分支名称。\n \n-We covered how to do a squashed merge (where Git merges the work but pretends like it's just a new commit without recording the history of the branch you're merging in) at the very end of <<_public_project>>.\n+我们在 <<_public_project>> 的后面介绍了如何做一个 `squashed merge` （指 Git 合并时将其当作一个新的提交而不是记录你合并时的分支的历史记录。）\n \n-We went over a lot about the merge process and command, including the `-Xignore-all-whitespace` command and the `--abort` flag to abort a problem merge in <<_advanced_merging>>.\n+在 <<_advanced_merging>> 一节中，我们介绍了合并的过程及命令，包含 `-Xignore-all-whitespace` 命令及 `--abort` 选项来中止一个有问题的提交。\n \n-We learned how to verify signatures before merging if your project is using GPG signing in <<_signing_commits>>.\n+在 <<_signing_commits>> 一节中我们学习了如何在合并前验证签名，如果你项目正在使用 GPG 签名的话。\n \n-Finally, we learned about Subtree merging in <<_subtree_merge>>.\n+最后，我们在 <<_subtree_merge>> 一节中学习了子树合并。\n \n ==== git mergetool\n \n-The `git mergetool` command simply launches an external merge helper in case you have issues with a merge in Git.\n+当你在 Git 的合并中遇到问题时，可以使用 `git mergetool` 来启动一个外部的合并帮助工具。\n \n-We mention it quickly in <<_basic_merge_conflicts>> and go into detail on how to implement your own external merge tool in <<_external_merge_tools>>.\n+我们在 <<_basic_merge_conflicts>> 中快速介绍了一下它，然后在 <<_external_merge_tools>> 一节中介绍了如何实现你自己的外部合并工具的细节。\n \n ==== git log\n \n-The `git log` command is used to show the reachable recorded history of a project from the most recent commit snapshot backwards. By default it will only show the history of the branch you're currently on, but can be given different or even multiple heads or branches from which to traverse. It is also often used to show differences between two or more branches at the commit level.\n+`git log` 命令用来展示一个项目的可达历史记录，从最近的提交快照起。默认情况下，它只显示你当前所在分支的历史记录，但是可以显示不同的甚至多个头记录或分支以供遍历。此命令通常也用来在提交记录级别显示两个或多个分支之间的差异。\n \n-This command is used in nearly every chapter of the book to demonstrate the history of a project.\n+在本书的每一章几乎都有用到此命令来描述一个项目的历史。\n \n-We introduce the command and cover it in some depth in <<_viewing_history>>. There we look at the `-p` and `--stat` option to get an idea of what was introduced in each commit and the `--pretty` and `--oneline` options to view the history more concisely, along with some simple date and author filtering options.\n+在 <<_viewing_history>> 一节中我们介绍了此命令，并深入做了研究，研究了包括 `-p` 和 `--stat` 选项来了解每一个提交引入的变更，及使用`--pretty` 和 `--online` 选项来查看简洁的历史记录。\n \n-In <<_create_new_branch>> we use it with the `--decorate` option to easily visualize where our branch pointers are located and we also use the `--graph` option to see what divergent histories look like.\n+在 <<_create_new_branch>> 一节中我们使用它加 `--decorate` 选项来简单的可视化我们分支的指针所在，同时我们使用 `--graph` 选项来查看分叉的历史记录是怎么样的。\n \n-In <<_private_team>> and <<_commit_ranges>> we cover the `branchA..branchB` syntax to use the `git log` command to see what commits are unique to a branch relative to another branch. In <<_commit_ranges>> we go through this fairly extensively.\n+在 <<_private_team>> 和 <<_commit_ranges>> 章节中，我们介绍了在使用 `git log` 命令时用 `branchA..branchB` 的语法来查看一个分支相对于另一个分支, 哪一些提交是唯一的。在 <<_commit_ranges>> 一节中我们作了更多介绍。\n \n-In <<_merge_log>> and <<_triple_dot>> we cover using the `branchA...branchB` format and the `--left-right` syntax to see what is in one branch or the other but not in both. In <<_merge_log>> we also look at how to use the `--merge` option to help with merge conflict debugging as well as using the `--cc` option to look at merge commit conflicts in your history.\n+在 <_merge_log>> 和 <<_triple_dot>> 章节中，我们介绍了 `branchA...branchB` 格式和 `--left-right` 语法来查看哪些仅其中一个分支。在 <<_merge_log>> 一节中我们还研究了如何使用 `--merge` 选项来帮助合并冲突调试，同样也使用 `--cc` 选项来查看在你历史记录中的合并提交的冲突。\n \n-In <<_git_notes>> we use the `--notes=` option to display notes inline in the log output, and in <<_git_reflog>> we use the `-g` option to view the Git reflog through this tool instead of doing branch traversal.\n+在 <<_git_notes>> 一节中，我们使用 `--notes=` 选项来在输出的日志中内联注释，在 <<_git_reflog>> 一节中我们使用此工具和 `-g` 选项 而不是遍历分支来查看 Git 的 `reflog`。\n \n-In <<_searching>> we look at using the `-S` and `-L` options to do fairly sophisticated searches for something that happened historically in the code such as seeing the history of a function.\n+在 <<_searching>> 一节中我们研究了`-S` 及 `-L` 选项来进行来在代码的历史变更中进行相当优雅地搜索，如一个函数的历史。\n \n-In <<_signing_commits>> we see how to use `--show-signature` to add a validation string to each commit in the `git log` output based on if it was validly signed or not.\n+在 <<_signing_commits>> 一节中，我们了解了如何使用 `--show-signature` 来为每一个提交的 `git log` 输出中，添加一个判断是否已经合法的签名的一个验证。\n \n ==== git stash\n \n-The `git stash` command is used to temporarily store uncommitted work in order to clean out your working directory without having to commit unfinished work on a branch.\n+`git stash` 命令用来临时地保存一些还没有提交的工作，以便在分支上不需要提交未完成工作就可以清理工作目录。\n \n-This is basically entirely covered in <<_git_stashing>>.\n+<<_git_stashing>> 一整个章节基本就是在讲这个命令。\n \n ==== git tag\n \n-The `git tag` command is used to give a permanent bookmark to a specific point in the code history. Generally this is used for things like releases.\n+`git tag` 命令用来为代码历史记录中的某一个点指定一个永久的书签。一般来说它用于发布相关事项。\n \n-This command is introduced and covered in detail in <<_git_tagging>> and we use it in practice in <<_tagging_releases>>.\n+我们在 <<_git_tagging>> 一节中介绍了此命令及相关细节，并在 <<_tagging_releases>> 一节实践了此命令。\n \n-We also cover how to create a GPG signed tag with the `-s` flag and verify one with the `-v` flag in <<_signing>>.\n+我也在 <<_signing>> 一节中介绍了如何使用 `-s` 标志创建一个 GPG 签名的标签，然后使用 `-v` 选项来验证。\n \n+=== 分享与更新项目 Sharing and Updating Projects\n \n-=== Sharing and Updating Projects\n-\n-There are not very many commands in Git that access the network, nearly all of the commands operate on the local database. When you are ready to share your work or pull changes from elsewhere, there are a handful of commands that deal with remote repositories.\n+在 Git 中没有多少访问网络的命令，几乎所以的命令都是在操作本地的数据库。当你想要分享你的工作，或者从其他地方拉取变更时，这有几个处理远程仓库的命令。\n \n ==== git fetch\n \n-The `git fetch` command communicates with a remote repository and fetches down all the information that is in that repository that is not in your current one and stores it in your local database.\n+`git fetch` 命令与一个远程的仓库交互，并且将远程仓库中有但是在当前仓库的没有的所有信息拉取下来然后存储在你本地数据库中。\n \n-We first look at this command in <<_fetching_and_pulling>> and we continue to see examples of it use in <<_remote_branches>>.\n+我们开始在 <<_fetching_and_pulling>> 一节中介绍了此命令，然后我们在 <<_remote_branches>> 中看到了几个使用示例。\n \n-We also use it in several of the examples in <<_contributing_project>>.\n+我们在 <<_contributing_project>> 一节中有几个示例中也都有使用此命令。\n \n-We use it to fetch a single specific reference that is outside of the default space in <<_pr_refs>> and we see how to fetch from a bundle in <<_bundling>>.\n+在 <<_pr_refs>> 我们用它来抓取一个在默认空间之外指定的引用，在 <<_bundling>> 中，我们了解了怎么从一个包中获取内容。\n \n-We set up highly custom refspecs in order to make `git fetch` do something a little different than the default in <<_getting_notes>> and <<_refspec>>.\n+在 <<_getting_notes>> 和 <<_refspec>> 章节中我们设置了高度自定义的 `refspec` 以便 `git fetch` 可以做一些跟默认不同的事情。\n \n ==== git pull\n \n-The `git pull` command is basically a combination of the `git fetch` and `git merge` commands, where Git will fetch from the remote you specify and then immediately try to merge it into the branch you're on.\n+`git pull` 命令基本上就是 `git fetch` 和 `git merge` 命令的组合体，Git 从你指定的远程仓库中抓取内容，然后马上尝试将其合并进你所在的分支中。\n \n-We introduce it quicking in <<_fetching_and_pulling>> and show how to see what it will merge if you run it in <<_inspecting_remote>>.\n+我们在 <<_fetching_and_pulling>> 一节中快速介绍了此命令，然后在 <<_inspecting_remote>> 一节中了解了如果你运行此命令的话，什么将会合并。\n \n-We also see how to use it to help with rebasing difficulties in <<_rebase_rebase>>.\n+我们也在 <<_rebase_rebase>> 一节中了解了如何使用此命令来来处理变基的难题。\n \n-We show how to use it with a URL to pull in changes in a one-off fashion in <<_checking_out_remotes>>.\n+在 <<_checking_out_conflicts>> 一节中我们展示了使用此命令如何通过一个 URL 来一次性的拉取变更。\n \n-Finally, we very quickly mention that you can use the `--verify-signatures` option to it in order to verify that commits you are pulling have been GPG signed in <<_signing_commits>>.\n+最后，我们在 <<_signing_commits>> 一节中我们快速的介绍了你可以使用 `--verify-signatures` 选项来验证你正在拉取下来的经过 GPG 签名的提交。\n \n ==== git push\n \n-The `git push` command is used to communicate with another repository, calculate what your local database has that the remote one does not, and then pushes the difference into the other repository. It requires write access to the other repository and so normally is authenticated somehow.\n+`git push` 命令用来与另一个仓库通信，计算你本地数据库与远程仓库的差异，然后将差异推送到另一个仓库中。它需要有另一个仓库的写权限，因此这通常是需要验证的。\n \n-We first look at the `git push` command in <<_pushing_remotes>>. Here we cover the basics of pushing a branch to a remote repository. In <<_pushing_branches>> we go a little deeper into pushing specific branches and in <<_tracking_branches>> we see how to set up tracking branches to automatically push to. In <<_delete_branches>> we use the `--delete` flag to delete a branch on the server with `git push`.\n+我们开始在 <<_pushing_remotes>> 一节中介绍了 `git push` 命令。在这一节中主要介绍了推送一个分支到远程仓库的基本用法。在 <<_pushing_branches>> 一节中，我们深入了解了如何推送指定分支，在 <<_tracking_branches>> 一节中我们了解了如何设置一个默认的推送的跟踪分支。在 <<_delete_branches>> 一节中我们使用 `--delete` 标志和 `git push` 命令来在删除一个在服务器上的分支。\n \n-Throughout <<_contributing_project>> we see several examples of using `git push` to share work on branches through multiple remotes.\n+在 <<_contributing_project>> 一整节中，我们看到了几个使用 `git push` 在多个远程仓库分享分支中的工作的示例。\n \n-We see how to use it to share tags that you have made with the `--tags` option in <<_sharing_tags>>.\n+在 <<_sharing_tags>> 一节中，我们知道了如何使用此命令加 `--tags` 选项来分享你打的标签。\n \n-In <<_sharing_notes>> we use it in a slightly less common way to share references for commit notes -- references that sit outside of the normal refs namespace.\n+在 <<_sharing_notes>> 一节中我们以一种不太常用的方式来分享提交注释的引用--在正常的 refs 空间之外的引用。\n \n-In <<_publishing_submodules>> we use the `--recurse-submodules` option to check that all of our submodules work has been published before pushing the superproject, which can be really helpful when using submodules.\n+在 <<_publishing_submodules>> 一节中，我们使用 `--recurse-submodules` 选项来检查是否我们所有的子模块的工作都已经在推送子项目之前已经推送出去了，当使用子模块时这真的很有帮助。\n \n-In <<_other_client_hooks>> we talk briefly about the `pre-push` hook, which is a script we can setup to run before a push completes to verify that it should be allowed to push.\n+在 <<_other_client_hooks>> 中我们简单的提到了 `pre-push` 挂钩（hook），它是一个可以用来设置成在一个推送完成之前运行的脚本，以检查推送是否被允许。\n \n-Finally, in <<_pushing_refspecs>> we look at pushing with a full refspec instead of the general shortcuts that are normally used. This can help you be very specific about what work you wish to share.\n+最后，在 <<_pushing_refspecs>> 一节中，我们知道了使用完整的 refspec 来推送，而不是通常使用的简写形式。 这对我们精确的指定要分享出去的工作很有帮助。\n \n ==== git remote\n \n-The `git remote` command is a management tool for your record of remote repositories. It allows you to save long URLs as short handles, such as ``origin'' so you don't have to type them out all the time. You can have several of these and the `git remote` command is used to add, change and delete them.\n+`git remote` 命令是一个是你远程仓库记录的管理工具。它允许你将一个长的 URL 保存成一个简写的句柄，例如 `origin` ，这样你就可以不用每次都输入他们了。你可以有多个这样的句柄，`git remote` 可以用来添加，修改，及删除它们。\n \n-This command is covered in detail in <<_remote_repos>>, including listing, adding, removing and renaming them.\n+此命令在 <<_remote_repos>> 一节中做了详细的介绍，包括列举、添加、移除、重命名功能。\n \n-It is used in nearly every subsequent chapter in the book too, but always in the standard `git remote add <name> <url>` format.\n+几乎在此书的后续章节中都有使用此命令，但是一般是以 `git remote add <name> <url>` 这样的标准格式。\n \n ==== git archive\n \n-The `git archive` command is used to create an archive file of a specific snapshot of the project.\n+`git archive` 命令用来创建项目一个指定快照的归档文件。\n \n-We use `git archive` to create a tarball of a project for sharing in <<_preparing_release>>.\n+我们在 <<_preparing_release>> 一节中，使用 `git archive` 命令来创建一个项目的归档文件用于分享。\n \n ==== git submodule\n \n-The `git submodule` command is used to manage external repositories within a normal repositories. This could be for libraries or other types of shared resources. The `submodule` command has several sub-commands (`add`, `update`, `sync`, etc) for managing these resources.\n+`git submodule` 命令用来管理一个仓库的其他外部仓库。可以用在库或者其他类型的共享资源上。`submodule` 命令有几个子命令, 如（`add`、`update`、`sync` 等等）用来管理这些资源。\n \n-This command is only mentioned and entirely covered in <<_git_submodules>>.\n+只在 <<_git_submodules>> 章节中提到和详细介绍了此命令。\n \n-=== Inspection and Comparison\n+=== 内省与比较 （Inspection and Comparison）\n \n ==== git show\n \n-The `git show` command can show a Git object in a simple and human readable way. Normally you would use this to show the information about a tag or a commit.\n+`git show` 命令可以以一种简单的人类可读的方式来显示一个 Git 对象。你一般使用此命令来显示一个标签或一个提交的信息。\n \n-We first use it to show annotated tag information in <<_annotated_tags>>.\n+我们在 <<_annotated_tags>> 一节中使用此命令来显示带注解标签的信息。\n \n-Later we use it quite a bit in <<_revision_selection>> to show the commits that our various revision selections resolve to.\n+然后，我们在 <<_revision_selection>> 一节中，用了很多次来显示不同的版本选择将解析出来的提交。\n \n-One of the more interesting things we do with `git show` is in <<_manual_remerge>> to extract specific file contents of various stages during a merge conflict.\n+我们使用 `git show` 做的最有意思的事情是在 <<_manual_remerge>> 一节中用来在合并冲突的多个暂存区域中提取指定文件的内容。\n \n ==== git shortlog\n \n-The `git shortlog` command is used to summarize the output of `git log`. It will take many of the same options that the `git log` command will but instead of listing out all of the commits it will present a summary of the commits grouped by author.\n+`git shortlog` 是一个用来归纳 `git log` 的输出的命令。它可以接受很多与 `git log` 相同的选项，但是此命令并不会列出所有的提交，而是展示一个根据作者分组的提交记录的概括性信息\n \n-We showed how to use it to create a nice changelog in <<_the_shortlog>>.\n+我们在 <<_the_shortlog>> 一节中展示了如何使用此命令来创建一个漂亮的 changelog 文件。\n \n ==== git describe\n \n-The `git describe` command is used to take anything that resolves to a commit and produces a string that is somewhat human-readable and will not change. It's a way to get a description of a commit that is as unambiguous as a commit SHA but more understandable.\n-\n-We use `git describe` in <<_build_number>> and <<_preparing_release>> to get a string to name our release file after.\n+`git describe` 命令用来接受任何可以解析成一个提交的东西，然后生成一个人类可读的字符串且不可变。这是一种获得一个提交的描述的方式，它跟一个提交的 SHA 值一样是无歧义，但是更具可读性。\n \n+我们在 <<_build_number>> 及 <<_preparing_release>> 章节中使用 `git describe` 命令来获得一个字符串来命名我们发布的文件。\n \n-=== Debugging\n+=== 调试 （Debugging）\n \n-Git has a couple of commands that are used to help debug an issue in your code. This ranges from figuring out where something was introduced to figuring out who introduced it.\n+Git 有一些命令可以用来帮你调试你代码中的问题。包括找出是什么时候，是谁引入的变更。\n \n ==== git bisect\n \n-The `git bisect` tool is an incredibly helpful debugging tool used to find which specific commit was the first one to introduce a bug or problem by doing an automatic binary search.\n+`git bisect` 工具是一个非常有用的调试工具，它通过自动进行一个二分查找来找到哪一个特定的提交是导致 bug 或者问题的第一个提交。\n \n-It is fully covered in <<_binary_search>> and is only mentioned in that section.\n+仅在 <<_binary_search>> 一节中完整的介绍了此命令。\n \n ==== git blame\n \n-The `git blame` command annotates the lines of any file with which commit was the last one to introduce a change to each line of the file and what person authored that commit. This is helpful in order to find the person to ask for more information about a specific section of your code.\n+`git blame` 命令标注任何文件的行，指出文件的每一行的最后的变更的提交及谁是那一个提交的作者。\n \n-It is covered in <<_file_annotation>> and is only mentioned in that section.\n+只有 <<_file_annotation>> 一节有中提到此命令。\n \n ==== git grep\n \n-The `git grep` command can help you find any string or regular expression in any of the files in your source code, even older versions of your project.\n+`git grep` 命令可以帮助在源代码中，甚至是你项目的老版本中的任意文件中查找任何字符串或者正则表达式。\n \n-It is covered in <<_git_grep>> and is only mentioned in that section.\n+只有 <<_git_grep>> 的章节中与提到此命令。\n \n-=== Patching\n+=== 补丁 （Patching）\n \n-A few commands in Git are centered around the concept of thinking of commits in terms of the changes they introduce, as thought the commit series is a series of patches. These commands help you manage your branches in this manner.\n+Git 中的一些命令是以引入的变更即提交这样的概念为中心的，这样一系列的提交，就是一系列的补丁。这些命令以这样的方式来管理你的分支。\n \n ==== git cherry-pick\n \n-The `git cherry-pick` command is used to take the change introduced in a single Git commit and try to re-introduce it as a new commit on the branch you're currently on. This can be useful to only take one or two commits from a branch individually rather than merging in the branch which takes all the changes.\n+`git cherry-pick` 命令用来获得在单个提交中引入的变更，然后尝试将作为一个新的提交引入到你当前分支上。从一个分支单独一个或者两个提交而不是合并整个分支的所有变更是非常有用的。\n \n-Cherry picking is described and demonstrated in <<_rebase_cherry_pick>>.\n+在 <<_rebase_cherry_pick>> 一节中描述和演示了 `Cherry picking`\n \n ==== git rebase\n \n-The `git rebase` command is basically an automated `cherry-pick`. It determines a series of commits and then cherry-picks them one by one in the same order somewhere else.\n+`git rebase` 命令基本是是一个自动化的 `cherry-pick` 命令。它计算出一系列的提交，然后再以它们在其他地方以同样的顺序一个一个的 `cherry-picks` 出它们\n \n-Rebasing is covered in detail in <<_rebasing>>, including covering the collaborative issues involved with rebasing branches that are already public.\n+在 <<_rebasing>> 一章中详细提到了此命令，包括与已经公开的分支的变基所涉及的协作问题。\n \n-We use it in practice during an example of splitting your history into two separate repositories in <<_replace>>, using the `--onto` flag as well.\n+在 <<_replace>> 中我们在一个分离历史记录到两个单独的仓库的示例中实践了此命令，同时使用了 `--onto` 选项。\n \n-We go through running into a merge conflict during rebasing in <<_rerere>>.\n+在 <<_rerere>> 一节中，我们研究了在变基时遇到的合并冲突的问题。\n \n-We also use it in an interactive scripting mode with the `-i` option in <<_changing_multiple>>.\n+在 <<_changing_multiple>> 一节中，我们也结合 `-i` 选项将其用于交互式的脚本模式。\n \n ==== git revert\n \n-The `git revert` command is essentially a reverse `git cherry-pick`. It creates a new commit that applies the exact opposite of the change introduced in the commit you're targeting, essentially undoing or reverting it.\n \n-We use this in <<_reverse_commit>> to undo a merge commit.\n+`git revert` 命令本质上就是一个逆向的 `git cherry-pick` 操作。它将你提交中的变更的以完全相反的方式的应用到一个新创建的提交中，本质上就是撤销或者倒转。\n+\n+我们在 <<_reverse_commit>> 一节中使用此命令来撤销一个合并提交。\n \n-=== Email\n+=== 邮件 （Email）\n \n-Many Git projects, including Git itself, are entirely maintained over mailing lists. Git has a number of tools built into it that help make this process easier, from generating patches you can easily email to applying those patches from an email box.\n+很多 Git 项目，包括 Git 本身，基本是通过邮件列表来维护的。Git 有一些工具用来让帮助此操作变简单的工具，从生成方便邮件的补丁到从一个邮箱中应用这些补丁。\n \n ==== git apply\n \n-The `git apply` command applies a patch created with the `git diff` or even GNU diff command. It is similar to what the `patch` command might do with a few small differences.\n+`git apply` 命令应用一个通过 `git diff` 或者甚至使用 GNU diff 命令创建的补丁。它跟补丁命令做了差不多的工作，有一些小小的差别。\n \n-We demonstrate using it and the circumstances in which you might do so in <<_patches_from_email>>.\n+我们在 <<_patches_from_email>> 一节中演示了它的使用及什么环境下你可能会用到它。\n \n ==== git am\n \n-The `git am` command is used to apply patches from an email inbox, specifically one that is mbox formatted. This is useful for receiving patches over email and applying them to your project easily.\n+`git am` 命令用来应用来自邮箱的补丁。特别是那些被 mbox 格式化过的。这对于通过邮件接受补丁并将他们轻松地应用到你的项目中很有用。\n \n-We covered usage and workflow around `git am` in <<_git_am>> including using the `--resolved`, `-i` and `-3` options.\n+我们在 <<_git_am>> 命令中提到了它的用法及工作流，包括使用 `--resolved`、`-i` 及 `-3` 选项。\n \n-There are also a number of hooks you can use to help with the workflow around `git am` and they are all covered in <<_email_hooks>>.\n+我们在 <<_email_hooks>> 也提到了几条 hooks，你可以用来辅助与 `git am` 相关工作流。\n \n-We also use it to apply patch formatted GitHub Pull Request changes in <<_email_notifications>>.\n+在 <<_email_notifications>> 一节中我们也将用此命令来应用 格式化的 GitHub的推送请求的变更。\n \n ==== git format-patch\n \n-The `git format-patch` command is used to generate a series of patches in mbox format that you can use to send to a mailing list properly formatted.\n \n-We go through an example of contributing to a project using the `git format-patch` tool in <<_project_over_email>>.\n+`git format-patch` 命令用来以 mbox 的格式来生成一系列的补丁以便你可以发送到一个邮件列表中。\n+\n+我们在 <<_project_over_email>> 一节中研究了一个使用 `git format-patch` 工具为一个项目做贡献的示例\n \n ==== git send-email\n \n-The `git send-email` command is used to send patches that are generated with `git format-patch` over email.\n+`git send-mail` 命令用来通过邮件发送那些使用 `git format-patch` 生成的补丁。\n \n-We go through an example of contributing to a project by sending patches with the `git send-email` tool in <<_project_over_email>>.\n+我们在 <<_project_over_email>> 一节中研究了一个使用 `git send-email` 工具发送补丁来为一个项目做贡献的示例。\n \n ==== git request-pull\n \n-The `git request-pull` command is simply used to generate an example message body to email to someone. If you have a branch on a public server and want to let someone know how to integrate those changes without sending the patches over email, you can run this command and send the output to the person you want to pull the changes in.\n+`git request-pull` 命令只是简单的用来生成一个可通过邮件发送给某个人的示例信息体。如果你在公共服务器上有一个分支，并且想让别人知道如何集成这些变更，而不用通过邮件发送补丁，你就可以执行此命令的输出发送给这个你想拉取变更的人。\n \n-We demonstrate how to use `git request-pull` to generate a pull message in <<_public_project>>.\n+我们在 <<_public_project>> 一节中演示了如何使用 `git request-pull` 来生成一个推送消息。\n \n-=== External Systems\n+===  外部系统 （External Systems）\n \n-Git comes with a few commands to integrate with other version control systems.\n+Git 有一些可以与其他的版本控制系统集成的命令。\n \n ==== git svn\n \n-The `git svn` command is used to communicate with the Subversion version control system as a client. This means you can use Git to checkout from and commit to a Subversion server.\n+`git svn` 可以使 Git 作为一个客户端来与 Subversion 版本控制系统通信。这意味着你可以使用 Git 来检出内容，或者提交到 Subversion 服务器。\n \n-This command is covered in depth in <<_git_svn>>.\n+<<_git_svn>> 一章深入讲解了此命令。\n \n ==== git fast-import\n \n-For other version control systems or importing from nearly any format, you can use `git fast-import` to quickly map the other format to something Git can easily record.\n+对于其他版本控制系统或者从其他任何的格式导入，你可以使用 `git fast-import` 快速地将其他格式映射到 Git 可以轻松记录的格式。\n \n-This command is coverd in depth in <<_custom_importer>>.\n+在 <<_custom_importer>> 一节中深入讲解了此命令。\n \n-=== Administration\n+=== 管理 （Administration）\n \n-If you're administering a Git repository or need to fix something in a big way, Git provides a number of administrative commands to help you out.\n+如果你正在管理一个 Git 仓库，或者需要通过一个复杂的方法来修复某些东西，Git 提供了一些管理命令来帮助你。\n \n ==== git gc\n \n-The `git gc` command runs ``garbage collection'' on your repository, removing unnecessary files in your database and packing up the remaining files into a more efficient format.\n+`git gc` 命令在你的仓库中执行 ``garbage collection'' ，删除数据库中不需要的文件和将其他文件打包成一种更有效的格式。\n \n-This command normally runs in the background for you, though you can manually run it if you wish. We go over some examples of this in <<_git_gc>>.\n+此命令一般在背后为你工作，虽然你可以手动执行它-如果你想的话。我们在<<_git_gc>> 一节中研究此命令的几个示例。\n \n ==== git fsck\n \n-The `git fsck` command is used to check the internal database for problems or inconsistencies.\n \n-We only quickly use this once in <<_data_recovery>> to search for dangling objects.\n+`git fsck` 命令用来检查内部数据库的问题或者不一致性。\n+\n+我们只在 <<_data_recovery>> 这一节中快速使用了一次此命令来搜索所有的漂流对象（dangling object）。\n \n ==== git reflog\n \n-The `git reflog` command goes through a log of where all the heads of your branches have been as you work to find commits you may have lost through rewriting histories.\n+`git reflog` 命令分析你所有分支的头日志来查找出你在重写历史上可能丢失的提交。\n \n-We cover this command mainly in <<_git_reflog>>, where we show normal usage to and how to use `git log -g` to view the same information with `git log` output.\n+我们主要在 <<_git_reflog>> 一节中提到了此命令。在那我们展示了一般用法，及如何使用 `git log -g` 配合 `git log` 的输出来查看同样的信息。\n \n-We also go through a practical example of recovering such a lost branch in <<_data_recovery>>.\n+我们同样在 <<_data_recovery>> 一节中研究了恢复一个丢失的分支的实例。\n \n ==== git filter-branch\n \n-The `git filter-branch` command is used to rewrite loads of commits according to certain patterns, like removing a file everywhere or filtering the entire repository down to a single subdirectory for extracting a project.\n-\n-In <<_removing_file_every_commit>> we explain the command and explore several different options such as `--commit-filter`, `--subdirectory-filter` and `--tree-filter`.\n+`git filter-branch` 命令用来根据一定的规则来重写大量的提交记录，例如从任何地方删除一个文件，或者通过过滤一个仓库中的一个单独的子目录以提取出一个项目。","path":"book/C-git-commands/1-git-commands.asc","position":652,"original_position":652,"commit_id":"855592ceb0ac650c12314ae56776afaae24a29e8","original_commit_id":"42c0efdce6b8e7bf825c1d62db205cd9c1318cfb","user":{"login":"byr-gdp","id":9307206,"avatar_url":"https://avatars.githubusercontent.com/u/9307206?v=3","gravatar_id":"","url":"https://api.github.com/users/byr-gdp","html_url":"https://github.com/byr-gdp","followers_url":"https://api.github.com/users/byr-gdp/followers","following_url":"https://api.github.com/users/byr-gdp/following{/other_user}","gists_url":"https://api.github.com/users/byr-gdp/gists{/gist_id}","starred_url":"https://api.github.com/users/byr-gdp/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/byr-gdp/subscriptions","organizations_url":"https://api.github.com/users/byr-gdp/orgs","repos_url":"https://api.github.com/users/byr-gdp/repos","events_url":"https://api.github.com/users/byr-gdp/events{/privacy}","received_events_url":"https://api.github.com/users/byr-gdp/received_events","type":"User","site_admin":false},"body":"* certain patterns 译为 `某些规则` 是否更好\r\n* 从任何地方删除<del>一个</del>文件，`或者通过过滤仓库的单独子目录以提取项目`。","created_at":"2015-07-26T08:10:58Z","updated_at":"2015-07-26T08:10:58Z","html_url":"https://github.com/progit/progit2-zh/pull/138#discussion_r35490375","pull_request_url":"https://api.github.com/repos/progit/progit2-zh/pulls/138","_links":{"self":{"href":"https://api.github.com/repos/progit/progit2-zh/pulls/comments/35490375"},"html":{"href":"https://github.com/progit/progit2-zh/pull/138#discussion_r35490375"},"pull_request":{"href":"https://api.github.com/repos/progit/progit2-zh/pulls/138"}}},"pull_request":{"url":"https://api.github.com/repos/progit/progit2-zh/pulls/138","id":38180246,"html_url":"https://github.com/progit/progit2-zh/pull/138","diff_url":"https://github.com/progit/progit2-zh/pull/138.diff","patch_url":"https://github.com/progit/progit2-zh/pull/138.patch","issue_url":"https://api.github.com/repos/progit/progit2-zh/issues/138","number":138,"state":"open","locked":false,"title":"Translate C-git-comands 1-git-commands","user":{"login":"banxi1988","id":726774,"avatar_url":"https://avatars.githubusercontent.com/u/726774?v=3","gravatar_id":"","url":"https://api.github.com/users/banxi1988","html_url":"https://github.com/banxi1988","followers_url":"https://api.github.com/users/banxi1988/followers","following_url":"https://api.github.com/users/banxi1988/following{/other_user}","gists_url":"https://api.github.com/users/banxi1988/gists{/gist_id}","starred_url":"https://api.github.com/users/banxi1988/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/banxi1988/subscriptions","organizations_url":"https://api.github.com/users/banxi1988/orgs","repos_url":"https://api.github.com/users/banxi1988/repos","events_url":"https://api.github.com/users/banxi1988/events{/privacy}","received_events_url":"https://api.github.com/users/banxi1988/received_events","type":"User","site_admin":false},"body":"那先发初稿的PR\r\n标点，格式我问题我自己处理。其他翻译考虑大学帮看看。","created_at":"2015-06-21T07:00:07Z","updated_at":"2015-07-26T08:10:58Z","closed_at":null,"merged_at":null,"merge_commit_sha":"0b30dd70528ccc81ec7d7994e0161a88bb327093","assignee":null,"milestone":null,"commits_url":"https://api.github.com/repos/progit/progit2-zh/pulls/138/commits","review_comments_url":"https://api.github.com/repos/progit/progit2-zh/pulls/138/comments","review_comment_url":"https://api.github.com/repos/progit/progit2-zh/pulls/comments{/number}","comments_url":"https://api.github.com/repos/progit/progit2-zh/issues/138/comments","statuses_url":"https://api.github.com/repos/progit/progit2-zh/statuses/855592ceb0ac650c12314ae56776afaae24a29e8","head":{"label":"banxi1988:C-git-commands","ref":"C-git-commands","sha":"855592ceb0ac650c12314ae56776afaae24a29e8","user":{"login":"banxi1988","id":726774,"avatar_url":"https://avatars.githubusercontent.com/u/726774?v=3","gravatar_id":"","url":"https://api.github.com/users/banxi1988","html_url":"https://github.com/banxi1988","followers_url":"https://api.github.com/users/banxi1988/followers","following_url":"https://api.github.com/users/banxi1988/following{/other_user}","gists_url":"https://api.github.com/users/banxi1988/gists{/gist_id}","starred_url":"https://api.github.com/users/banxi1988/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/banxi1988/subscriptions","organizations_url":"https://api.github.com/users/banxi1988/orgs","repos_url":"https://api.github.com/users/banxi1988/repos","events_url":"https://api.github.com/users/banxi1988/events{/privacy}","received_events_url":"https://api.github.com/users/banxi1988/received_events","type":"User","site_admin":false},"repo":{"id":37563856,"name":"progit2-zh","full_name":"banxi1988/progit2-zh","owner":{"login":"banxi1988","id":726774,"avatar_url":"https://avatars.githubusercontent.com/u/726774?v=3","gravatar_id":"","url":"https://api.github.com/users/banxi1988","html_url":"https://github.com/banxi1988","followers_url":"https://api.github.com/users/banxi1988/followers","following_url":"https://api.github.com/users/banxi1988/following{/other_user}","gists_url":"https://api.github.com/users/banxi1988/gists{/gist_id}","starred_url":"https://api.github.com/users/banxi1988/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/banxi1988/subscriptions","organizations_url":"https://api.github.com/users/banxi1988/orgs","repos_url":"https://api.github.com/users/banxi1988/repos","events_url":"https://api.github.com/users/banxi1988/events{/privacy}","received_events_url":"https://api.github.com/users/banxi1988/received_events","type":"User","site_admin":false},"private":false,"html_url":"https://github.com/banxi1988/progit2-zh","description":"","fork":true,"url":"https://api.github.com/repos/banxi1988/progit2-zh","forks_url":"https://api.github.com/repos/banxi1988/progit2-zh/forks","keys_url":"https://api.github.com/repos/banxi1988/progit2-zh/keys{/key_id}","collaborators_url":"https://api.github.com/repos/banxi1988/progit2-zh/collaborators{/collaborator}","teams_url":"https://api.github.com/repos/banxi1988/progit2-zh/teams","hooks_url":"https://api.github.com/repos/banxi1988/progit2-zh/hooks","issue_events_url":"https://api.github.com/repos/banxi1988/progit2-zh/issues/events{/number}","events_url":"https://api.github.com/repos/banxi1988/progit2-zh/events","assignees_url":"https://api.github.com/repos/banxi1988/progit2-zh/assignees{/user}","branches_url":"https://api.github.com/repos/banxi1988/progit2-zh/branches{/branch}","tags_url":"https://api.github.com/repos/banxi1988/progit2-zh/tags","blobs_url":"https://api.github.com/repos/banxi1988/progit2-zh/git/blobs{/sha}","git_tags_url":"https://api.github.com/repos/banxi1988/progit2-zh/git/tags{/sha}","git_refs_url":"https://api.github.com/repos/banxi1988/progit2-zh/git/refs{/sha}","trees_url":"https://api.github.com/repos/banxi1988/progit2-zh/git/trees{/sha}","statuses_url":"https://api.github.com/repos/banxi1988/progit2-zh/statuses/{sha}","languages_url":"https://api.github.com/repos/banxi1988/progit2-zh/languages","stargazers_url":"https://api.github.com/repos/banxi1988/progit2-zh/stargazers","contributors_url":"https://api.github.com/repos/banxi1988/progit2-zh/contributors","subscribers_url":"https://api.github.com/repos/banxi1988/progit2-zh/subscribers","subscription_url":"https://api.github.com/repos/banxi1988/progit2-zh/subscription","commits_url":"https://api.github.com/repos/banxi1988/progit2-zh/commits{/sha}","git_commits_url":"https://api.github.com/repos/banxi1988/progit2-zh/git/commits{/sha}","comments_url":"https://api.github.com/repos/banxi1988/progit2-zh/comments{/number}","issue_comment_url":"https://api.github.com/repos/banxi1988/progit2-zh/issues/comments{/number}","contents_url":"https://api.github.com/repos/banxi1988/progit2-zh/contents/{+path}","compare_url":"https://api.github.com/repos/banxi1988/progit2-zh/compare/{base}...{head}","merges_url":"https://api.github.com/repos/banxi1988/progit2-zh/merges","archive_url":"https://api.github.com/repos/banxi1988/progit2-zh/{archive_format}{/ref}","downloads_url":"https://api.github.com/repos/banxi1988/progit2-zh/downloads","issues_url":"https://api.github.com/repos/banxi1988/progit2-zh/issues{/number}","pulls_url":"https://api.github.com/repos/banxi1988/progit2-zh/pulls{/number}","milestones_url":"https://api.github.com/repos/banxi1988/progit2-zh/milestones{/number}","notifications_url":"https://api.github.com/repos/banxi1988/progit2-zh/notifications{?since,all,participating}","labels_url":"https://api.github.com/repos/banxi1988/progit2-zh/labels{/name}","releases_url":"https://api.github.com/repos/banxi1988/progit2-zh/releases{/id}","created_at":"2015-06-17T00:43:44Z","updated_at":"2015-06-17T00:43:46Z","pushed_at":"2015-07-26T07:27:31Z","git_url":"git://github.com/banxi1988/progit2-zh.git","ssh_url":"git@github.com:banxi1988/progit2-zh.git","clone_url":"https://github.com/banxi1988/progit2-zh.git","svn_url":"https://github.com/banxi1988/progit2-zh","homepage":null,"size":159643,"stargazers_count":0,"watchers_count":0,"language":"CSS","has_issues":false,"has_downloads":true,"has_wiki":true,"has_pages":false,"forks_count":0,"mirror_url":null,"open_issues_count":0,"forks":0,"open_issues":0,"watchers":0,"default_branch":"master"}},"base":{"label":"progit:master","ref":"master","sha":"af9ee732e6977aa621e30c8ceb152375f0911346","user":{"login":"progit","id":95588,"avatar_url":"https://avatars.githubusercontent.com/u/95588?v=3","gravatar_id":"","url":"https://api.github.com/users/progit","html_url":"https://github.com/progit","followers_url":"https://api.github.com/users/progit/followers","following_url":"https://api.github.com/users/progit/following{/other_user}","gists_url":"https://api.github.com/users/progit/gists{/gist_id}","starred_url":"https://api.github.com/users/progit/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/progit/subscriptions","organizations_url":"https://api.github.com/users/progit/orgs","repos_url":"https://api.github.com/users/progit/repos","events_url":"https://api.github.com/users/progit/events{/privacy}","received_events_url":"https://api.github.com/users/progit/received_events","type":"Organization","site_admin":false},"repo":{"id":26017730,"name":"progit2-zh","full_name":"progit/progit2-zh","owner":{"login":"progit","id":95588,"avatar_url":"https://avatars.githubusercontent.com/u/95588?v=3","gravatar_id":"","url":"https://api.github.com/users/progit","html_url":"https://github.com/progit","followers_url":"https://api.github.com/users/progit/followers","following_url":"https://api.github.com/users/progit/following{/other_user}","gists_url":"https://api.github.com/users/progit/gists{/gist_id}","starred_url":"https://api.github.com/users/progit/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/progit/subscriptions","organizations_url":"https://api.github.com/users/progit/orgs","repos_url":"https://api.github.com/users/progit/repos","events_url":"https://api.github.com/users/progit/events{/privacy}","received_events_url":"https://api.github.com/users/progit/received_events","type":"Organization","site_admin":false},"private":false,"html_url":"https://github.com/progit/progit2-zh","description":"","fork":false,"url":"https://api.github.com/repos/progit/progit2-zh","forks_url":"https://api.github.com/repos/progit/progit2-zh/forks","keys_url":"https://api.github.com/repos/progit/progit2-zh/keys{/key_id}","collaborators_url":"https://api.github.com/repos/progit/progit2-zh/collaborators{/collaborator}","teams_url":"https://api.github.com/repos/progit/progit2-zh/teams","hooks_url":"https://api.github.com/repos/progit/progit2-zh/hooks","issue_events_url":"https://api.github.com/repos/progit/progit2-zh/issues/events{/number}","events_url":"https://api.github.com/repos/progit/progit2-zh/events","assignees_url":"https://api.github.com/repos/progit/progit2-zh/assignees{/user}","branches_url":"https://api.github.com/repos/progit/progit2-zh/branches{/branch}","tags_url":"https://api.github.com/repos/progit/progit2-zh/tags","blobs_url":"https://api.github.com/repos/progit/progit2-zh/git/blobs{/sha}","git_tags_url":"https://api.github.com/repos/progit/progit2-zh/git/tags{/sha}","git_refs_url":"https://api.github.com/repos/progit/progit2-zh/git/refs{/sha}","trees_url":"https://api.github.com/repos/progit/progit2-zh/git/trees{/sha}","statuses_url":"https://api.github.com/repos/progit/progit2-zh/statuses/{sha}","languages_url":"https://api.github.com/repos/progit/progit2-zh/languages","stargazers_url":"https://api.github.com/repos/progit/progit2-zh/stargazers","contributors_url":"https://api.github.com/repos/progit/progit2-zh/contributors","subscribers_url":"https://api.github.com/repos/progit/progit2-zh/subscribers","subscription_url":"https://api.github.com/repos/progit/progit2-zh/subscription","commits_url":"https://api.github.com/repos/progit/progit2-zh/commits{/sha}","git_commits_url":"https://api.github.com/repos/progit/progit2-zh/git/commits{/sha}","comments_url":"https://api.github.com/repos/progit/progit2-zh/comments{/number}","issue_comment_url":"https://api.github.com/repos/progit/progit2-zh/issues/comments{/number}","contents_url":"https://api.github.com/repos/progit/progit2-zh/contents/{+path}","compare_url":"https://api.github.com/repos/progit/progit2-zh/compare/{base}...{head}","merges_url":"https://api.github.com/repos/progit/progit2-zh/merges","archive_url":"https://api.github.com/repos/progit/progit2-zh/{archive_format}{/ref}","downloads_url":"https://api.github.com/repos/progit/progit2-zh/downloads","issues_url":"https://api.github.com/repos/progit/progit2-zh/issues{/number}","pulls_url":"https://api.github.com/repos/progit/progit2-zh/pulls{/number}","milestones_url":"https://api.github.com/repos/progit/progit2-zh/milestones{/number}","notifications_url":"https://api.github.com/repos/progit/progit2-zh/notifications{?since,all,participating}","labels_url":"https://api.github.com/repos/progit/progit2-zh/labels{/name}","releases_url":"https://api.github.com/repos/progit/progit2-zh/releases{/id}","created_at":"2014-10-31T13:43:10Z","updated_at":"2015-07-24T10:08:27Z","pushed_at":"2015-07-26T07:27:31Z","git_url":"git://github.com/progit/progit2-zh.git","ssh_url":"git@github.com:progit/progit2-zh.git","clone_url":"https://github.com/progit/progit2-zh.git","svn_url":"https://github.com/progit/progit2-zh","homepage":null,"size":161088,"stargazers_count":267,"watchers_count":267,"language":"CSS","has_issues":true,"has_downloads":true,"has_wiki":true,"has_pages":false,"forks_count":96,"mirror_url":null,"open_issues_count":87,"forks":96,"open_issues":87,"watchers":267,"default_branch":"master"}},"_links":{"self":{"href":"https://api.github.com/repos/progit/progit2-zh/pulls/138"},"html":{"href":"https://github.com/progit/progit2-zh/pull/138"},"issue":{"href":"https://api.github.com/repos/progit/progit2-zh/issues/138"},"comments":{"href":"https://api.github.com/repos/progit/progit2-zh/issues/138/comments"},"review_comments":{"href":"https://api.github.com/repos/progit/progit2-zh/pulls/138/comments"},"review_comment":{"href":"https://api.github.com/repos/progit/progit2-zh/pulls/comments{/number}"},"commits":{"href":"https://api.github.com/repos/progit/progit2-zh/pulls/138/commits"},"statuses":{"href":"https://api.github.com/repos/progit/progit2-zh/statuses/855592ceb0ac650c12314ae56776afaae24a29e8"}}}}