git reset --hard 和 git clean 的区别答案

【问题标题】：Difference between git reset --hard and git cleangit reset --hard 和 git clean 的区别
【发布时间】：2015-08-26 11:42:02
【问题描述】：

您好，我很好奇这两个命令之间的区别。当他们在这里介绍时：https://www.atlassian.com/git/tutorials/undoing-changes

看起来 git reset --hard 还设置了暂存目录和工作目录以匹配最新提交，但最后他们说 git reset --hard 不会更改当前工作目录。所以我在这里很困惑，有人可以澄清一下吗？

【问题讨论】：

它在哪里 does 说“git reset --hard 不会更改当前工作目录”？它明确表示相反 - “换一种说法：这 [硬重置] 消除所有未提交的更改”。
另外，注意“记住[hard] 重置只影响被跟踪的文件，所以需要单独的[clean]命令进行清理找到未跟踪的。"
@user2864740 是的，它消除了所有未提交的更改，但如果它还重置工作目录以匹配最后一次提交，为什么我们仍然需要 git clean 命令，因为在这种情况下不会有任何未跟踪的文件作为工作目录和暂存区是一样的
请参阅git-scm.com/book/en/v2/… ：“请记住，工作目录中的每个文件都可以处于以下两种状态之一：已跟踪或未跟踪。跟踪的文件是上次快照中的文件；它们可以是未修改的，修改的[表示未暂存/未提交的更改]，或暂存的[表示未提交的更改]。未跟踪的文件是其他所有文件 - 您的工作目录中不在您上一个快照中且不在暂存区域中的任何文件[未跟踪] 。”
也许这是一些非常乏味的生活，改变了重要的不可复制的艺术作品，却被遗忘了添加到 git 中。在那种情况下，是的，我会说它很重要/很有用——如果通过运行 git clean 删除它可能会令人不安。我听说过的关于 git 的最大抱怨之一是新用户忘记添加 [并随后暂存] 文件。 Git 不会丢失更改 [没有一点帮助] - 但有些更改根本不会进入 git！

标签： git git-reset git-clean

【解决方案1】：

他们做两件不同的事情。假设你做了GIT PULL 然后开始编辑一些文件并且可能已经添加并提交了这些更改到被推送...然后由于某种原因你决定放弃对给定文件所做的所有更改并回到较早的状态。在这种情况下你会这样做

$ git reflog
... snip ...
cf42fa2... HEAD@{0}: commit: fixed misc bugs
~
~
cf42fa2... HEAD@{84}: commit: fixed params for .....
73b9363... HEAD@{85}: commit: Don't symlink to themes on deployment.
547cc1b... HEAD@{86}: commit: Deploy to effectif.com web server.
1dc3298... HEAD@{87}: commit: Updated the theme.
18c3f51... HEAD@{88}: commit: Verify with Google webmaster tools.
26fbb9c... HEAD@{89}: checkout: moving to effectif

选择要回滚的提交，如下所示：

git reset --hard 73b9363

重置 HEAD 后，所有更改/暂存文件都将消失。

至于 git clean 。以下是git-scm.com 的描述方式。

DESCRIPTION
Cleans the working tree by recursively removing files that 
are not under version control, starting from the current directory.

Normally, only files unknown to Git are removed, but if the -x
option is specified, ignored files are also removed. This 
can, for example, be useful to remove all build products.

If any optional <path>... arguments are given, only those paths are affected.

更多关于 reset vs clean 以及它们的 --options

lnydex99uhc:~  user$ git reset -h
usage: git reset [--mixed | --soft | --hard | --merge | --keep] [-q] [<commit>]
   or: git reset [-q] <tree-ish> [--] <paths>...
   or: git reset --patch [<tree-ish>] [--] [<paths>...]

    -q, --quiet           be quiet, only report errors
    --mixed               reset HEAD and index
    --soft                reset only HEAD
    --hard                reset HEAD, index and working tree
    --merge               reset HEAD, index and working tree
    --keep                reset HEAD but keep local changes
    -p, --patch           select hunks interactively

 lnydex99uhc:~ user$ git clean -h
    usage: git clean [-d] [-f] [-i] [-n] [-q] [-e <pattern>] [-x | -X] [--] <paths>...

        -q, --quiet           do not print names of files removed
        -n, --dry-run         dry run
        -f, --force           force
        -i, --interactive     interactive cleaning
        -d                    remove whole directories
        -e, --exclude <pattern>
                              add <pattern> to ignore rules
        -x                    remove ignored files, too
        -X                    remove only ignored files

【讨论】：

感谢分享。这是否意味着这是一个可能会影响项目未来编码的强大命令？
它将影响最近的更改，并且通过重置为较早的提交，您是在告诉 git 丢弃自上次提交以来的所有新更改。
写“所有更改/暂存文件都将消失” - 这只会影响 未提交 更改。提交的更改（如 reflog 所示）将始终保持不变，并且只要它们可以访问就可以随时恢复 - 例如。通过分支、标签或子级。（git“丢失”提交的唯一时间是 GC 运行并且它们 not 可访问，除了通过 id。）重写提交是另一种野兽，但 git reset 根本无法修改/删除以前的提交。
^- 也就是说，只要没有修改/暂存文件并且所有更改都已提交或隐藏， git reset 并不会真正“影响[现有或]未来的编码“因为它很容易恢复。丢失未提交的更改是眼前的问题，而不是长期的问题。