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

StackOverflow https://stackoverflow.com/questions/237408

  •  04-07-2019
  •  | 
  •  

题

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

对于为什么会发生这种情况有什么想法吗？我以前做过这个程序，但没有成功几次，所以我有点困惑。

更新: ：此存储库中一直只有主分支。只是为了解决一些已发布的答案......

有帮助吗？

解决方案

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

  • 在某个时刻，rpj 已经执行了 git checkout [commit id]. 。这将 HEAD 指向松散的提交而不是公认的分支。我相信这就是 CesarB 所指的“悬空头”问题。
  • 没有意识到这个问题，他继续进行更改并提交它们，这每次都会使 HEAD 抬起来。然而，HEAD 只是指向一个悬空的提交链，而不是一个公认的分支。
  • 当他去推送他的更改时，git 将所有内容推送到 master 的顶部，这大约只是他当前所在树的一半。
  • 混乱随之而来

这张图应该可以更清楚地说明：

                 -- 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 现在指向提交 F.

  • 扔掉你的临时分支

    git branch -d tmp

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

其他提示

从Git 1.7.3开始，您只需一个简单的命令就可以完成此任务：

git checkout -B master

-b 开关意味着＆＃8220;在检查之前在这里创建分支＆＃8221;并且 -B 是该条件的无条件版本，即使分支已经存在＆＃8211;在这种情况下，请在检查之前将其移到此处。

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

因此，假设当前提交是您希望 master 的提交，您只需执行

git branch -D master

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

git checkout -b master

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

检查您是否正在推动正确的分支，并且分支实际上具有您认为的分支。特别是，检查你是否没有分离的HEAD，如果没有故意这样做会很混乱。

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

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

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

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

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

因此，事实证明两者都是：.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中。容易腻......不。

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

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top