git - 简单来说， "git reset"是做什么的？

Question

我见过interesting posts解释有关 git reset 的微妙之处.

不幸的是，我读得越多，就越觉得我没有完全理解它。我来自 SVN 背景，Git 是一个全新的范式。我很容易获得 mercurial，但 Git 的技术性要高得多。

我想 git reset靠近hg revert ，但似乎存在差异。

那么究竟是什么git reset做？请包括有关以下方面的详细说明:

选项 --hard , --soft和 --merge ;

您在 HEAD 中使用的奇怪符号如 HEAD^和 HEAD~1 ;

具体用例和工作流程；

对工作副本的影响，HEAD以及您的整体压力水平。

Answer 1

一般来说，git reset的功能是获取当前分支并将其重置为指向其他地方，并可能带来索引和工作树。更具体地说，如果您的主分支(当前已 check out )是这样的:

- A - B - C (HEAD, master)

并且您意识到您希望 master 指向 B，而不是 C，您将使用 git reset B把它移到那里:

- A - B (HEAD, master)      # - C is still here, but there's no branch pointing to it anymore

题外话:这与结帐不同。如果你运行 git checkout B ，你会得到这个:

- A - B (HEAD) - C (master)

您最终处于分离的 HEAD 状态。 HEAD ，工作树，索引全部匹配 B ，但 master 分支留在了 C .如果您进行新的提交 D在这一点上，你会得到这个，这可能不是你想要的:

- A - B - C (master)
       \
        D (HEAD)

请记住，重置不会进行提交，它只是更新一个分支(它是一个指向提交的指针)以指向不同的提交。其余的只是您的索引和工作树发生的情况的详细信息。

用例

我涵盖了 git reset 的许多主要用例在下一节中我对各种选项的描述中。它真的可以用于各种各样的事情；共同点是所有这些都涉及重置分支、索引和/或工作树以指向/匹配给定的提交。

需要注意的事项

--hard可能会导致您真正失业。它会修改您的工作树。

git reset [options] commit可能会导致您(有点)丢失提交。在上面的玩具示例中，我们丢失了提交 C .它仍在 repo 中，您可以通过查看 git reflog show HEAD 找到它或 git reflog show master ，但实际上不再可以从任何分支访问它。

Git 会在 30 天后永久删除此类提交，但在此之前您可以通过再次指向 C 分支来恢复它 ( git checkout C; git branch <new branch name> )。

参数

解释手册页，最常见的用法是 git reset [<commit>] [paths...] ，这会将给定的路径从给定的提交重置为它们的状态。如果未提供路径，则重置整个树，如果未提供提交，则将其视为 HEAD(当前提交)。这是跨 git 命令的常见模式(例如 checkout、diff、log，尽管确切的语义有所不同)，因此应该不会太令人惊讶。

例如， git reset other-branch path/to/foo将 path/to/foo 中的所有内容重置为其在其他分支中的状态， git reset -- .将当前目录重置为其在 HEAD 中的状态，以及一个简单的 git reset将所有内容重置为 HEAD 中的状态。

主要工作树和索引选项

有四个主要选项可以控制重置期间工作树和索引发生的情况。

请记住，索引是 git 的“暂存区”——当你说 git add 时，它就是事情发生的地方。准备提交。

--hard使一切都与您重置​​的提交相匹配。这可能是最容易理解的。您所有的本地更改都会遭到破坏。一个主要用途是吹走你的工作而不是切换提交:git reset --hard意味着 git reset --hard HEAD ，即不要更改分支，而是摆脱所有本地更改。另一种只是将分支从一个地方移动到另一个地方，并保持索引/工作树同步。这是一个真正会让你失去工作的人，因为它会修改你的工作树。在运行任何 reset --hard 之前，请非常确定您想丢弃本地工作。 .

--mixed是默认值，即 git reset意味着 git reset --mixed .它会重置索引，但不会重置工作树。这意味着您的所有文件都完好无损，但是原始提交和您重置的提交之间的任何差异都将显示为具有 git 状态的本地修改(或未跟踪的文件)。当你意识到你做了一些错误的提交，但你想保留你所做的所有工作以便你可以修复它并重新提交时使用它。为了提交，您必须再次将文件添加到索引( git add ... )。

--soft不接触索引或工作树。您的所有文件都完好无损，就像 --mixed 一样，但所有更改都显示为 changes to be committed与 git status (即 checkin 准备提交)。当你意识到你做了一些错误的提交，但工作都很好 - 你需要做的就是以不同的方式重新提交它时使用它。索引未受影响，因此您可以根据需要立即提交 - 生成的提交将具有与您重置之前相同的所有内容。

--merge是最近添加的，旨在帮助您中止失败的 merge 。这是必要的，因为 git merge实际上，只要这些修改位于不受 merge 影响的文件中，您就可以尝试与脏工作树(具有本地修改的工作树)进行 merge 。 git reset --merge重置索引(如 --mixed - 所有更改都显示为本地修改)，并重置受 merge 影响的文件，但不理会其他文件。这有望将所有内容恢复到错误 merge 之前的状态。您通常将其用作 git reset --merge (意思是 git reset --merge HEAD )因为您只想重置 merge ，而不是实际移动分支。 ( HEAD 还没有更新，因为 merge 失败)

更具体地说，假设您已经修改了文件 A 和 B，并且您尝试在修改了文件 C 和 D 的分支中进行 merge 。由于某种原因 merge 失败，您决定中止它。您使用 git reset --merge .它将 C 和 D 带回到它们在 HEAD 中的状态，但不会单独对 A 和 B 进行修改，因为它们不是尝试 merge 的一部分。

想知道更多？

我确实认为 man git reset对此确实非常有用 - 也许您确实需要对 git 的工作方式有所了解才能真正融入其中。特别是，如果您花时间仔细阅读它们，那些详细说明索引和工作树中所有各种选项和案例的文件状态的表格非常有帮助。 (但是，是的，它们非常密集——它们以非常简洁的形式传达了大量上述信息。)

奇怪的符号

您提到的“奇怪的符号”( HEAD^ 和 HEAD~1 )只是指定提交的简写，而不必使用像 3ebe3f6 这样的哈希名称。 .它在 "specifying revisions" section 中有完整的记录。 git-rev-parse 的手册页，包含大量示例和相关语法。插入符号和波浪号实际上意味着 different things :

HEAD~ HEAD~1的缩写并表示提交的第一个父级。 HEAD~2表示提交的第一个父级的第一个父级。想想HEAD~n如“n 在 HEAD 之前提交”或“HEAD 的第 n 代祖先”。

HEAD^ (或 HEAD^1 )也表示提交的第一个父项。 HEAD^2表示提交的第二个父级。请记住，正常的 merge 提交有两个父项 - 第一个父项是 merge 到的提交，第二个父项是 merge 的提交。一般来说， merge 实际上可以有任意多个父级( Octopus merge )。

^和 ~运算符可以串在一起，如 HEAD~3^2 ，HEAD的第三代祖先的第二个亲代, HEAD^^2 ，HEAD 的第一个父级的第二个父级，甚至 HEAD^^^ ，相当于 HEAD~3 .