我正在使用git reset --hard <commit>尝试将我的repo代码移回上一个提交，因此删除了1个提交，但是在执行该语句后，似乎创建了一个本地分支，并且当前头和上一个之间的提交提交仍然存在。
我读到在垃圾回收完成之前，提交是孤立的，因此尝试强制使用GC，但没有帮助。我希望负责人转入先前的提交，但没有发生。
任何对我来说更清晰的文档帮助或指导将不胜感激
答案 0 :(得分：0)
运行git reset时，如果您有一个分支已签出，则该分支将移至目标提交。任何其他分支（或任何其他引用）将保持不变（旧提交将保留在整个历史记录中）。如果在运行git reset时处于分离的HEAD状态，则不会检出任何分支，因此不会移动任何分支。
默认情况下，git仅显示可到达的提交。我不确定哪个命令会向您显示提交仍然存在，但是在大多数情况下，显示它们的事实将意味着引用仍指向它们-这是gc不能提供帮助的原因之一
有几种类型的ref可以使提交保持“活动”状态。
即使本地分支移动了（并且是唯一的分支），也可能存在相应的远程跟踪引用-如果分支在远程中共享，也会存在。不过，这引起了更多的担忧（请参阅下文）。也可能有标签，或者其他一些晦涩的事物。
由于最可能的问题是远程跟踪引用，因此重要的是要了解从引用的历史记录中删除提交称为“历史记录重写”，并且对共享分支进行历史记录重写会产生成本。 git rebase文档在“从上游基准库恢复”下对此进行了描述。 （虽然据记录它与重新设置有关，但实际上它适用于所有重写。）
如果有一个远程跟踪分支需要移动，并且尽管这样做会花费很多费用，但您仍然决定继续进行历史记录重写，那么您将执行强制推送以更新远程分支（并且远程跟踪参考）。
git push --force-with-lease
与所有其他回购用户进行通信/协调历史重写非常重要；如果他们在尝试恢复时做错了事，则可能会撤消历史记录的重写。
一旦所有引用都移动了，大多数命令将不会显示“已删除”的提交，但是它们实际上仍然存在。实际上，它们仍然不会立即具有gc的资格，因为您的本地存储库具有一组“引用日志”，这些日志跟踪每个分支的历史以及符号引用HEAD。因此，如果您已经检出了提交，或者任何分支都包含了提交，那么即使分支和其他引用已经移动，也可以使用相应的引用日志来恢复它们。这意味着提交尚未被物理删除。
您可以使reflog过期（或删除reflog文件本身）；请参阅git reflog文档。或者，您可以等待reflog自行过期。之后，提交将被删除。
但是，根据远程服务器的托管方式，可能需要一个单独的过程才能从数据库副本中删除提交。而且，您绝对无法采取任何措施来迫使其他用户从其克隆中实际丢弃这些提交。因此，如果从存储库中删除信息很重要，那么您将需要每个人与克隆人的合作。并且如果删除提交的原因包括它们包含敏感信息，那么您需要考虑将该信息泄露（例如，通过更改以此方式公开的任何密码等）。
答案 1 :(得分：0)
我很抱歉，我只是意识到我的提交实际上已被推送到原始位置，因此我没有遵循正确的工作流程。我已经对重置进行了“本地”测试，并且提交已按预期方式删除，谢谢您的回复。