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

Question

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

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

更新 ：此回购中只有，而且一直只是主分支。 只是为了解决一些已发布的答案......

Answer 1

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

• 在某些时候，rpj已经执行了git checkout [commit id] 。 这指出HEAD处于松散的提交而不是公认的分支。 我相信这是CesarB所指的“悬空HEAD”问题。
• 没有意识到这个问题，他继续改变和提交它们，每次都让HEAD起来。 然而，HEAD只是指着悬挂的一系列承诺，而不是一个公认的分支。
• 当他去推动他的改变时，git将所有东西都推到了主人的顶端，这只是当前他所在的树的一半。
• 随之而来的是混乱

这个图表应该更清楚：

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

当他试图推动他的改变时，只有A到C被推动并且remote移动到C 他无法通过提交D到F来推送，因为它们没有被已知的分支引用。

这是你在这种状态下所看到的：

$ git branch
* (no branch)
master

解决方案是在悬挂的提交链中将master移动到F 这就是我做到的。

• 为当前状态创建合法分支：

  git checkout -b tmp

  • tmp分支现在指向上图中的提交F

• 快进master到tmp

  git checkout master

  git merge tmp

  • master现在指向commit F 。

• 丢掉你的临时分支

  git branch -d tmp

• 您可以愉快地推送到远程存储库，它应该发送所有更改。

Answer 2

从Git 1.7.3开始，您可以使用一个简单的命令执行此操作：

git checkout -B master

-b开关意味着“在检查之前在这里创建分支”，而-B是其无条件版本，“即使分支已经存在 - 在这种情况下，在检查之前将其移动到此处”。

---

解决此类问题的一种非常简单的方法是删除master分支并重新创建它。 毕竟，git中的分支只是提交的名称，而master分支并不特别。

因此，假设当前提交是您想要master那个，那么您就是这么做的

git branch -D master

删除现有的master分支，然后执行

git checkout -b master

a）创建一个名为master的新分支，指向当前提交，b）更新HEAD以指向master分支。 在那之后， HEAD将被附加到master ，因此master会在你提交时继续前进。

Answer 3

检查您是否正在推动正确的分支，并且分支实际上具有您认为的分支。 特别是，检查您是否没有分离的HEAD，如果不是故意的话，这可能会非常混乱。

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

Answer 4

我想我要做的第一件事就是在你的本地存储库上运行git fsck以确保它的状态良好。

我以前从未见过这个问题，我想不出可能出现的问题。

Answer 5

我没有直接评论CesarB早期答案的声誉，但gitk --all在这种情况下不起作用，因为它只列出已知的分支。

gitk HEAD显示了这个问题，但并不完全清楚。 吸烟枪是master出现在提交树而不是最近的提交。

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

我有两次同样的问题，最后弄清楚我在做什么导致它。 在使用git rebase -i编辑旧提交的过程中，我没有调用git commit -a git commit --amend ，而是通过习惯强制调用git commit -a ，当然紧接着是git rebase --continue 。 其他人可能能够解释幕后发生的事情，但似乎结果是分离的HEAD问题。