Question

前几天我搞砸了我的应用程序并从主人分支以从我的错误中恢复。今天早上我注意到我无法推送到Github，因为我不是主人，所以我检查了主人并收到了这个警告：

你要离开6个提交，没有连接到你的任何一个分支

我做了一个git reflog并得到了

651c63a HEAD@{0}: checkout: moving from 64c5d8d2abf3c6337ee8a9d6ea91b40c5b31d2e3 to master
64c5d8d HEAD@{1}: commit: preparing to move Ramp Receiving to TOP LEVEL
0f12bf1 HEAD@{2}: commit: receiving custom cell complete
3df40ec HEAD@{3}: commit: custom cell outlets and actions
09f0ef9 HEAD@{4}: commit: added button bar to Ramp Receiving
813df97 HEAD@{5}: commit: rounded buttons
91d4d47 HEAD@{6}: commit: recovered
2d7dbb9 HEAD@{7}: checkout: moving from master to 2d7dbb9f1d359bbb2393e0cf5c246f19f13ac818

在我再次陷入困境之前，我怎样才能掌握“准备将Ramp Receiving to TOP LEVEL”状态，以便我可以推送到github并重新开始工作？

感谢!!!

Answer 1

您获得的反馈将与在独立的HEAD状态下工作一致。我不知道你是怎么到达那里的，你的问题也没有明确说明这一点。但是如果正确的话，快速修复以保存你的工作就是从你所在的位置结账新分支：

git checkout -b master_hotfix

现在，您将成为真正的本地Git分支master_hotfix，您的6个提交应该是该分支的一部分。您可以将此修复分支合并到master，也可以推送到回购并发送回请求回master。

修改

正如@Mark在他的回答中指出的那样，reflog显示实际上你已经在master。因此，如果您想从之前的分离HEAD状态创建一个新分支，您可以签出该提交，然后从那里创建分支：

git checkout 64c5d8d git checkout -b master_hotfix

Answer 2

首先说明为什么git会发出警告，然后我会回到问题本身......

为何选择警告

你的reflog表明，当你从错误中恢复过来时，你做了类似

的事情

git checkout 2d7dbb9f1

（或者您可能已经说过git checkout HEAD^或git checkout HEAD~3，或者其他任何表达式都会导航到2d7dbb9f1提交。）

当你这样做时，你应该收到一条警告，说你正处于“超脱HEAD”状态。这是一个没有检出分支的条件，这意味着当你进行提交时，没有分支自动移动到指向那些新提交。只有你当前的HEAD（以及reflog）才能保持这些提交“可达”。

在您处于分离头状态的任何时候，如果您想在已签出的提交中开始提交提交，您可以创建一个新分支

git checkout -b new_branch

通过使用checkout -b创建分支，您也可以将其检出，因此在您创建新提交时它将随您一起移动。现在你只是在一个分支上，而不是处于独立的头状态。

由于你没有这样做，当你签出master git时警告你，你正在离开“悬空”或“无法接近”。如果你不采取措施保护它们，它们最终会丢失。现在，reflog让它们保持活力，但它最终会过期。

现在该怎么做

那么你如何保留提交？有几种选择。

您询问有关将master移至64c5d8d的问题。简短的回答是

git checkout master
git reset --hard 64c5d8d

答案很长......你确定这是你想做的吗？如果origin/master可以从64c5d8d访问，并且您不希望任何未推送的提交当前在主服务器上（但无法从64c5d8d访问）那么这没关系。但请注意，这会使那些提交在恢复较新的过程中“无法访问”。

如果origin/master 不能从64c5d8d到达 - 也就是说，在创建分支时，您已经过了已经推送过的提交，按照下图 - 这个使事情复杂化。

                      C -- D <--(master)
                     /
x -- x -- x -- A -- B <--(origin/master)
                \
                 X -- Y -- Z=64c5d8d

在此示例中，您发现B，C和D“不好”，但到那时B已被推送。在这种情况下，重置master会尝试从分支历史记录中删除B。这会产生一种“上游条件”状态，这会给那些克隆origin的人带来麻烦。如果适用，请参阅git rebase文档，了解有关如何协调和清理此问题的信息。

在这种情况下，另一种方法是在主服务器上恢复B，然后将新提交合并（或rebase-and-fast-forward）到master，这样就不会删除历史上的任何事情。

另一个选择 - 我在确定目标状态时首先要做的是 - 为新提交创建一个新分支。 reflog显示最后一个新提交位于HEAD@{1}，因此如果仍然是最新提交，您可以git checkout HEAD@{1}。交替

git checkout 64c5d8d

将起作用，因为这是最后一次悬挂提交的缩写哈希（也来自reflog）。然后

git checkout -b some_branch_name

GIT转向掌握分离我的HEAD

2 个答案: