git - 将现有的 Git 存储库推送到 Github 只会发送大约一半的提交？

Question

我有一个本地 Git 存储库，我已经在其中开发了几天：到目前为止，它有 18 个提交。今晚，我创建了一个私人 Github 存储库，我希望将其推送到；然而，当我这样做时，它最终只将 18 个提交中的 8 个推送到 Github。我删除了 Github repo 并重试，结果相同。

关于为什么会发生这种情况的任何想法？我以前做过这个程序，但没有成功几次，所以我有点难过。

更新：这个 repo 中只有 master 分支，并且一直存在。只是为了解决一些已发布的答案......

Answer 1

我查看了有问题的存储库，这是发生了什么：

• 在某些时候，rpj 执行了git checkout [commit id]. 这将 HEAD 指向一个松散的提交，而不是一个公认的分支。我相信这就是 CesarB 所指的“悬空 HEAD”问题。
• Not realizing this problem, he went on making changing and committing them, which bumped HEAD up every time. However, HEAD was just pointing at a dangling chain of commits, not at a recognized branch.
• When he went to push his changes, git pushed everything up to the top of master, which was only about halfway through the current tree he was on.
• Confusion ensued

This diagram should make it more clear:

                 -- D -- E -- F
                /             ^
   A -- B -- C -              |
   ^         ^               HEAD
   |         |
 remote    master

When he tried to push his changes, only A through C were pushed and remote moved up to C. He couldn't get commits D through F to push because they aren't referenced by a known branch.

Here's what you see when you're in this state:

$ git branch
* (no branch)
master

The solution is to move master up to F in the dangling chain of commits. Here's how I did it.

• Create a legitimate branch for the current state:

  git checkout -b tmp

  • The tmp branch is now pointing at commit F in the diagram above

• Fast-forward master to tmp

  git checkout master

  git merge tmp

  • master is now pointing at commit F.

• Throw away your temporary branch

  git branch -d tmp

• You can happily push to the remote repository and it should send all of your changes.

Answer 2

From Git 1.7.3 onwards, you can do this with one simple command:

git checkout -B master

The -b switch means “create branch here before checking it out” and -B is the unconditional version of that, “even if the branch already exists – in that case, move it here before checking it out”.

---

A very simple approach for fixing this sort of problem is to just delete the master branch and recreate it. After all, branches in git are merely names for commits and the master branch is nothing special.

So assuming that the current commit is the one you want master to be, you simply do

git branch -D master

to delete the existing master branch, then do

git checkout -b master

to a) create a new branch called master that points to the current commit and b) update HEAD to point to the master branch. After that, HEAD will be attached to master and therefore master will move forward whenever you commit.

Answer 3

检查您是否推送了正确的分支，并且这些分支实际上具有您认为它们具有的内容。特别是，检查您是否没有分离的 HEAD，如果不是故意这样做可能会非常混乱。

最简单的检查方法是使用gitk --all，它以图形方式显示所有分支、HEAD 等。

Answer 4

我想我要做的第一件事是git fsck在您的本地存储库上运行，以确保一切正常。

我以前从未见过这个问题，我想不出可能出了什么问题。

Answer 5

I don't have the reputation to comment directly on CesarB's earlier answer, but gitk --all doesn't work in this case because it only lists out known branches.

gitk HEAD shows this problem, but it's not entirely clear. The smoking gun is that master shows up down the commit tree rather than at the most recent commit.

Answer 6

因此，事实证明： .git/refs/heads/master 中的提交哈希不正确， .git/logs/refs/heads/master 中的信息不完整；我的意思是它只包含在 .git/refs/heads/master 中指定的提交哈希。

一旦我（手动）修复了这些文件，并将它们推回 Github，一切就又恢复了。我仍然不知道在这种状态下发生了什么，但我很高兴我至少找到了解决办法。

如果有人想知道：修复 .git/refs/heads/master，我只是用最新的提交哈希 (HEAD) 替换了该文件的内容，修复 .git/logs/refs/heads/master，我只是将 .git/logs/HEAD 的内容复制到 .git/logs/refs/heads/master 中。简单的...不是。

Answer 7

I've had this same problem twice, and finally figured out what I was doing that was causing it. In the process of editing an old commit with git rebase -i, instead of calling git commit --amend, I was calling git commit -a by force of habit, immediately followed by git rebase --continue, of course. Someone else might be able to explain what's going on behind the scenes, but it seems that the result is the detached HEAD problem.