git重置和git cherry pick之间的差异

我从这里读到：

如果您想恢复项目的历史记录，请使用git reset--hard 如果您想将其中一个提交重放到存储库中，请使用git cherry pick

我是一个初学者，还没有进入分支领域。对我来说，这里cherry-pick的用法似乎与git-reset的用法相同。我想知道git cherry pick与git reset有什么不同，因为我只在一个分支中工作。

git reset--hard的意思是

git reset--hard HEAD

其中HEAD是当前分支中当前签出的提交或最后一次提交的引用，也就是说，不要更改分支，但要删除所有本地更改，这样它将删除所有暂存和未暂存的更改。

git reset

命令提供了许多选项，这里对此进行了很好的解释：

而Cherry picking意味着从一个分支中选择一个commit并将其应用到另一个分支上。如果您犯了一个错误并将更改提交到错误的分支，但不想合并整个分支，则可以这样做。您可以恢复提交并在另一个分支上选择它

如果您推送到错误的分支，或者您的分支出现问题，显示来自其他用户的大量提交（当多个用户正在工作时）由于您的系统上有旧的git历史记录，您可以删除当前分支以保证提交哈希的安全性，然后选择提交到新分支，该分支将从主节点更新。（这种情况有时会发生，

cherry pick

是

rebase

或

merge

无法解决问题时的一个选项）

这句话摘自以下答案：

来源：

使用git cherry pick命令git cherry pick commit应用 命名提交在当前分支上引入的更改。会的 引入一个新的、独特的提交。严格地说，使用git cherry pick不会改变存储库中现有的历史记录； 相反，它增加了历史。与其他Git操作一样 通过应用差异的过程引入更改，您可能需要 解决冲突以完全应用给定提交中的更改。 git cherry pick命令通常用于引入特定的 从存储库中的一个分支提交到另一个分支。A. 常见用途是从维护中向前或向后端口提交 分支到发展分支

因此，每当您想要重置提交或更改时，您可以使用

git reset

和event。如果您想要重置提交并确保提交更改的安全，您可以使用

git reset

和

--soft

选项。如果您想将提交从其他分支复制到其他分支，那么可以使用

git cherry pick

。

git reset

有许多可用选项，例如：

$ git pull    
  Automatic merge failed; fix conflicts and then commit the result.
$ git reset --hard   # clears the mess from the index file and the working tree.

要重置为当前

磁头

：

git reset --hard HEAD

要重置一个提交并删除更改，请执行以下操作：

git reset --hard HEAD~1

此1可以是n以删除任意数量的提交。此外，为了保留提交的更改，您可以使用

--soft

而不是

--hard

对于

cherry pick

，语法为：

git cherry-pick <commit-hash>

git樱桃采摘

樱桃采摘用于将属于另一个分支的特定（甚至是一系列）提交合并到当前签出的分支

比方说，另一个用户希望将此提交，

sha1

，从同一存储库的分支

foo

转移到分支

bar

。注意，在这种情况下，分支

foo

可以通过

sha1

commit状态位于多个提交之前

foo : ORIG_HEAD -- sha1 -- sha2 -- sha3 -- .... shaN
                    ^~~~user want to cherry-pick 
                        only this commit

要将提交

sha1

到分支

条

：

git checkout bar
git cherry-pick sha1 
# The commit `sha1` is merged to your branch `bar` and is ahead by 1 commit

---

Git reset主要用于撤消本地提交或失败的Git拉/合并。它也被用来清理脏兮兮的树上的杂物

例如：

$ git pull    
  Automatic merge failed; fix conflicts and then commit the result.
$ git reset --hard   # clears the mess from the index file and the working tree.

---

---

因此，cherry picking和git重置都会影响头部位置，但它们在用例方面有很大的不同

@Construct我更新了我的声明，因为我理解你的担忧，但我在解释这个问题时不清楚。当您有一个较旧的git历史记录并且很长时间没有更新它时，就会出现这个问题。然后，有时在您的功能分支中，它开始显示其他用户的提交，但不会显示文件中的额外更改。在这种情况下，您可以这样做。@Construct:是的，他们会的。事实上，

git-rebase

仅仅是一系列自动的cherry-pick操作，然后在最后移动重基分支以指向最后一个这样的cherry-pick提交。@Deep:

git-cherry-pick

表示“复制一个提交”。您选择提交，无论您现在在哪里，它都会作为新的提交添加。（您可以复制多个，但默认值仅为一个。）另一方面，

git-rebase

的意思是：“从当前分支（我现在所在的分支）复制尽可能多的提交到我告诉您移动到的分支；然后将我的当前分支移动到上次复制的提交。”移动分支的最后一步有效地删除了来自该分支的原始（现在已复制）提交。（这很好，因为它们是被复制的。）所以它们非常不同。@Deep：“根据需要复制尽可能多的提交”部分实际上使用了cherry pick，如果您使用的是

git-rebase-i

（它可能会为非交互式rebase使用另一种机制）。这就是为什么编辑器中有一堆“pick”命令：这些是要挑选的提交。但是，“删除”步骤是新的，所有复制的要点是使新的复制发生在提交图中的不同点。您可能想看看，例如，这里。好吧，这已经深入人心了，因为正如我提到的，rebase实际上可能运行

git cherry pick

，或者