【问题标题】：git reset --soft strange behaviorgit reset --soft 奇怪的行为
【发布时间】：2020-02-16 04:28:55
【问题描述】：

在我推入远程存储库中的develop 分支之前，我想压缩 3 个提交。我想我会使用git reset --soft HEAD~3（删除我最后的 3 次提交，并使用新的提交消息将它们放在一个提交中）。但是，当我编写命令时，我注意到它并没有只重置 3 次提交，而是像 20 次一样（别担心，我有备份）。在那之后，我想我会再试一次之前的提交（只是为了测试行为），我看到它不仅删除了 3 个提交，而且是一个随机数。

这可能是什么原因？（注意：“HEAD~3”提交在此之前拉取时存在合并冲突，我已解决，不确定是否会出现这种情况。

【问题讨论】：

标签： git version-control git-reset

【解决方案1】：

如果您重置 merge 提交，那么您将删除所有合并到您的分支中的提交...

假设您有另一个包含 10 个提交的分支，您将其合并到您的 develop 分支中。如果您现在运行 git reset --soft HEAD~1，那么您将看到这 10 次提交的所有更改。

更深入的解释

假设您有以下提交：

abc123 last commit (HEAD)
def456 merge feature2-branch (with 10 commits)
ghi789 add feature
jkl123 fix bug

HEAD（您在历史记录中的位置）位于 abc123。当你现在执行命令git reset --soft HEAD~3，

这不是的意思是：git，请删除最后 3 个提交。
这确实表示：git，请将HEAD 移至jkl123，但保留所有文件原样。

所以git 没有提交数量的概念，也不知道它们是合并提交还是其他什么。

【讨论】：

这是否记录在某处？有什么办法可以避免这种行为？类似于您传递给 git reset 的标志之类的东西？因为您可以轻松地重写不是由您做出的提交。 git如何知道是普通提交还是合并提交？
不，甚至没有理论上可行的方法。通过合并，您包括所有工作，如果您撤消合并提交但保留工作，那么您当然拥有该分支的所有工作。您可以期待哪些不同的行为？
类似警告的东西：你确定吗？（比如当他们希望你添加强制标志时，这样你就不会意外删除某些东西）
@jhon354 我刚刚编辑了我的答案。我希望你能更好地理解 git 现在是如何工作的。

【解决方案2】：

看起来你合并到你的分支然后运行重置。

这是一个可行的计划。

在您的分支上找到合并前的提交。
git checkout last_commit_before_merge
git branch -b feature/_X_attempt2
你压扁了吗 - 我推荐git rebase --interactive
按照常规流程：合并 master、push、创建 PR

在合并之前回退到您的分支后，您可以使用 git rebase -i master 在您的分支上重新设置 master。见Merging vs. Rebasing。

注意：这都是在您不与他人共享分支的情况下，因为变基（以及您的 git reset 方法）会重写历史。

【讨论】：