既存のGitリポジトリをGithubにプッシュすると、コミットの約半分しか送信されませんか？

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

  •  04-07-2019
  •  | 
  •  

質問

私は数日間開発を続けてきたローカルGitリポジトリを持っています。これまでに18件のコミットがあります。今夜、私はそれをプッシュしたいと思っていたプライベートGithubリポジトリを作成しました。ただし、そうすると、18件のコミットのうち8件がGithubにプッシュされました。 Githubリポジトリを削除して再試行しましたが、同じ結果になりました。

これが起こっている理由について何か考えはありますか？何度か成功せずにこの手順を実行したことがあるので、少し困惑しています。

更新：このレポにはmasterブランチのみが存在し、常に存在します。投稿された回答のいくつかに対処するために...

役に立ちましたか？

解決

問題のリポジトリを調べたところ、次のようになりました。

  • ある時点で、rpjは git checkout [commit id] を実行していました。これは、HEADが認識されたブランチではなくルーズコミットであることを示しています。これが「ダングリングヘッド」だと思います。 CesarBが参照している問題。
  • この問題を認識せずに、彼は変更とコミットを続けました。ただし、HEADは、認識されているブランチではなく、コミットのぶら下がりのチェーンを指しているだけです。
  • 変更をプッシュするために行ったとき、gitはすべてをマスターの最上部に押し上げました。これは、現在のツリーのちょうど中間にありました。
  • 混乱が生じた

この図により、より明確になります。

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

変更をプッシュしようとしたとき、 A から C のみがプッシュされ、リモートは C 。彼は、既知のブランチによって参照されていないため、プッシュする F を介してコミット D を取得できませんでした。

この状態のときに表示されるものは次のとおりです。

$ 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以降では、1つの簡単なコマンドでこれを実行できます。

git checkout -B master

-b スイッチは、チェックアウトする前にここにブランチを作成することを意味します＆＃8221; -B はその無条件バージョンです。ブランチが既に存在していても＆＃8211;その場合は、チェックアウトする前にここに移動してください＆＃8221;。

この種の問題を修正するための非常に簡単なアプローチは、 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にコピーしました。簡単です... NOT。

これと同じ問題が2回発生し、最終的にはそれが原因で何をしていたのかがわかりました。 git rebase -i で古いコミットを編集する過程で、 git commit --amend を呼び出す代わりに、 git commit -a もちろん習慣の強制によって、直後に git rebase --continue が続きます。他の誰かが舞台裏で何が起こっているのかを説明できるかもしれませんが、結果は分離されたHEADの問題のようです。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top