git push dice "tutto aggiornato" anche se ho delle modifiche locali

Ho un server di gitosi remoto e un repository git locale e ogni volta che apporto una grande modifica al mio codice, invierò anche le modifiche a quel server.

Ma oggi trovo che, anche se ho alcune modifiche locali e mi impegno nel repository locale, quando git push origin masterlo eseguo dice "Tutto aggiornato", ma quando uso git cloneper verificare i file sul server remoto, non contiene le ultime modifiche . E ho solo un ramo chiamato "master" e un server remoto chiamato "origin".

PS: Questo è ciò che git mostra quando è in esecuzione ls-remote, non sono sicuro che possa aiutare

$ 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

Stai lavorando con una testa distaccata per caso?

Come in:

indicando che l'ultimo commit non è una diramazione.

Avvertenza : quanto segue git reset --hard: assicurarsi di utilizzare git stashprima se si desidera salvare i file attualmente modificati.

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

Come menzionato nella git checkoutpagina man (enfasi sulla mia):

A volte è utile essere in grado di effettuare il checkout di un commit che non si trova sulla punta di una delle filiali .
L'esempio più ovvio è verificare il commit in un punto di rilascio ufficiale con tag, come questo:

$ git checkout v2.6.18

Le versioni precedenti di git non lo consentivano e ti chiedevano di creare un ramo temporaneo usando l' -bopzione, ma a partire dalla versione 1.5.0, il comando sopra si stacca HEADdal ramo corrente e punta direttamente al commit chiamato dal tag ( v2.6.18nel esempio sopra).

Puoi usare tutti i comandi git mentre sei in questo stato.
È possibile utilizzare git reset --hard $othercommitper spostarsi ulteriormente, ad esempio.
È possibile apportare modifiche e creare un nuovo commit su HEAD distaccato .
Puoi persino creare un'unione usando git merge $othercommit.

Lo stato in cui ci si trova mentre HEAD è staccato non è registrato da alcun ramo (il che è naturale --- non ci si trova in nessun ramo).
Ciò significa che puoi scartare i tuoi commit e le tue fusioni temporanee tornando a una succursale esistente (ad es. git checkout master) E in un secondo momento git pruneo git gcvorrebbe raccoglierli.
Se lo hai fatto per errore, puoi chiedere al reflog di HEAD dove ti trovavi, ad es

$ git log -g -2 HEAD

Err .. Se sei un git noob sei sicuro di averlo fatto git commitprima git push? Ho fatto questo errore la prima volta!

Forse stai spingendo una nuova filiale locale?

Una nuova filiale locale deve essere spinta esplicitamente:

git push origin your-new-branch-name

Solo una di quelle cose su git ... Clonate un repository, fate un ramo, commettete alcune modifiche, spingete ... "Tutto è aggiornato". Capisco perché ciò accada, ma questo flusso di lavoro è estremamente ostile ai nuovi arrivati.

Il mio problema era che la mia filiale locale aveva un nome diverso da quello remoto. Sono stato in grado di spingere nel modo seguente:

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

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

Un'altra situazione di cui è importante tenere conto: il tipo di stato predefinito per git è che si sta lavorando nel ramo "master". E per molte situazioni, ti ritroverai come il tuo principale ramo di lavoro (anche se alcune persone si divertono e fanno altre cose).

Comunque, è solo un ramo. Quindi una situazione in cui potrei entrare è:

Il mio ramo attivo NON è in realtà il ramo principale. ... Ma di solito eseguo il comando: git push(e l'avevo già fatto in precedenza git push origin master, quindi è una scorciatoia per QUELLO).

Quindi sto spingendo abitualmente il ramo master nel repository condiviso ... che probabilmente è una buona cosa pulita, nel mio caso ...

Ma ho dimenticato che i cambiamenti a cui ho lavorato non sono ancora nel ramo principale !!!

Quindi ogni volta che provo git pushe vedo "Tutto aggiornato", voglio urlare, ma ovviamente non è colpa di Git! È mio.

Quindi, invece, unisco il mio ramo in master, quindi spingo e tutto è di nuovo felice.

$ git push origin local_branch:remote_branch

Spiegazione

Ho avuto lo stesso errore e ho passato ore a cercare di capirlo. Alla fine l'ho trovato. Quello che non sapevo è che spingendo in questo git push origin branch-xmodo proverai a cercare branch-x localmente, quindi a push su branch-x remoto.

Nel mio caso, avevo due URL remoti. Ho fatto un checkout da branch-x a branch-y quando ho provato a passare da y localmente a x remote Ho ricevuto il messaggio tutto aggiornato, il che è normale perché stavo spingendo a x del secondo telecomando.

Per farla breve, per non cadere in questo tipo di trappola è necessario specificare il riferimento sorgente e il riferimento bersaglio:

$ git push origin local_branch:remote_branch

Aggiornare:

Se devi eseguire questo comando ogni volta che invii il tuo ramo, potresti aver bisogno di impostare l'upstream tra il tuo ramo locale e remoto con il seguente:

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

O

$ git push -u origin local_branch:remote_branch

Vedi la risposta di VonC sopra: avevo bisogno di un passaggio in più:

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

L'ho fatto, ma quando ho provato a git push remoterepo masterfarlo, ha detto "errore: impossibile inviare alcuni riferimenti. Per impedirti di perdere la cronologia, gli aggiornamenti non avanzati sono stati rifiutati, prima di unire le modifiche remote (ad esempio" git pull ") spingendo di nuovo ".

Così ho fatto 'git pull remoterepo master', e ho trovato un conflitto. L'ho fatto di git reset --hard <commit-id>nuovo, ho copiato i file in conflitto in una cartella di backup, l'ho fatto di git pull remoterepo masternuovo , ho copiato i file in conflitto nel mio progetto git commit, quindi git push remoterepo master, e questa volta ha funzionato.

Git ha smesso di dire "tutto è aggiornato" e ha smesso di lamentarsi di "avanzamenti veloci".

Ho affrontato una situazione simile; quando ho apportato le modifiche e ci ho provato git push origin master, dicevo che tutto era aggiornato.

Ho dovuto git addcambiare il file e poi git push origin master. Ha iniziato a funzionare da allora in poi.

Dal tuo stato di git, probabilmente hai una situazione diversa dalla mia.

Ma comunque, ecco cosa mi è successo .. Ho riscontrato il seguente errore:

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

Il messaggio più informativo qui è che il telecomando ha riagganciato. Si è scoperto che è dovuto al superamento della dimensione del buffer post HTTP. La soluzione è aumentarla con

git config http.postBuffer 524288000

Ho avuto questo problema oggi e non ha avuto nulla a che fare con nessuna delle altre risposte. Ecco cosa ho fatto e come l'ho risolto:

Un mio repository è stato spostato di recente, ma avevo una copia locale. Mi sono ramificato dal mio ramo "master" locale e ho apportato alcune modifiche - e poi mi sono ricordato che il repository si era spostato. Prima git remote set-url origin https://<my_new_repository_url>imponevo il nuovo URL, ma quando lo spingevo dicevo "Tutto aggiornato" invece di spingere il mio nuovo ramo al master.

Ho finito per risolverlo riformulandomi origin/mastere spingendo con nomi di rami espliciti, in questo modo:

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

Spero che questo aiuti chiunque abbia avuto il mio stesso problema!

Super rare - ma ancora: in Windows, potrebbe essere che i -arbitri confezionati ha un ramo con un caso lettera (cioè dev / mybranch), mentre arbitri cartella ha un altro caso (cioè Dev / mybranch) quando core.ignorecase è impostata su true .

La soluzione consiste nell'eliminare manualmente la riga pertinente dai pacchetti-refs . Non ho trovato una soluzione più pulita.

Mi sono imbattuto in questo me stesso quando ho unito un ramo su Github e ho continuato a svilupparci localmente. La mia correzione era un po 'diversa dalle altre che sono state suggerite.

Prima ho ramificato un nuovo ramo locale dal mio vecchio ramo locale (che non potevo spingere). Quindi ho inviato il nuovo ramo locale al server di origine (Github). ie

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

Ciò ha portato i cambiamenti a presentarsi su Github, sebbene in newlocalbranch piuttosto che in oldlocalbranch.

Nel mio caso avevo 2 repository remoti.

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

Entrambi i pronti contro termine erano uguali. Solo uno era l' httpsaltro era ssh. Quindi, rimuovendo quello indesiderato, (nel mio caso, sshdato che l'ho usato httpsperché sshnon funzionava!) Risolto il problema per me.

Il mio errore è stato diverso da tutto ciò che è stato menzionato finora. Se non hai idea del perché avresti una testa staccata, probabilmente non lo fai. Stavo lavorando al pilota automatico con git commite git push, e non avevo letto l'output di git commit. Si è scoperto, è stato un messaggio di errore perché ho dimenticato -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

Risolto il problema ponendo -amdove di solito faccio:

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

Ho affrontato lo stesso problema. Poiché non ho aggiunto modifiche all'area di gestione temporanea. E ho provato direttamente a inviare il codice al repository remoto usando il comando:

git push origin master

E mostra il messaggio Everything up-to-date.

per risolvere questo problema, prova questi passaggi

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

Verifica di non aver ingannato il tuo URL remoto.

Volevo solo menzionare che mi sono imbattuto in questo dopo aver abilitato Git come CVS in una configurazione di build Jenkins locale. Sembra che Jenkins abbia verificato il commit più recente del ramo che gli ho dato e anche ripristinato il mio telecomando per corrispondere ai percorsi che ho dato al repository. Ho dovuto ricontrollare il mio ramo di funzionalità e correggere l'URL remoto di origine con 'git remote set-url'. Non puntare uno strumento di compilazione sulla tua directory di lavoro o avrai un brutto momento. Il mio telecomando era impostato su un percorso di file nella mia directory di lavoro, quindi ha riportato naturalmente tutto aggiornato quando ho tentato di inviare modifiche con la stessa origine e destinazione.

Un'altra possibilità è che hai nominato una directory nel tuo file .gitignore che è stata esclusa. Quindi i nuovi commit non verrebbero spinti. Mi è capitato di nominare una directory per ignorare la "ricerca", ma quella era anche una directory nel mio albero dei sorgenti.

C'è un modo rapido che ho trovato. Vai alla tua cartella .git, apri il HEADfile e cambia il ramo su cui ti trovavi. Ad esempio ref:refs/heads/master

Ho avuto lo stesso problema. Nel mio caso è stato causato dal dover nominare lo stesso telecomando. Ha creato la "origine" standard, ma ho usato "github" come telecomando per molto tempo, quindi anche quello era lì. Non appena ho rimosso il telecomando "origine", l'errore è scomparso.

Ho avuto questo successo (i miei commit nel mio log di git non erano su GitHub anche se git diceva che tutto era aggiornato) e sono sicuro che il problema fosse Github. Non ho ricevuto alcun messaggio di errore in Git, ma GitHub presentava errori di stato e il mio commit era lì diverse ore dopo.

https://status.github.com/messages

I messaggi di stato di GitHub erano:

• Stiamo esaminando segnalazioni di indisponibilità del servizio.
• Stiamo esaminando i problemi di accesso a GitHub.com.
• Stiamo fallendo un sistema di archiviazione dati per ripristinare l'accesso a GitHub.com.

Un altro mio errore molto semplice ma noobish: ho semplicemente dimenticato di aggiungere un -mmodificatore di messaggio nel mio commit. Quindi ho scritto:

git commit 'My message'

Invece di corretto:

git commit -m 'My message'

NOTA: NON genera errori! Ma non sarai in grado di spingere i tuoi impegni e ottenere sempre Everything up to dateinvece

qui, la mia soluzione è diversa da quella sopra. non ho capito come si presenta questo problema, ma l'ho risolto. un po 'inaspettatamente.

ora arriva il modo:

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

il comando che funziona per me è

$git push origin HEAD:use_local_cache

（Spero che voi ragazzi uscite da questo problema il prima possibile)

So che è super vecchio, ma nel mio caso l'ho risolto abbastanza rapidamente.

Stavo ottenendo lo stesso errore pur essendo un commit in anticipo master. Poi ho trovato l'attuale post Stack Overflow. Tuttavia, prima di procedere con le idee suggerite, ho appena deciso di fare un nuovo impegno e riprovare con la spinta all'origine e ha funzionato senza problemi.

Non so perché, ma forse è utile per qualcun altro.

Un'altra possibilità è che hai dei commit che non influenzano la directory che stai spingendo. Quindi nel mio caso avevo una struttura simile

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

E mi sono impegnato a padroneggiare la modifica README.md, quindi git subtree push --prefix client heroku-client masterho eseguito e ricevuto il messaggioEverything up-to-date

Stavo lavorando con Jupyter-Notebook quando ho riscontrato questo errore ingannevole.

Non sono stato in grado di risolvere le soluzioni fornite in precedenza poiché non avevo una testa distaccata né avevo nomi diversi per il mio repository locale e remoto .

Ma quello che avevo era che le mie dimensioni dei file erano leggermente superiori a 1 MB e la più grande era quasi ~ 2 MB . Ho ridotto la dimensione del file usando Come posso ridurre la dimensione del file del mio notebook iPython?tecnica. Mi ha aiutato a ridurre le dimensioni del mio file cancellando gli output. Sono stato in grado di spingere il codice, d'ora in poi perché ha portato la mia dimensione del file in KB.