HEAD 领先于 master答案

【问题标题】：HEAD is way ahead of masterHEAD 领先于 master
【发布时间】：2019-08-01 13:25:11
【问题描述】：

我的HEAD 远远领先于master。 HEAD 有正确的代码，master 没有。我无法更新 BitBucket 上的存储库，因为它不是快进。

我的历史是这样的：

|HEAD
|some commit
|some commit
|some commit
| |origin/master master
| |some commit
| |some commit
|/
some other commits...

如何使我的源/主更新 HEAD 女巫拥有正确的新代码？

谢谢！

【问题讨论】：

首先要问自己的是，你最初是如何设法得到一个分离的头的，这样你以后就可以尽量避免这种情况

标签： git head master

【解决方案1】：

git branch new-master # mark the commit with the branch
git checkout master
git reset --hard new-master  # move master to new-master
git branch -D new-master # it's no longer needed, delete it
git push --force origin master  # Force to update the remote repo

【讨论】：

就像@choroba 说的那样，如果存储库中有更多人，他们不会对强制推送感到满意
但你在那里回答了他的担忧。 :-p

【解决方案2】：

如果您对源代码/主代码无关紧要并且对 HEAD 感到满意，则可以执行以下操作： git push --force

编辑：如果存储库中有其他人，您不应该这样做。相反，您应该首先 git merge master，手动解决合并冲突，提交更改，然后将它们推送到 origin/master

【讨论】：

如果有更多人使用同一个仓库，这会让他们很不高兴。

【解决方案3】：

严格来说，HEAD 与master分歧。并且似乎HEAD 已分离，因此创建一个分支以进行备份并轻松引用其提交。

# "backup" can be any valid branch name you like
git branch backup HEAD

由于origin/master 和master 指向同一个提交，我们可以得出结论，master 上的提交已经发布。现在你有两个选择。

一个是改写master的历史。它需要强制推送来更新远程存储库中的master。如果有许多其他贡献者，这不是一个好主意，因为如果处理不当，可能会带来混乱的历史。

git checkout master
git reset backup --hard
git push origin -f master

另一种是在master上创建一个新的提交，并使代码与HEAD完全相同。缺点是backup 上的提交和master 上的新提交如果您没有推送或不打算推送它们可能会消失。

git checkout master
git merge $(git commit-tree -p HEAD -m "whatever" master^{tree})
# edit the commit message
git commit --amend
# later you can push as usual, without "-f"
git push origin master

如果您希望master 包含backup 和master 的所有提交，同时代码与backup 完全相同，您可以尝试

git checkout master
# with "-s ours", commits are merged but the changes are not
git merge backup -s ours 
# repeat the 2nd option
git merge $(git commit-tree -p HEAD -m "whatever" master^{tree})
# edit the commit message
git commit --amend
# later you can push as usual, without "-f"
git push origin master

origin/master会自动更新。不用管它也没关系。

【讨论】：

【解决方案4】：

我建议要么

git merge origin/master

或

git rebase origin/master

使用任何一种方法，您可能都需要解决合并冲突，但在这样做之后，您将能够将您的 master 推送到 BitBucket。

在这种情况下，Rebase 稍微好一点，因为它会使您的历史保持线性，并且不会显示您正在处理 detached HEAD。

有时能够检查不在任何命名分支顶端的提交，或者甚至创建一个未被命名分支引用的新提交，这有时很有用。让我们看看当我们 checkout commit b 时会发生什么（这里我们展示了两种可能的方式）：
$ git checkout v2.0  # or
$ git checkout master^^

  HEAD (refers to commit 'b')
    |
    v
a---b---c---d  branch 'master' (refers to commit 'd')
    ^
    |
  tag 'v2.0' (refers to commit 'b')
请注意，无论我们使用哪个签出命令，HEAD 现在都直接指向提交 b。这被称为处于分离HEAD 状态。这意味着HEAD 指的是一个特定的提交，而不是指一个命名的分支。

【讨论】：