將現有的Git存儲庫推送到Github只發送大約一半的提交？

我有一個本地Git倉庫，我一直在開發幾天：它迄今有18個提交。今晚，我創建了一個私人的Github存儲庫，我希望能推動它;然而，當我這樣做的時候，它最終只能將十八個提交中的八個提交給Github。我刪除了Github repo並重新嘗試，結果相同。將現有的Git存儲庫推送到Github只發送大約一半的提交？

有關爲什麼會發生這種情況的任何想法？我之前沒有成功完成這個程序，所以我有點難住。

更新：有，並且一直只有在這個回購中的主分支。只是爲了解決一些已發佈的答案...

來源

2008-10-26 rpj

我接過一看有問題的資料庫，這裏是發生了什麼事情：

在某些時候，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現在指着提交F。
扔掉你的臨時黨支部

git branch -d tmp
您可以愉快地推到遠程存儲庫，它應該將所有的更改。

來源

2008-11-09 20:13:26 farktronix

如果你想謹慎的話，這種方法很好;如果您知道合併將快進，那麼您可以刪除並重新創建分支。看到我的答案。 – 2008-11-10 00:27:04

我想我會做的第一件事就是在本地存儲庫上運行git fsck以確保它的狀態良好。

我從來沒有見過這個問題，我想不出什麼可能是錯的。

來源

2008-10-26 02:35:27

檢查你是否推動正確的分支，並確保分支實際上擁有你認爲他們擁有的東西。特別是，檢查你是否沒有分離的HEAD，如果不是故意的，可能會令人困惑。

最簡單的檢查方法是使用gitk --all，它以圖形方式顯示所有分支，HEAD等等。

來源

2008-10-26 03:57:07 CesarB

因此，事實證明，兩者：.git/refs/heads/master中的提交散列是正確的，而.git/logs/refs/heads/master中的信息是不完整的;我的意思是它只包含了.git/refs/heads/master中指定的提交哈希。

一旦我修復了這些文件（手工），並推回到Github，一切都變成了肉汁。我仍然有不知道在這個狀態下發生了什麼事情，但我很高興至少我已經找到了解決方法。

如果有人想知道：修正.git/refs/heads/master，我只是使用最新的提交散列（HEAD）替換該文件的內容，並修復.git/logs/refs/heads /主，我只是將.git/logs/HEAD的內容複製到.git/logs/refs/heads/master中。容易peasy ...不。

來源

2008-10-26 21:26:15 rpj

正如我在答案中提到的那樣，您可能有一個「脫離頭部」。檢查.git/HEAD;如果它沒有「ref：refs/heads/master」（或另一個ref：行），那麼你有一個分離的HEAD，並且你的提交將不會到達分支，只到達HEAD。 – CesarB 2008-10-27 09:50:58

順便說一句，如果你確實有一個分離的HEAD，你只能修正這些症狀，並且你所有的新提交將只會繼續到HEAD。 IIRC，擺脫這種情況的方法是簽出一個分支（「git checkout master」），它會將HEAD設置爲指向該分支。 – CesarB 2008-10-27 09:53:17

我沒有信譽直接CesarB早期的回答發表評論，但gitk --all不會在這種情況下工作，因爲它只是列出了已知的分支。

gitk HEAD顯示了這個問題，但它並不完全清楚。冒煙槍是master顯示在提交樹下，而不是最近的提交。

來源

2008-11-09 20:17:25 farktronix

從Git的1.7.3起，你可以用一個簡單的命令做到這一點：

git checkout -B master

的-b開關裝置「檢查出來之前，在這裏創建分支」和-B是那個無條件版「即使分支已經存在 - 在這種情況下，在檢查出來之前將它移動到這裏「。

解決這類問題的一個非常簡單的方法就是刪除master分支並重新創建它。畢竟，git中的分支僅僅是提交的名字，master分支沒什麼特別的。

所以假設當前承諾是你想要master是一個，你只需做

git branch -D master

刪除現有master分支，然後做

git checkout -b master

到）創建稱爲master的新分支指向當前提交併且b）更新HEAD以指向master分支。之後，HEAD將附加到master，因此master將在您提交時向前移動。

來源

2008-11-09 21:25:14

我有兩次這個相同的問題，最後想出了我在做什麼導致它。在用git rebase -i編輯舊提交的過程中，我不是調用git commit --amend，而是通過習慣的強制呼叫git commit -a，當然，緊接着是git rebase --continue。其他人可能能夠解釋幕後發生的事情，但看起來結果是分離的HEAD問題。

來源

2009-01-30 15:38:37

將現有的Git存儲庫推送到Github只發送大約一半的提交？

回答

相關問題