用简单的英语来说，“git reset”是做什么的？

In plain English, what does "git reset" do?

提问by e-satis

I have seen interesting postsexplaining subtleties about git reset.

我看过一些有趣的帖子，解释了关于git reset.

Unfortunately, the more I read about it, the more it appears that I don't understand it fully. I come from a SVN background and Git is a whole new paradigm. I got mercurial easily, but Git is much more technical.

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

I think git resetis close to hg revert, but it seems there are differences.

我认为git reset接近hg revert，但似乎存在差异。

So what exactly does git resetdo? Please include detailed explanations about:

那么具体有什么作用git reset呢？请包括有关以下方面的详细说明：

• the options --hard, --softand --merge;
• the strange notation you use with HEADsuch as HEAD^and HEAD~1;
• concrete use cases and work flows;
• consequences on the working copy, the HEADand your global stress level.

• 选项--hard,--soft和--merge;
• 你使用的奇怪符号，HEAD例如HEAD^and HEAD~1；
• 具体用例和工作流程；
• 对工作副本的影响，HEAD以及您的整体压力水平。

回答by Cascabel

In general, git reset's function is to take the current branch and reset it to point somewhere else, and possibly bring the index and work tree along. More concretely, if your master branch (currently checked out) is like this:

通常，git reset的功能是获取当前分支并将其重置为指向其他地方，并可能将索引和工作树一起带上。更具体地说，如果您的主分支（当前已检出）是这样的：

- A - B - C (HEAD, master)

and you realize you want master to point to B, not C, you will use git reset Bto move it there:

并且您意识到您希望 master 指向 B，而不是 C，您将使用git reset B它来移动它：

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

Digression: This is different from a checkout. If you'd run git checkout B, you'd get this:

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

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

You've ended up in a detached HEAD state. HEAD, work tree, index all match B, but the master branch was left behind at C. If you make a new commit Dat this point, you'll get this, which is probably not what you want:

您最终处于分离的 HEAD 状态。HEAD, 工作树, 索引都匹配B，但主分支在C. 如果您此时进行新的提交D，您会得到这个，这可能不是您想要的：

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

Remember, reset doesn't make commits, it just updates a branch (which is a pointer to a commit) to point to a different commit. The rest is just details of what happens to your index and work tree.

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

Use cases

用例

I cover many of the main use cases for git resetwithin my descriptions of the various options in the next section. It can really be used for a wide variety of things; the common thread is that all of them involve resetting the branch, index, and/or work tree to point to/match a given commit.

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

Things to be careful of

需要注意的事项

• --hardcan cause you to really lose work. It modifies your work tree.

• git reset [options] commitcan cause you to (sort of) lose commits. In the toy example above, we lost commit C. It's still in the repo, and you can find it by looking at git reflog show HEADor git reflog show master, but it's not actually accessible from any branch anymore.

• Git permanently deletes such commits after 30 days, but until then you can recover C by pointing a branch at it again (git checkout C; git branch <new branch name>).

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

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

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

Arguments

参数

Paraphrasing the man page, most common usage is of the form git reset [<commit>] [paths...], which will reset the given paths to their state from the given commit. If the paths aren't provided, the entire tree is reset, and if the commit isn't provided, it's taken to be HEAD (the current commit). This is a common pattern across git commands (e.g. checkout, diff, log, though the exact semantics vary), so it shouldn't be too surprising.

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

For example, git reset other-branch path/to/fooresets everything in path/to/foo to its state in other-branch, git reset -- .resets the current directory to its state in HEAD, and a simple git resetresets everything to its state in HEAD.

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

The main work tree and index options

主要工作树和索引选项

There are four main options to control what happens to your work tree and index during the reset.

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

Remember, the index is git's "staging area" - it's where things go when you say git addin preparation to commit.

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

• --hardmakes everything match the commit you've reset to. This is the easiest to understand, probably. All of your local changes get clobbered. One primary use is blowing away your work but not switching commits: git reset --hardmeans git reset --hard HEAD, i.e. don't change the branch but get rid of all local changes. The other is simply moving a branch from one place to another, and keeping index/work tree in sync. This is the one that can really make you lose work, because it modifies your work tree.Be very very sure you want to throw away local work before you run any reset --hard.

• --mixedis the default, i.e. git resetmeans git reset --mixed. It resets the index, but not the work tree. This means all your files are intact, but any differences between the original commit and the one you reset to will show up as local modifications (or untracked files) with git status. Use this when you realize you made some bad commits, but you want to keep all the work you've done so you can fix it up and recommit. In order to commit, you'll have to add files to the index again (git add ...).

• --softdoesn't touch the index orwork tree. All your files are intact as with --mixed, but all the changes show up as changes to be committedwith git status (i.e. checked in in preparation for committing). Use this when you realize you've made some bad commits, but the work's all good - all you need to do is recommit it differently. The index is untouched, so you can commit immediately if you want - the resulting commit will have all the same content as where you were before you reset.

• --mergewas added recently, and is intended to help you abort a failed merge. This is necessary because git mergewill actually let you attempt a merge with a dirty work tree (one with local modifications) as long as those modifications are in files unaffected by the merge. git reset --mergeresets the index (like --mixed- all changes show up as local modifications), and resets the files affected by the merge, but leaves the others alone. This will hopefully restore everything to how it was before the bad merge. You'll usually use it as git reset --merge(meaning git reset --merge HEAD) because you only want to reset away the merge, not actually move the branch. (HEADhasn't been updated yet, since the merge failed)

  To be more concrete, suppose you've modified files A and B, and you attempt to merge in a branch which modified files C and D. The merge fails for some reason, and you decide to abort it. You use git reset --merge. It brings C and D back to how they were in HEAD, but leaves your modifications to A and B alone, since they weren't part of the attempted merge.

• --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 显示（即在准备提交时签入）。当你意识到你做了一些错误的提交，但工作都很好 - 你需要做的就是以不同的方式重新提交它时使用它。索引未受影响，因此您可以根据需要立即提交 - 生成的提交将具有与您重置之前相同的所有内容。

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

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

Want to know more?

想知道更多？

I do think man git resetis really quite good for this - perhaps you do need a bit of a sense of the way git works for them to really sink in though. In particular, if you take the time to carefully read them, those tables detailing states of files in index and work tree for all the various options and cases are very very helpful. (But yes, they're very dense - they're conveying an awful lot of the above information in a very concise form.)

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

Strange notation

奇怪的符号

The "strange notation" (HEAD^and HEAD~1) you mention is simply a shorthand for specifying commits, without having to use a hash name like 3ebe3f6. It's fully documented in the "specifying revisions" sectionof the man page for git-rev-parse, with lots of examples and related syntax. The caret and the tilde actually mean different things:

您提到的“奇怪符号”（HEAD^和HEAD~1）只是指定提交的简写，而不必使用像3ebe3f6. 它在git-rev-parse 手册页的“指定修订”部分中有完整的文档，其中包含大量示例和相关语法。插入符号和波浪号实际上意味着不同的东西：

• HEAD~is short for HEAD~1and means the commit's first parent. HEAD~2means the commit's first parent's first parent. Think of HEAD~nas "n commits before HEAD" or "the nth generation ancestor of HEAD".
• HEAD^(or HEAD^1) also means the commit's first parent. HEAD^2means the commit's secondparent. Remember, a normal merge commit has two parents - the first parent is the merged-into commit, and the second parent is the commit that was merged. In general, merges can actually have arbitrarily many parents (octopus merges).
• The ^and ~operators can be strung together, as in HEAD~3^2, the second parent of the third-generation ancestor of HEAD, HEAD^^2, the second parent of the first parent of HEAD, or even HEAD^^^, which is equivalent to HEAD~3.

• HEAD~是HEAD~1并且表示提交的第一个父级的缩写。HEAD~2表示提交的第一个父级的第一个父级。可以认为HEAD~n是“在 HEAD 之前提交 n”或“HEAD 的第 n 代祖先”。
• HEAD^(或HEAD^1) 也表示提交的第一个父项。HEAD^2表示提交的第二个父级。请记住，正常的合并提交有两个父项 - 第一个父项是合并到的提交，第二个父项是合并的提交。一般来说，合并实际上可以有任意多个父项（章鱼合并）。
• 的^和~运营商可以被串在一起，如在HEAD~3^2，第三代祖先的第二亲本HEAD，HEAD^^2，的第一个亲本的第二个亲本HEAD，或甚至HEAD^^^，这相当于HEAD~3。

回答by John Feminella

Remember that in gityou have:

请记住，git您拥有：

• the HEADpointer, which tells you what commit you're working on
• the working tree, which represents the state of the files on your system
• the staging area(also called the index), which "stages" changes so that they can later be committed together

• 该HEAD指针，它告诉你什么承诺你的工作
• 在工作树，这代表你的系统上的文件的状态
• 在临时区域（也称为指数），其中“分期”的变化，让他们以后可以一起提交

Please include detailed explanations about:

--hard, --softand --merge;

请包括有关以下方面的详细说明：

--hard,--soft和--merge;

In increasing order of dangerous-ness:

按危险程度递增的顺序：

• --softmoves HEADbut doesn't touch the staging area or the working tree.
• --mixedmoves HEADand updates the staging area, but not the working tree.
• --mergemoves HEAD, resets the staging area, and tries to move all the changes in your working tree into the new working tree.
• --hardmoves HEADandadjusts your staging area and working tree to the new HEAD, throwing away everything.

• --soft移动HEAD但不接触暂存区或工作树。
• --mixed移动HEAD和更新暂存区，而不是工作树。
• --merge移动HEAD，重新设置临时区域，并试图在所有你的工作树中的变化移动到新的工作树。
• --hard移动HEAD和调整你的临时区域和工作树到新的HEAD，扔掉一切。

concrete use cases and workflows;

具体用例和工作流程；

• Use --softwhen you want to move to another commit and patch things up without "losing your place". It's pretty rare that you need this.

• 使用--soft时要移动到另一个承诺和修补的东西没有“失去你的地方。” 你很少需要这个。

--

——

# git reset --soft example
touch foo                            // Add a file, make some changes.
git add foo                          // 
git commit -m "bad commit message"   // Commit... D'oh, that was a mistake!
git reset --soft HEAD^               // Go back one commit and fix things.
git commit -m "good commit"          // There, now it's right.

--

——

• Use --mixed(which is the default) when you want to see what things look like at another commit, but you don't want to lose any changes you already have.

• Use --mergewhen you want to move to a new spot but incorporate the changes you already have into that the working tree.

• Use --hardto wipe everything out and start a fresh slate at the new commit.

• --mixed当您想查看另一次提交时的情况时使用（这是默认设置），但您不想丢失任何已有的更改。

• 使用--merge时要移动到一个新的地方，但包括你已经有了成工作树的变化。

• 使用--hard擦拭的一切，并开始一个新的石板在新的提交。

回答by Daniel Hershcovich

The post Reset Demystifiedin the blog Pro Gitgives a very no-brainerexplanation on git resetand git checkout.

博客Pro Git 中的文章Reset Demystified对和 进行了非常简单的解释。git resetgit checkout

After all the helpful discussion at the top of that post, the author reduces the rules to the following simple three steps:

在该帖子顶部进行了所有有用的讨论之后，作者将规则简化为以下简单的三个步骤：

That is basically it. The resetcommand overwrites these three trees in a specific order, stopping when you tell it to.

1. Move whatever branch HEAD points to (stop if --soft)
2. THEN, make the Index look like that (stop here unless --hard)
3. THEN, make the Working Directory look like that

There are also --mergeand --keepoptions, but I would rather keep things simpler for now - that will be for another article.

基本上就是这样。该reset命令以特定顺序覆盖这三棵树，并在您告诉它时停止。

1. 移动任何分支 HEAD 指向（如果停止--soft）
2. 然后，使索引看起来像那样（除非--hard）
3. 然后，使工作目录看起来像这样

还有--merge和--keep选项，但我现在宁愿让事情更简单——那将是另一篇文章。

回答by love

When you commit something to git you first have to stage (add to the index) your changes. This means you have to git add all the files you want to have included in this commit before git considers them part of the commit. Let's first have a look over the image of a git repo:

当您向 git 提交某些内容时，您首先必须暂存（添加到索引）您的更改。这意味着在 git 将它们视为提交的一部分之前，您必须 git add 所有要包含在此提交中的文件。让我们先看一下 git repo 的图像：

so, its simple now. We have to work in working directory, creating files, directories and all. These changes are untracked changes. To make them tracked, we need to add them to git index by using git addcommand. Once they are added to git index. We can now commit these changes, if we want to push it to git repository.

所以，现在很简单。我们必须在工作目录中工作，创建文件、目录等等。这些更改是未跟踪的更改。为了让它们被跟踪，我们需要使用git add命令将它们添加到 git index 中。一旦它们被添加到 git index. 如果我们想将其推送到 git 存储库，我们现在可以提交这些更改。

But suddenly we came to know while commiting that we have one extra file which we added in index is not required to push in git repository. It means we don't want that file in index. Now the question is how to remove that file from git index, Since we used git addto put them in the index it would be logical to use git rm? Wrong! git rmwill simply delete the file and add the deletion to the index. So what to do now:

但是突然我们在提交时发现我们在索引中添加了一个额外的文件，不需要推送到 git 存储库中。这意味着我们不希望该文件在 index.html 中。现在的问题是如何从 git index 中删除该文件，因为我们使用git add将它们放在索引中，所以使用git rm是合乎逻辑的？错误的！git rm将简单地删除文件并将删除添加到索引中。那么现在该怎么做：

Use:-

用：-

git reset

重置

It Clears your index, leaves your working directory untouched. (simply unstaging everything).

它清除您的索引，使您的工作目录保持不变。（只是取消一切）。

It can be used with number of options with it. There are three main options to use with git reset: --hard, --soft and --mixed. These affect what get's reset in addition to the HEAD pointer when you reset.

它可以与许多选项一起使用。git reset可以使用三个主要选项：--hard、--soft 和--mixed。除了重置时的 HEAD 指针之外，这些还会影响 get 的重置内容。

First, --hardresets everything. Your current directory would be exactly as it would if you had been following that branch all along. The working directory and the index are changed to that commit. This is the version that I use most often. git reset --hardis something like svn revert.

首先，-- hard重置一切。如果您一直关注该分支，您当前的目录将完全相同。工作目录和索引更改为该提交。这是我最常使用的版本。git reset --hard类似于svn revert。

Next, the complete opposite, —soft, does not reset the working tree nor the index. It only moves the HEAD pointer. This leaves your current state with any changes different than the commit you are switching to in place in your directory, and “staged” for committing. If you make a commit locally but haven't pushed the commit to the git server, you can reset to the previous commit, and recommit with a good commit message.

接下来，完全相反的—soft不会重置工作树和索引。它只移动 HEAD 指针。这使您的当前状态具有与您在目录中切换到的提交不同的任何更改，并“暂存”以进行提交。如果您在本地进行了提交但尚未将提交推送到 git 服务器，则可以重置为之前的提交，并使用良好的提交消息重新提交。

Finally, --mixedresets the index, but not the working tree. So the changes are all still there, but are “unstaged” and would need to be git add'ed or git commit -a. we use this sometimes if we committed more than we meant to with git commit -a, we can back out the commit with git reset --mixed, add the things that we want to commit and just commit those.

最后，--mixed重置索引，但不重置工作树。所以更改仍然存在，但“未暂存”并且需要 git add'ed 或git commit -a。如果我们使用 git commit -a 提交的内容超出预期，我们有时会使用它，我们可以使用 git reset --mixed 取消提交，添加我们想要提交的内容，然后提交这些内容。

Difference between git revert and git reset:-

git revert 和 git reset 之间的区别：-

---

---

In simple words, git resetis a command to "fix-uncommited mistakes"and git revertis a command to "fix-commited mistake".

在简单的话，git的复位就是命令“修复未提交的错误”和混帐复归就是命令“修复COMMITED错误”。

It means if we have made some error in some change and commited and pushed the same to git repo, then git revertis the solution. And if in case we have identified the same error before pushing/commiting, we can use git resetto fix the issue.

这意味着如果我们在某些更改中犯了一些错误并将其提交并推送到 git repo，那么git revert就是解决方案。如果我们在推送/提交之前发现了相同的错误，我们可以使用git reset来解决问题。

I hope it will help you to get rid of your confusion.

我希望它能帮助你摆脱你的困惑。

回答by Snowcrash

TL;DR

TL; 博士

git resetresets Staging to the last commit. Use --hardto also reset files in your Working directory to the last commit.

git reset将暂存重置为最后一次提交。使用--hard在你的工作目录还重置文件上次提交。

LONGER VERSION

更长的版本

But that's obviously simplistic hence the many rather verbose answers. It made more sense for me to read up on git resetin the context of undoing changes. E.g. see this:

但这显然很简单，因此有许多相当冗长的答案。git reset在撤消更改的上下文中阅读对我来说更有意义。例如看这个：

If git revert is a “safe” way to undo changes, you can think of git reset as the dangerous method. When you undo with git reset(and the commits are no longer referenced by any ref or the reflog), there is no way to retrieve the original copy—it is a permanent undo. Care must be taken when using this tool, as it's one of the only Git commands that has the potential to lose your work.

如果 git revert 是撤消更改的“安全”方式，您可以将 git reset 视为危险方法。当您使用 git reset 撤消（并且提交不再被任何 ref 或 reflog 引用）时，无法检索原始副本——这是永久撤消。使用此工具时必须小心，因为它是仅有的可能会丢失您的工作的 Git 命令之一。

From https://www.atlassian.com/git/tutorials/undoing-changes/git-reset

来自https://www.atlassian.com/git/tutorials/undoing-changes/git-reset

and this

和这个

On the commit-level, resetting is a way to move the tip of a branch to a different commit. This can be used to remove commits from the current branch.

在提交级别，重置是一种将分支的尖端移动到不同提交的方法。这可用于从当前分支中删除提交。

From https://www.atlassian.com/git/tutorials/resetting-checking-out-and-reverting/commit-level-operations

来自https://www.atlassian.com/git/tutorials/resetting-checking-out-and-reverting/commit-level-operations

回答by timhc22

Please be aware, this is a simplified explanation intended as a first step in seeking to understand this complex functionality.

请注意，这是一个简化的解释，旨在作为寻求理解这一复杂功能的第一步。

May be helpful for visual learners who want to visualise what their project state looks like after each of these commands:

对于想要在每个命令后可视化项目状态的视觉学习者可能会有所帮助：

---

---

For those who use Terminal with colour turned on (git config --global color.ui auto):

对于那些在颜色打开的情况下使用终端的人（git config --global color.ui auto）：

git reset --soft Aand you will see B and C's stuff in green (staged and ready to commit)

git reset --soft A你会看到 B 和 C 的东西呈绿色（已上演并准备提交）

git reset --mixed A(or git reset A) and you will see B and C's stuff in red (unstaged and ready to be staged (green) and then committed)

git reset --mixed A（或git reset A），您将看到 B 和 C 的内容为红色（未暂存并准备暂存（绿色）然后提交）

git reset --hard Aand you will no longer see B and C's changes anywhere (will be as if they never existed)

git reset --hard A并且您将不再在任何地方看到 B 和 C 的变化（就像它们从未存在过一样）

---

---

Or for those who use a GUI program like 'Tower' or 'SourceTree'

或者对于那些使用像“Tower”或“SourceTree”这样的 GUI 程序的人

git reset --soft Aand you will see B and C's stuff in the 'staged files' area ready to commit

git reset --soft A你会在“暂存文件”区域看到 B 和 C 的东西准备提交

git reset --mixed A(or git reset A) and you will see B and C's stuff in the 'unstaged files' area ready to be moved to staged and then committed

git reset --mixed A（或git reset A），您将在“未暂存文件”区域中看到 B 和 C 的内容准备移至暂存然后提交

git reset --hard Aand you will no longer see B and C's changes anywhere (will be as if they never existed)

git reset --hard A并且您将不再在任何地方看到 B 和 C 的变化（就像它们从未存在过一样）

回答by Ian Warburton

Checkout points the head at a specific commit.

Checkout 将头部指向特定的提交。

Reset points a branch at a specific commit. (A branch is a pointer to a commit.)

重置将分支指向特定提交。（分支是指向提交的指针。）

Incidentally, if your head doesn't point to a commit that's also pointed to by a branch then you have a detached head._{(turned out to be wrong. See comments...)}

顺便说一句，如果你的头没有指向一个分支也指向的提交，那么你有一个分离的头。_{（原来是错的。见评论...）}