git Pushは、ローカルに変更があったとしても、すべてが最新であると言います
リモートgitosisサーバーとローカルgitリポジトリがあり、コードに大きな変更を加えるたびに、そのサーバーにも変更をプッシュします。
しかし、今日、ローカル変更を行ってローカルリポジトリにコミットしているにもかかわらず、git Push Origin masterを実行すると「Everything up-to-date」と表示されますが、git cloneリモートサーバー上のファイルをチェックアウトするには、最新の変更は含まれません。そして、masterという名前のブランチとOriginという名前のリモートサーバーが1つだけあります。
PS：これはls-remoteを実行したときにgitが表示するものです。それが役立つかどうかわかりません
$ git ls-remote Origin
df80d0c64b8e2c160d3d9b106b30aee9540b6ece HEAD
df80d0c64b8e2c160d3d9b106b30aee9540b6ece refs/heads/master
$ git ls-remote .
49c2cb46b9e798247898afdb079e76e40c9f77ea HEAD
df80d0c64b8e2c160d3d9b106b30aee9540b6ece refs/heads/master
df80d0c64b8e2c160d3d9b106b30aee9540b6ece refs/remotes/Origin/master
3a04c3ea9b81252b0626b760f0a7766b81652c0c refs/tags/stage3
もしかしたら デタッチドヘッド で作業することはないでしょうか？
次のように：
最新のコミットがブランチヘッドではないことを示します。
$ git log -1
# note the SHA-1 of latest commit
$ git checkout master
# reset your branch head to your previously detached commit
$ git reset --hard <commit-id>
git checkout manページ （強調鉱山）で述べたように：
ブランチの先端にないコミットをチェックアウトできると便利な場合があります。
最も明白な例は、次のように、タグ付きの公式リリースポイントでコミットをチェックアウトすることです。
$ git checkout v2.6.18
Gitの以前のバージョンではこれが許可されず、
-bオプションを使用して一時ブランチを作成するように求められましたが、バージョン1.5.0以降、上記のコマンドはHEADを現在のブランチから切り離し、コミットを直接ポイントしますtagで命名（上記の例ではv2.6.18）。この状態ですべてのgitコマンドを使用できます。
たとえば、git reset --hard $othercommitを使用してさらに移動できます。
分離されたHEADの上に変更を加えて新しいコミットを作成できます。git merge $othercommitを使用してマージを作成することもできます。HEADが切り離されている間、あなたがいる状態はどのブランチによっても記録されません（これは当然です-あなたはどのブランチにもいません）。
これは、既存のブランチ（たとえばgit checkout master）に戻すことにより、一時的なコミットとマージを破棄でき、後でgit Pruneまたはgit gcがガベージコレクションされることを意味しますそれら。
これを誤って行った場合は、reflogにHEADの場所を尋ねることができます。
$ git log -g -2 HEAD
Err .. git noobの場合、git commitの前にgit Pushがありますか？初めてこの間違いを犯しました！
たぶん、あなたは新しいローカルブランチをプッシュしていますか？
新しいローカルブランチを明示的にプッシュする必要があります。
git Push Origin your-new-branch-name
Gitのことの1つです...リポジトリのクローンを作成し、ブランチを作成し、いくつかの変更をコミットし、プッシュします...「すべてが最新です」。なぜ起こるのかは理解していますが、このワークフローは初心者には非常に不親切です。
私の問題は、ローカルブランチの名前がリモートブランチの名前と異なることでした。次の操作を行うことでプッシュできました。
$ git Push Origin local-branch-name:remote-branch-name
（クレジット https://penandpants.com/2013/02/07/git-pushing-to-a-remote-branch-with-a-different-name/ ）
知っておくべき重要な別の状況：gitのデフォルト状態の一種は、「マスター」ブランチで作業していることです。そして、多くの状況では、メインの作業ブランチとしてそこにたむろします（ただし、一部の人々は空想を得て、他のことをします）。
とにかく、それはたった1つのブランチです。だから私が入る可能性がある状況は次のとおりです：
私のアクティブなブランチは、実際にはマスターブランチではありません。 ...しかし、私は習慣的にコマンドgit Pushを実行します（以前にgit Push Origin masterを実行したことがあるので、THATのショートカットです）。
だから、私は習慣的にmasterブランチを共有リポジトリにプッシュしています...これはおそらく私の場合、きれいなものです...
しかし、私が取り組んでいる変更がまだmasterブランチにないことを忘れました!!!
したがって、git Pushを試すたびに、「すべてが最新」と表示されるたびに、悲鳴を上げたいのですが、もちろんgitのせいではありません。私のものです。
代わりに、ブランチをマスターにマージしてからプッシュを実行すると、すべてが再び幸せになります。
$ git Push Origin local_branch:remote_branch
説明
私は同じエラーがあり、それを理解しようとして何時間も費やしました。ついに見つけました。私が知らなかったのは、このgit Push Origin branch-xのようにプッシュすると、ローカルでbranch-xを検索し、次にリモートのbranch-xにプッシュしようとすることです。
私の場合、2つのリモートURLがありました。私はbranch-xからbranch-yにチェックアウトしましたyからxリモートにプッシュしようとすると、すべてが最新であるというメッセージがありました。これは通常の原因です。 2番目のリモートのxにプッシュしていました。
この種のtrapに陥らないようにするには、ソースrefとターゲットrefを指定する必要があります。
$ git Push Origin local_branch:remote_branch
上記のVonCの回答を参照してください-追加の手順が必要でした：
$ git log -1
- note the SHA-1 of latest commit
$ git checkout master
- reset your branch head to your previously detached commit
$ git reset --hard <commit-id>
私はこれをやったが、その後git Push remoterepo masterを試みたとき、それは言った 「エラー：いくつかの参照をプッシュできませんでした。履歴を失わないようにするため、早送り以外の更新は拒否されました。リモートの変更（例： 'git pull'）をマージしてから再度プッシュしてください。」
そこで、「git pull remoterepo master」を実行しましたが、競合が見つかりました。もう一度git reset --hard <commit-id>を実行し、競合するファイルをバックアップフォルダーにコピーし、git pull remoterepo masterを再度実行し、競合するファイルをプロジェクトにコピーし、git commitを実行してから、git Push remoterepo masterを実行しました。
Gitは「すべてが最新」であると言うのを止めました-そして、「早送り」について不満を言うのを止めました。
今日、この問題が発生しましたが、他の回答とは何の関係もありませんでした。ここに私がしたこととそれを修正した方法があります：
私のリポジトリは最近移動しましたが、ローカルコピーがありました。ローカルの「マスター」ブランチから分岐し、いくつかの変更を加えました。そして、リポジトリが移動したことを思い出しました。 git remote set-url Origin https://<my_new_repository_url>を使用して新しいURLを設定しましたが、プッシュすると、新しいブランチをマスターにプッシュする代わりに、「すべてが最新」と表示されます。
私はOrigin/masterにリベースし、次のように明示的なブランチ名でプッシュすることでそれを解決しました：
$ git rebase <my_branch> Origin/master
$ git Push Origin <my_branch>
これが私の同じ問題を抱えている人の助けになることを願っています！
あなたのgitステータスから、おそらくあなたは私のものとは異なる状況を持っているでしょう。
しかし、とにかく、ここに私に起こったことがあります。
fatal: The remote end hung up unexpectedly
Everything up-to-date
ここでより有益なメッセージは、リモートがハングアップしたことです。判明したのは、httpのポストバッファーサイズを超えているためです。解決策は、それを増やすことです
git config http.postBuffer 524288000
私は同様の状況に直面しています。変更を加えてgit Push Origin masterを試みたとき、すべてが最新であると言っていました。
変更したファイルをgit addしてから、git Push Origin masterにする必要がありました。それからそれは働き始めました。
私の間違いは、これまで述べてきたすべてのものとは異なりました。頭を切り離す理由がわからない場合は、おそらくそうではないでしょう。私はgit commitとgit Pushで自動操縦に取り組んでいて、git commitからの出力を読んでいませんでした。結局、-amを忘れたため、エラーメッセージでした。
[colin] ~/github/rentap.js [master] M % git commit 'figured out some more stuff with the forms in views and started figuring out row and mode in models so also made matching routes and controllers'
error: pathspec 'figured out some more stuff with the forms in views and started figuring out row and mode in models so also made matching routes and controllers' did not match any file(s) known to git.
[colin] ~/github/rentap.js [master] M % git Push
Enter passphrase for key '/home/colin/.ssh/id_ecdsa':
Everything up-to-date
私が通常行う場所に-amを置くことで修正しました：
[colin] ~/github/rentap.js [master] M % git commit -am 'figured out some more stuff with the forms in views and started figuring out row and mode in models so also made matching routes and controllers'
私の場合、2つのリモートリポジトリがありました。
git remote -v
originhttps https://asim_kt@...
originhttps https://asim_kt@...
Origin ssh:[email protected]:...
Origin ssh:[email protected]:...
両方のレポは同じでした。 1つだけがhttpsで、もう1つはsshでした。そのため、不要なものを削除すると（私の場合はssh。httpsが機能していなかったので、sshを使用していたので！）、この問題は修正されました。
Githubでブランチをマージし、ローカルで開発を続けたときに、私自身がこれに遭遇しました。私の修正は、提案されている他の修正とは少し異なっていました。
最初に、古いローカルブランチから新しいローカルブランチを分岐しました（プッシュできませんでした）。次に、新しいローカルブランチをOriginサーバー（Github）にプッシュしました。つまり.
$ git checkout -b newlocalbranch oldlocalbranch
$ git Push Origin newlocalbranch
これにより、oldlocalbranchではなくnewlocalbranchであるにもかかわらず、Githubに表示されるように変更されました。
非常にまれですが、それでも：Windowsでは、packed-refsには1つの大文字と小文字のブランチ（つまり、dev/mybranch）がありますが、refsフォルダーには別のケースがあります（つまり、Dev/mybranch）core.ignorecaseがtrueに設定されている場合。
解決策は、関連行をpacked-refsから手動で削除することです。よりクリーンなソリューションが見つかりませんでした。
別の可能性は、除外された.gitignoreファイルのディレクトリに名前を付けたことです。したがって、新しいコミットはプッシュされません。 「検索」を無視するディレクトリを指定したのは偶然でしたが、それはソースツリーのディレクトリでもありました。
リモートURLを間違えていないことを確認します。
また、ローカルJenkinsビルド構成でGitをCVSとして有効にした後、これに遭遇したことにも触れたいと思います。 Jenkinsは、私がそれを与えたブランチの最新のコミットをチェックアウトし、レポジトリに与えたパスに対応するようにリモートをリセットしたようです。機能ブランチを再度チェックアウトし、「git remote set-url」でOriginリモートURLを修正する必要がありました。ビルドツールを作業ディレクトリに向けないでください。リモートは作業ディレクトリへのファイルパスに設定されていたため、同じソースと宛先で変更をプッシュしようとすると、当然、最新のものがすべて報告されました。
私はこれを起こしました（gitログのコミットはGitHubにありませんでしたが、gitはすべてが最新であると言っていました）。問題はGithubであると確信しています。 gitでエラーメッセージは表示されませんでしたが、GitHubにはステータスエラーがあり、数時間後にコミットがありました。
https://status.github.com/messages
GitHubのステータスメッセージは次のとおりです。
- サービスが利用できないという報告を調査しています。
- GitHub.comへのアクセスに関する問題を調査しています。
- GitHub.comへのアクセスを復元するために、データストレージシステムをフェールオーバーしています。
私が見つけた簡単な方法があります。 .gitフォルダーに移動し、HEADファイルを開いて、マスターに戻るブランチを変更します。例えば。 ref：refs/heads/master
同じ問題がありました。私の場合、同じリモートに名前を付ける必要がありました。それは標準の「Origin」を作成しましたが、私は長い間「github」をリモコンとして使用していたので、それもそこにありました。 「Origin」リモートを削除するとすぐに、エラーはなくなりました。
私のもう1つの非常にシンプルでありながらヌーブな間違い：コミットに-m修飾子を追加するのを忘れました。だから私は書いた：
git commit 'My message'
正しい代わりに：
git commit -m 'My message'
注：エラーはスローされません！ただし、コミットをプッシュすることはできず、代わりに常にEverything up to dateを取得できます