diff --git a/docs/10.md b/docs/10.md index f72aa939c3cedab6c5e53d1ada558d68d0350b85..299bddbe705ee156b23bf456dd6ea4bbca1ab632 100644 --- a/docs/10.md +++ b/docs/10.md @@ -16,37 +16,37 @@ git reset [--soft | --mixed [-N] | --hard | --merge | --keep] [-q] [] ## 描述 -在第一种和第二种形式中，将条目从`<tree-ish>`复制到索引。在第三种形式中，将当前分支头（`HEAD`）设置为`<commit>`，可选择修改索引和工作树以匹配。所有形式的`<tree-ish>` / `<commit>`默认为`HEAD`。 +在第一种和第二种形式中，将条目从``复制到索引。在第三种形式中，将当前分支头（`HEAD`）设置为``，可选择修改索引和工作树以匹配。所有形式的`` / ``默认为`HEAD`。 ``` git reset [-q] [] [--] …​ ``` -此表单将所有`<paths>`的索引条目重置为`<tree-ish>`的状态。 （它不会影响工作树或当前分支。） +此表单将所有``的索引条目重置为``的状态。（它不会影响工作树或当前分支。） -这意味着`git reset <paths>`与`git add <paths>`相反。 +这意味着`git reset `与`git add `相反。 -运行`git reset <paths>`更新索引条目后，可以使用 [git-checkout [1]](https://git-scm.com/docs/git-checkout) 检查工作树索引中的内容。或者，使用 [git-checkout [1]](https://git-scm.com/docs/git-checkout) 并指定提交，您可以一次性将提交中的路径内容复制到索引和工作树。 +运行`git reset `更新索引条目后，可以使用 [git-checkout [1]](https://git-scm.com/docs/git-checkout) 检查工作树索引中的内容。或者，使用 [git-checkout [1]](https://git-scm.com/docs/git-checkout) 并指定提交，您可以一次性将提交中的路径内容复制到索引和工作树。 ``` git reset (--patch | -p) [] [--] […​] ``` -在索引和`<tree-ish>`之间的差异中交互式选择帅气（默认为`HEAD`）。选择的帅哥与指数相反。 +在索引和``（默认为`HEAD`）之间的差异中交互式选择某块。选择的块与索引相反。 -这意味着`git reset -p`与`git add -p`相反，即您可以使用它来选择性地重置帅哥。请参阅 [git-add [1]](https://git-scm.com/docs/git-add) 的“交互模式”部分，了解如何操作`--patch`模式。 +这意味着`git reset -p`与`git add -p`相反，即您可以使用它来选择性地重置代码块。请参阅 [git-add [1]](https://git-scm.com/docs/git-add) 的“交互模式”部分，了解如何操作`--patch`模式。 ``` git reset [] [] ``` -此表单将当前分支头重置为`<commit>`，并可能根据`<mode>`更新索引（将其重置为`<commit>`的树）和工作树。如果省略`<mode>`，则默认为`--mixed`。 `<mode>`必须是以下之一： +此表单将当前分支头重置为``，并可能根据``更新索引（将其重置为``的树）和工作树。如果省略``，则默认为`--mixed`。 ``必须是以下之一： ``` --soft ``` -根本不触摸索引文件或工作树（但将头重置为`<commit>`，就像所有模式一样）。这将保留所有已更改的文件“要提交的更改”，如`git status`所示。 +根本不接触索引文件或工作树（但将头节点重置为``，就像所有模式一样）。这将保留所有已更改的文件“要提交的更改”，如`git status`所示。 ``` --mixed @@ -60,25 +60,25 @@ git reset [--soft | --mixed [-N] | --hard | --merge | --keep] [-q] [] --hard ``` -重置索引和工作树。自`<commit>`以来对工作树中跟踪文件的任何更改都将被丢弃。 +重置索引和工作树。自``以来对工作树中跟踪文件的任何更改都将被丢弃。 ``` --merge ``` -重置索引并更新工作树中`<commit>`和`HEAD`之间不同的文件，但保留索引和工作树之间不同的文件（即具有尚未添加的更改）。如果`<commit>`和索引之间不同的文件具有未分级更改，则重置将中止。 +重置索引并更新工作树中``和`HEAD`之间不同的文件，但保留索引和工作树之间不同的文件（即具有尚未添加的更改）。如果``和索引之间不同的文件具有未暂存更改，则重置将中止。 -换句话说，`--merge`执行类似`git read-tree -u -m <commit>`的操作，但会继承未合并的索引条目。 +换句话说，`--merge`执行类似`git read-tree -u -m `的操作，但会继承未合并的索引条目。 ``` --keep ``` -重置索引条目并更新工作树中`<commit>`和`HEAD`之间不同的文件。如果`<commit>`和`HEAD`之间不同的文件具有本地更改，则重置将中止。 +重置索引条目并更新工作树中``和`HEAD`之间不同的文件。如果``和`HEAD`之间不同的文件具有本地更改，则重置将中止。 如果你想撤消除分支上最新的提交， [git-revert [1]](https://git-scm.com/docs/git-revert) 是你的朋友。 -## OPTIONS +## 选项 ``` -q @@ -110,11 +110,11 @@ $ git pull git://info.example.com/ nitfol (4) 1. 您正在愉快地处理某些事情，并发现这些文件中的更改处于良好状态。当您运行`git diff`时，您不希望看到它们，因为您计划处理其他文件，并且使用这些文件进行更改会分散注意力。 -2. 有人要求你拉，这些变化听起来值得合并。 +2. 有人要求你拉更新，这些变化听起来值得合并。 -3. 但是，您已经弄脏了索引（即您的索引与`HEAD`提交不匹配）。但是你知道你要做的拉力不会影响`frotz.c`或`filfre.c`，所以你还原这两个文件的索引变化。您在工作树中的更改仍然存在。 +3. 但是，您已经弄脏了索引（即您的索引与`HEAD`提交不匹配）。但是你知道你要做的更新不会影响`frotz.c`或`filfre.c`，所以你还原这两个文件的索引变化。您在工作树中的更改仍然存在。 -4. 然后你可以拉动和合并，在工作树中仍然保留`frotz.c`和`filfre.c`。 +4. 然后你可以更新和合并，在工作树中仍然保留`frotz.c`和`filfre.c`。 ``` Undo a commit and redo @@ -160,7 +160,7 @@ $ git commit ... $ git reset --hard HEAD~3 (1) ``` -1. 最后三次提交（`HEAD`，`HEAD^`和`HEAD~2`）很糟糕，你不想再看到它们。如果你已经将这些提交给了其他人，那么**不是**会这样做。 （有关这样做的含义，请参阅 [git-rebase [1]](https://git-scm.com/docs/git-rebase) 中的“从上游返回的恢复”部分。） +1. 最后三次提交（`HEAD`，`HEAD^`和`HEAD~2`）很糟糕，你不想再看到它们。如果你已经将这些提交给了其他人，那么**不要**这样做。 （有关这样做的含义，请参阅 [git-rebase [1]](https://git-scm.com/docs/git-rebase) 中的“从上游返回的恢复”部分。） ``` Undo a merge or pull @@ -225,7 +225,7 @@ $ git reset (3) 2. 这将从提交历史记录中删除 _WIP_ 提交，并将工作树设置为创建快照之前的状态。 -3. 此时，索引文件仍然包含您作为_快照WIP_ 提交的所有WIP更改。这将更新索引以将您的WIP文件显示为未提交。 +3. 此时，索引文件仍然包含您作为 _快照WIP_ 提交的所有WIP更改。这将更新索引以将您的WIP文件显示为未提交。 另见 [git-stash [1]](https://git-scm.com/docs/git-stash) 。 @@ -290,7 +290,7 @@ $ git commit ... (8) 2. 接下来，我们使用`git add -p`工具以交互方式选择要添加的差异。这将按顺序询问每个差异块，您可以使用简单的命令，例如“是，包括此”，“不包括此”，甚至是非常强大的“编辑”工具。 -3. 一旦对您想要包含的帅哥感到满意，您应该使用`git diff --cached`验证为第一次提交准备的内容。这显示了已移入索引并即将提交的所有更改。 +3. 一旦对您想要包含的代码块感到满意，您应该使用`git diff --cached`为第一次提交准备的内容验证。这显示了已移入索引并即将提交的所有更改。 4. 接下来，提交存储在索引中的更改。 `-c`选项指定从第一次提交中启动的原始消息预填充提交消息。这有助于避免重新输入。 `HEAD@{1}`是`HEAD`曾经在原始重置提交之前进行的提交的特殊表示法（1更改前）。有关详细信息，请参阅 [git-reflog [1]](https://git-scm.com/docs/git-reflog) 。您还可以使用任何其他有效的提交引用。 @@ -312,7 +312,7 @@ git reset --option target 根据文件的状态，使用不同的重置选项将`HEAD`重置为另一个提交（`target`）。 -在这些表中，`A`，`B`，`C`和`D`是文件的某些不同状态。例如，第一个表的第一行表示如果文件在工作树中处于状态`A`，则在索引中的状态`B`中，在`HEAD`和状态`D`中的状态`C`中在目标中，`git reset --soft target`将文件保留在状态`A`的工作树中和状态`B`的索引中。它将`HEAD`（即当前分支的尖端，如果你在其中）重置（即移动）到`target`（其文件处于状态`D`）。 +在这些表中，`A`，`B`，`C`和`D`是文件的某些不同状态。例如，第一个表的第一行表示如果文件在工作树中处于状态`A`，在索引中处于状态`B`，在`HEAD`上是状态`C`，在目标节点中是状态`D`，`git reset --soft target`将文件保留在状态`A`的工作树中和状态`B`的索引中。它将`HEAD`（即当前分支的尖端，如果你在其中）重置（即移动）到`target`（其文件处于状态`D`）。 ``` working index HEAD target working index HEAD @@ -374,7 +374,7 @@ working index HEAD target working index HEAD --keep B C C ``` -`reset --merge`用于在重置冲突合并时使用。任何mergy操作都保证合并中涉及的工作树文件在启动之前没有索引的本地更改，并且它将结果写入工作树。因此，如果我们看到索引和目标之间以及索引和工作树之间存在某些差异，那么这意味着我们不会从失败冲突后的合法操作状态重置出来。这就是我们在这种情况下不允许`--merge`选项的原因。 +`reset --merge`用于在重置合并冲突时使用。任何mergy操作都应保证在工作树中涉及的合的文件，在开始合并之前，本地索引没有相应更改，并且它将合并结果写入工作树中。因此，如果我们看到索引和目标之间以及索引和工作树之间存在某些差异，那么这意味着当由于冲突导致合并失败后，我们不能通过reset操作将状态重置出来。这就是我们在这种情况下不允许`--merge`选项的原因。 在保留当前分支中的一些最后提交的同时保留工作树中的更改时，将使用`reset --keep`。如果我们要删除的提交中的更改与我们要保留的工作树中的更改之间可能存在冲突，则不允许重置。如果工作树和`HEAD`之间以及`HEAD`和目标之间存在变化，那么就不允许这样做。为了安全起见，当有未合并的条目时也不允许这样做。