Git Push sagt "alles auf dem neuesten Stand", obwohl ich lokale Änderungen habe

Ich habe einen Remote-Gitosis-Server und ein lokales Git-Repository. Jedes Mal, wenn ich eine große Änderung an meinem Code vornehme, werde ich die Änderungen auch auf diesen Server übertragen.

Aber heute stelle ich fest, dass, obwohl ich einige lokale Änderungen habe und mich für das lokale Repository festschreibe, beim Ausführen git push origin master"Alles auf dem neuesten Stand" steht, aber wenn ich git cloneDateien auf dem Remote-Server auschecke, enthält es keine neuesten Änderungen . Und ich habe nur einen Zweig namens "master" und einen Remote-Server namens "origin".

PS: Dies ist, was Git beim Laufen anzeigt ls-remote. Ich bin mir nicht sicher, ob es hilft

$ 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

Arbeiten Sie zufällig mit einem abgetrennten Kopf ?

Wie in:

Dies zeigt an, dass Ihr letztes Commit kein Zweigstellenleiter ist.

Warnung : Folgendes führt Folgendes aus git reset --hard: Stellen Sie sicher, dass Sie git stashzuerst verwenden, wenn Sie Ihre aktuell geänderten Dateien speichern möchten.

$ 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>

Wie in der git checkoutManpage erwähnt (Hervorhebung von mir):

Es ist manchmal nützlich, ein Commit auschecken zu können , das sich nicht an der Spitze eines Ihrer Zweige befindet .
Das naheliegendste Beispiel ist das Auschecken des Commits an einem markierten offiziellen Veröffentlichungspunkt wie folgt:

$ git checkout v2.6.18

Frühere Versionen von git haben dies nicht zugelassen und Sie aufgefordert, einen temporären Zweig mit der -bOption zu erstellen. Ab Version 1.5.0 löst der obige Befehl Ihren HEADvom aktuellen Zweig und zeigt direkt auf das vom Tag benannte Commit ( v2.6.18in der Beispiel oben).

In diesem Zustand können Sie alle Git-Befehle verwenden.
Sie können git reset --hard $othercommitsich beispielsweise weiter bewegen.
Sie können Änderungen vornehmen und ein neues Commit über einem abgetrennten HEAD erstellen .
Sie können sogar eine Zusammenführung erstellen, indem Sie verwenden git merge $othercommit.

Der Zustand, in dem Sie sich befinden, während Ihr HEAD getrennt ist, wird von keinem Zweig aufgezeichnet (was natürlich ist - Sie befinden sich in keinem Zweig).
Dies bedeutet, dass Sie Ihre temporären Commits und Zusammenführungen verwerfen können, indem Sie zu einem vorhandenen Zweig (z. B. git checkout master) zurückkehren und ihn später git pruneoder später git gcdurch Müllabfuhr sammeln.
Wenn Sie dies versehentlich getan haben, können Sie das Reflog nach HEAD fragen, wo Sie sich befanden, z

$ git log -g -2 HEAD

Err .. Wenn Sie ein git Noob sind , sind Sie sicher , dass Sie git commitvor git push? Ich habe diesen Fehler das erste Mal gemacht!

Vielleicht drängen Sie eine neue lokale Niederlassung?

Ein neuer lokaler Zweig muss explizit verschoben werden:

git push origin your-new-branch-name

Nur eines dieser Dinge über Git ... Sie klonen ein Repo, machen einen Zweig, übernehmen einige Änderungen, drücken ... "Alles ist auf dem neuesten Stand". Ich verstehe, warum es passiert, aber dieser Workflow ist für Neulinge äußerst unfreundlich.

Mein Problem war, dass meine lokale Niederlassung einen anderen Namen hatte als die entfernte Niederlassung. Ich konnte pushen, indem ich Folgendes tat:

$ git push origin local-branch-name:remote-branch-name

(Gutschrift an https://penandpants.com/2013/02/07/git-pushing-to-a-remote-branch-with-a-different-name/ )

Eine andere Situation, die Sie unbedingt beachten sollten: Der Standardstatus für git ist, dass Sie im Zweig "master" arbeiten. Und für viele Situationen werden Sie sich einfach als Hauptarbeitszweig darin aufhalten (obwohl manche Leute Lust haben und andere Dinge tun).

Jedenfalls ist das nur ein Zweig. Eine Situation, in die ich geraten könnte, ist:

Mein aktiver Zweig ist eigentlich NICHT der Hauptzweig. ... Aber ich mache gewöhnlich den Befehl: git push(und ich hatte es zuvor getan git push origin master, also ist es eine Abkürzung für DAS).

Also schiebe ich den Hauptzweig gewöhnlich auf das gemeinsame Repo ... was in meinem Fall wahrscheinlich eine gute, saubere Sache ist ...

Aber ich habe vergessen, dass die Änderungen, an denen ich gearbeitet habe, noch nicht in der Hauptniederlassung sind !!!

Deshalb möchte ich jedes Mal git push, wenn ich es versuche und "Alles auf dem neuesten Stand" sehe, schreien, aber natürlich ist es nicht die Schuld von git! Es gehört mir.

Also füge ich stattdessen meinen Zweig zum Master zusammen und drücke dann, und alles ist wieder glücklich.

$ git push origin local_branch:remote_branch

Erläuterung

Ich hatte den gleichen Fehler und verbrachte Stunden damit, es herauszufinden. Endlich habe ich es gefunden. Was ich nicht wusste ist, dass ich so drückegit push origin branch-x versucht wird, lokal nach branch-x zu suchen und dann auf remote branch-x zu pushen.

In meinem Fall hatte ich zwei Remote-URLs. Ich habe einen Checkout von Branch-X zu Branch-Y durchgeführt, als ich versucht habe, von y lokal auf x remote zu pushen. Ich hatte die Meldung, dass alles auf dem neuesten Stand ist, was normal ist, weil ich auf x der zweiten Remote pushe.

Lange Rede, kurzer Sinn, um nicht in diese Art von Falle zu geraten, müssen Sie die Quellreferenz und die Zielreferenz angeben:

$ git push origin local_branch:remote_branch

Aktualisieren:

Wenn Sie diesen Befehl jedes Mal ausführen müssen, wenn Sie Ihren Zweig pushen, müssen Sie möglicherweise den Upstream zwischen Ihrem lokalen und Remote-Zweig wie folgt einstellen:

$ git push --set-upstream origin local_branch:remote_branch

Oder

$ git push -u origin local_branch:remote_branch

Siehe VonCs Antwort oben - ich brauchte einen zusätzlichen Schritt:

$ 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>

Ich habe dies getan, aber als ich es dann versuchte, git push remoterepo masterstand dort "Fehler: Einige Refs konnten nicht gepusht werden. Um zu verhindern, dass Sie den Verlauf verlieren, wurden Aktualisierungen ohne schnellen Vorlauf abgelehnt. Führen Sie die Remote-Änderungen (z. B." Git Pull ") zuvor zusammen wieder drücken. "

Also habe ich 'git pull remoterepo master' gemacht und es wurde ein Konflikt gefunden. Ich habe es git reset --hard <commit-id>erneut getan , die in Konflikt stehenden Dateien in einen Sicherungsordner git pull remoterepo masterkopiert , es erneut getan , die in Konflikt stehenden Dateien wieder in mein Projekt kopiert, es git commitdann getan git push remoterepo master, und diesmal hat es funktioniert.

Git hörte auf zu sagen, "alles ist auf dem neuesten Stand" - und beschwerte sich nicht mehr über "Schnellvorlauf".

Ich habe eine ähnliche Situation erlebt; Als ich die Änderungen vornahm und es versuchte git push origin master, hieß es, alles sei auf dem neuesten Stand.

Ich musste git adddie geänderte Datei und dann git push origin master. Von da an fing es an zu arbeiten.

Von Ihrem Git-Status haben Sie wahrscheinlich eine andere Situation als ich.

Aber trotzdem, hier ist was mit mir passiert ist. Ich bin auf den folgenden Fehler gestoßen:

fatal: The remote end hung up unexpectedly
Everything up-to-date

Die informativere Nachricht hier ist, dass die Fernbedienung aufgelegt hat. Es stellte sich heraus, dass dies auf die Überschreitung der http-Post-Puffergröße zurückzuführen ist. Die Lösung besteht darin, es mit zu erhöhen

git config http.postBuffer 524288000

Ich hatte dieses Problem heute und es hatte nichts mit den anderen Antworten zu tun. Folgendes habe ich getan und wie ich es behoben habe:

Ein Repository von mir ist kürzlich umgezogen, aber ich hatte eine lokale Kopie. Ich habe mich von meinem lokalen "Master" -Zweig getrennt und einige Änderungen vorgenommen - und dann habe ich mich daran erinnert, dass das Repository verschoben wurde. Früher habe ich git remote set-url origin https://<my_new_repository_url>die neue URL festgelegt, aber wenn ich sie gedrückt habe, wurde nur "Alles auf dem neuesten Stand" angezeigt, anstatt meinen neuen Zweig an den Master zu senden.

Am Ende löste ich es, indem ich auf origin/masterexplizite Zweignamen umbasierte und dann darauf drückte:

$ git rebase <my_branch> origin/master
$ git push origin <my_branch>

Ich hoffe das hilft jedem, der das gleiche Problem hatte!

Super selten - aber dennoch: Unter Windows kann es sein, dass gepackte Refs einen Zweig mit einem Buchstaben (dh dev / mybranch) haben, während refs Ordner einen anderen Fall (dh Dev / mybranch) hat, wenn core.ignorecase auf true gesetzt ist .

Die Lösung besteht darin, die relevante Zeile manuell aus gepackten Referenzen zu löschen . Ich habe keine sauberere Lösung gefunden.

Ich bin selbst darauf gestoßen, als ich eine Niederlassung auf Github zusammengelegt und mich dort lokal weiterentwickelt habe. Mein Fix war etwas anders als die anderen, die vorgeschlagen wurden.

Zuerst habe ich eine neue lokale Niederlassung von meiner alten lokalen Niederlassung abgezweigt (die ich nicht pushen konnte). Dann habe ich den neuen lokalen Zweig auf den Ursprungsserver (Github) verschoben. Dh

$ git checkout -b newlocalbranch oldlocalbranch
$ git push origin newlocalbranch

Dies führte dazu, dass die Änderungen auf Github angezeigt wurden, allerdings eher in newlocalbranch als in oldlocalbranch.

In meinem Fall hatte ich 2 Remote-Repos.

git remote -v
originhttps https://asim_kt@...
originhttps https://asim_kt@...
origin  ssh:git@bitbucket.org:...
origin  ssh:git@bitbucket.org:...

Beide Repo waren gleich. Nur einer war der httpsandere ssh. Das Entfernen des unerwünschten (in meinem Fall, sshda ich es verwendet habe, httpsweil sshes nicht funktioniert hat!) Behebt das Problem für mich.

Mein Fehler war anders als alles, was bisher erwähnt wurde. Wenn Sie keine Ahnung haben, warum Sie einen abgetrennten Kopf haben würden, dann tun Sie dies wahrscheinlich nicht. Ich habe mit git commitund am Autopiloten gearbeitet und git pushdie Ausgabe von nicht gelesen git commit. Es stellte sich heraus, dass es eine Fehlermeldung war, weil ich -am vergessen habe.

[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

Es wurde behoben, indem ich -amdort platzierte , wo ich normalerweise bin:

[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'

Ich habe das gleiche Problem konfrontiert. Da ich dem Staging-Bereich keine Änderungen hinzugefügt habe. Und ich habe direkt versucht, den Code mit dem folgenden Befehl auf Remote Repo zu übertragen:

git push origin master

Und es zeigt die Nachricht Everything up-to-date.

Führen Sie die folgenden Schritte aus, um dieses Problem zu beheben

1. git add .
2. git commit -m "Bug Fixed"
3. git push -u origin master

Stellen Sie sicher, dass Sie Ihre Remote-URL nicht vermasselt haben.

Ich wollte nur erwähnen, dass ich darauf gestoßen bin, nachdem ich Git als CVS in einer lokalen Jenkins-Build-Konfiguration aktiviert hatte. Es scheint, dass Jenkins das letzte Commit des Zweigs, den ich ihm gegeben habe, überprüft und auch meine Fernbedienung zurückgesetzt hat, um den Pfaden zu entsprechen, die ich dem Repo gegeben habe. Musste meinen Feature-Zweig erneut auschecken und meine ursprüngliche Remote-URL mit 'git remote set-url' korrigieren. Zeigen Sie nicht mit einem Build-Tool auf Ihr Arbeitsverzeichnis, sonst haben Sie eine schlechte Zeit. Meine Fernbedienung war auf einen Dateipfad zu meinem Arbeitsverzeichnis eingestellt, sodass natürlich alles auf dem neuesten Stand war, als ich versuchte, Änderungen mit derselben Quelle und demselben Ziel zu übertragen.

Eine andere Möglichkeit besteht darin, dass Sie ein Verzeichnis in Ihrer Gitignore-Datei benannt haben, das ausgeschlossen wurde. Die neuen Commits würden also nicht vorangetrieben. Es ist mir passiert, dass ich ein Verzeichnis benannt habe, um "Suche" zu ignorieren, aber das war auch ein Verzeichnis in meinem Quellbaum.

Ich habe einen schnellen Weg gefunden. Gehen Sie zu Ihrem .git-Ordner, öffnen Sie die HEADDatei und ändern Sie den Zweig, in dem Sie sich befanden, wieder in master. ZB ref:refs/heads/master

Ich hatte das gleiche Problem. In meinem Fall wurde dies dadurch verursacht, dass Namen für dieselbe Fernbedienung erforderlich waren. Es wurde der Standard-Ursprung erstellt, aber ich habe lange Zeit "Github" als Fernbedienung verwendet, also war das auch da. Sobald ich die 'Origin'-Fernbedienung entfernt hatte, verschwand der Fehler.

Ich hatte dies geschehen (Commits in meinem Git-Protokoll waren nicht auf GitHub, obwohl Git sagte, dass alles auf dem neuesten Stand war) und ich bin zuversichtlich, dass das Problem Github war. Ich habe in git keine Fehlermeldungen erhalten, aber GitHub hatte Statusfehler und meine Commits waren einige Stunden später da.

https://status.github.com/messages

Die GitHub-Statusmeldungen lauteten:

• Wir untersuchen Berichte über die Nichtverfügbarkeit von Diensten.
• Wir untersuchen Probleme beim Zugriff auf GitHub.com.
• Wir führen ein Failover eines Datenspeichersystems durch, um den Zugriff auf GitHub.com wiederherzustellen.

Ein weiterer sehr einfacher, aber noobischer Fehler von mir: Ich habe einfach vergessen, einen Nachrichtenmodifikator -min mein Commit aufzunehmen. Also schrieb ich:

git commit 'My message'

Anstelle von richtig:

git commit -m 'My message'

HINWEIS: Es werden KEINE Fehler ausgegeben! Aber Sie werden nicht in der Lage sein, Ihre Commits zu pushen und immer Everything up to datestattdessen zu bekommen

hier unterscheidet sich meine Lösung von der oben genannten. Ich habe nicht herausgefunden, wie dieses Problem passiert, aber ich habe es behoben. ein wenig unerwartet.

jetzt kommt weg:

$ git push origin  use_local_cache_v1
Everything up-to-date
$ git status
On branch test
Your branch is ahead of 'origin/use_local_cache_v1' by 4 commits.
  (use "git push" to publish your local commits)
  ......
$ git push
fatal: The upstream branch of your current branch does not match
the name of your current branch.  To push to the upstream branch
on the remote, use

    git push origin HEAD:use_local_cache_v1

To push to the branch of the same name on the remote, use

    git push origin test
    
$ git push origin HEAD:use_local_cache_v1    
Total 0 (delta 0), reused 0 (delta 0)
remote:

Der Befehl, der für mich funktioniert, ist

$git push origin HEAD:use_local_cache

（Hoffe ihr kommt so schnell wie möglich aus diesen Schwierigkeiten heraus)

Ich weiß, dass es super alt ist, aber in meinem Fall habe ich es ziemlich schnell behoben.

Ich habe den gleichen Fehler erhalten, als ich ein Commit voraus war master . Dann habe ich den aktuellen Stack Overflow-Beitrag gefunden. Bevor ich jedoch mit den vorgeschlagenen Ideen fortfuhr, entschied ich mich, ein neues Commit zu machen und es erneut mit dem Push-to-Origin zu versuchen, und es funktionierte reibungslos.

Ich weiß nicht warum, aber vielleicht ist es für jemand anderen nützlich.

Eine andere Möglichkeit besteht darin, dass Sie Commits haben, die sich nicht auf das Verzeichnis auswirken, das Sie verschieben. In meinem Fall hatte ich also eine Struktur wie

- .git
- README.md
- client/
 - package.json
 - example.js
- api/
 - requirements.txt
 - example.py

Und ich habe mich verpflichtet, das Modifizieren zu meistern README.md, bin dann gelaufen git subtree push --prefix client heroku-client masterund habe die Nachricht erhaltenEverything up-to-date

Ich habe mit Jupyter-Notebook gearbeitet, als ich auf diesen irreführenden Fehler gestoßen bin.

Ich konnte durch die oben angegebenen Lösungen keine Lösung finden, da ich weder einen abgetrennten Kopf hatte noch unterschiedliche Namen für mein lokales und Remote- Repo hatte.

Aber was ich tat , war habe meine Dateigrößen waren etwas größer als 1 MB und der größte war fast ~ 2MB . Ich habe die Dateigröße mit reduziert Wie kann ich die Dateigröße meines iPython-Notebooks reduzieren?Technik. Es hat mir geholfen, meine Dateigröße zu reduzieren, indem ich die Ausgaben gelöscht habe. Ich konnte den Code fortan pushen, da er meine Dateigröße in KBs brachte.