我的同事做了一系列粗心的拉/推操作。他最终陷入了他的本地提交丢失的情况

我使用git reflog. 但我不明白为什么他的操作会导致这种情况。有人可以点亮一些灯吗？

请参阅git reflog下面的输出和评论：

问题：

1. 不小心做了一个 git --amend 并将其从第一台计算机推送到 USB 密钥
2. 从 USB 密钥拉到第二台计算机
3. 第二台计算机存储库现已损坏
4. git pull 到第一台计算机导致合并冲突；对这是否也是损坏状态感到困惑（如果 --amend 已损坏）

症状：

大多数命令：

.git/refs/heads/master：

.git/refs/heads/master 的文件内容：

'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'

我不确定我是否愿意责怪 git --amend ，因为它看起来有点温和；也许发生了其他事情。

怎么修？：

解决这个问题就像从 .git/logs/refs/heads/master 的最新良好提交中获取哈希并将其手动插入 .git/refs/heads/master 一样简单吗？我该怎么做，如果

如果是这样，我应该销毁有问题的提交（这样它就不会在以后破坏东西，比如 agit-repack或其他东西）？

当我尝试从表单的最后一行less .git/logs/refs/heads/master获取 [edit:typo]的第一个哈希时...

...然后粘贴到 .git/refs/heads/master 文件中，我现在坚持...

我可以尝试销毁松散的对象，但我不确定它是否是指向（例如树）的更多损坏对象的指针，这些对象也必须被销毁。如果我知道推荐，我当然可以尝试销毁这个对象（或者可以尝试rm备份它）；我应该试试吗？

此外，我将如何从这个混乱中修复 USB 密钥和其他 repo？谢谢。

（对新手可能有用的参考资料，不太可能帮助有能力回答这个问题的人：https ://aboullaite.me/deep-dive-into-git-git-refs/ ）（类似的问题致命：您当前的分支似乎已损坏-- 没有说明错误的原因；很多事情都可能导致这个错误）

编辑：

我rm .git/objects/...为上面列出的每个对象都做了，现在我有......

如果每个分支都引用了它的初始基本提交（比如） ，那么git 上游 rebase “硬案例”问题是否会得到解决branch@{base}？

这个初始的基本提交（branch.<name>.base例如，存储在配置文件中）将首先是分支最初创建时指向的那个。

然后，任何git rebase new_base_commit branch人实际上都可以git rebase --onto new_base_commit branch@{base} branch在更新branch@{base}到new_base_commit.

它只会自动化文档的“硬案例”解决方案。

我想如果这样一个简单的解决方案还没有实施，应该有充分的理由不这样做。既然我什么都看不到，那一定意味着我误解了什么。

那么，如果有，这些原因是什么？

编辑：阅读bk2204 的回答让我意识到这种行为只会对跟踪分支的特殊用例有用和预期（我应该早点意识到，因为它是关于上游变基的），所以应该记录初始基数只用于跟踪分支，仅用于使用隐式的命令@{upstream}，例如git rebase不带参数的命令。

编辑：我刚刚发现实际上，git pull --rebase并且git rebase已经使用 的算法做了类似的事情git merge-base --fork-point，但后者使用可以被垃圾收集的 reflog 来动态计算分叉点。

所以我仍然想知道：为什么不简单地将它存储在旁边branch.<name>.remote呢branch.<name>.merge？

例如，当用户开始跟踪另一个分支*时，可以使用 和 来计算分叉点git merge-base --fork-point upstream local并将其存储在git config branch.local.forkPoint（或任何其他名称）git config branch.local.remote下git config branch.local.merge。
然后，当用户执行 agit pull --rebase或 agit rebase时，它可以做**：

如果用户尝试执行 agit pull或 a git merge，它可以首先检查local@{upstream}没有重新设置基础，使用：

如果它被 rebase，它可能会中止，并建议改为执行 rebase 或编写完整的合并命令来强制它（例如）。

编辑：我认为，为了能够正确处理文档此页面中“变基的危险”中描述的情况，当使用合并而不是变基将分支“同步”到其上游时，最后一次“同步”点”应该被检查以验证上游也没有从那时起重新定位。

因此，每个git pullorgit merge还应该在应用合并后将来自上游分支的合并父提交存储在某个地方（比如branch.local.lastSyncPoint可能）。在应用合并之前，它还应该检查：

实际上，它可以使对分叉点的检查无用。

编辑：此外，我认为变基应该丢弃从最后一个“同步点”可到达的所有提交，这些提交未包含在（变基）上游（local@{upstream}..`git config branch.local.lastSyncPoint` ）中。在丢弃提交的情况下，它将使其按照预期工作。

* 带有git switch --create local --track upstream或git checkout -b local upstream或git branch --track local upstream或git branch --set-upstream-to upstream local

** 而不是即时：

假设我有一个 git 存储库，app.py并且我不小心将 API 密钥（或其他秘密）作为明文包含在我尚未推送到远程app.py的提交中（假设在 Github 上）。

要在本地撤消和修复此提交，我可以：

在本地，我仍然可以结帐到我不小心提交明文 API 密钥的 ref 并在以下位置查看秘密app.py：

如果我将删除明文 API 密钥的提交（即使用"some message上面的消息提交）推送到远程，有没有什么方法可以让远程仍然能够“看到”明文中包含 API 密钥的引用？这个秘密是否可能最终出现在 Github 上（即使只是在他们的服务器上，不一定通过网站/公共 API 可见）？

首先十分感谢！

我最近做了一个提交，但它不正确，所以我尝试将其重置为另一个提交。现在我意识到提交包含我们团队所需的信息。GitHub 组织的管理员能否找到该提交（来自 reflog）并从他们自己的计算机上获取所需的信息？它不再显示在 GitHub 上的提交历史记录中 :(。

如果他们能做到这一点，那将非常有帮助，因为我仍在学习 git 并且不想再搞砸任何事情。