Imansible inviare a GitHub – continua a dire che è necessario unire

Sono nuovo di GitHub . Oggi ho incontrato qualche problema quando stavo cercando di inviare il mio codice a GitHub.

Pushing to [email protected]:519ebayproject/519ebayproject.git To [email protected]:519ebayproject/519ebayproject.git ! [rejected] master -> master (non-fast-forward) error: failed to push some refs to '[email protected]:519ebayproject/519ebayproject.git' hint: Updates were rejected because the tip of your current branch is behind hint: its remote counterpart. Merge the remote changes (eg 'git pull') hint: before pushing again. hint: See the 'Note about fast-forwards' in 'git push --help' for details. 

Non ho ancora inserito nulla nel repository, quindi perché devo tirare qualcosa?

Ciò può causare la perdita di commit del repository remoto; usalo con cura

Se non desideri unire il ramo remoto al tuo ramo locale (vedi le differenze con git diff ), e vuoi fare un push forzato, usa il comando push con -f

 git push -f origin  

dove origin è il nome del tuo repository remoto .

Di solito, il comando si rifiuta di aggiornare un ref remoto che non è un antenato del ref locale usato per sovrascriverlo. Questo flag disabilita il controllo. Ciò può causare la perdita di commit del repository remoto; usalo con cura

Come ti dice il messaggio,

Unisci le modifiche remote (ad esempio ‘git pull’)

Usa git pull per estrarre le ultime modifiche dal repository remoto al tuo repository locale. In questo caso, l’estrazione delle modifiche richiederà un’unione perché hai apportato modifiche al tuo repository locale.

Fornirò un esempio e un’immagine da spiegare. Supponiamo che il tuo ultimo tiro da origine / ramo sia in Commit B. Hai completato e impegnato del lavoro (Commit C). Allo stesso tempo, qualcun altro ha completato il proprio lavoro e lo ha spinto all’origine / filiale (Commit D). Ci sarà bisogno di una fusione tra questi due rami.

 local branch: --- Commit C / / / origin/branch: Commit A ------ Commit B ---- Commit D 

Perché tu sei quello che vuole spingere, Git ti costringe a eseguire l’unione. Per fare ciò, devi prima tirare le modifiche da origine / ramo.

 local branch: --- Commit C -- Commit E / / / / / / origin/branch: Commit A ------ Commit B ---- Commit D 

Dopo aver completato l’unione, ora sarà ansible eseguire l’inoltro rapido di origine / ramo su Commit E, premendo le modifiche.

Git richiede che tu gestisca le fusioni te stesso, perché una fusione può portare a conflitti.

Hai aggiornato il tuo codice prima di premere?

Usa il git pull origin master prima di premere qualcosa.

Suppongo che tu stia utilizzando l’ origin come nome per il tuo telecomando.

È necessario tirare prima di premere, per aggiornare il repository locale prima di spingere qualcosa (nel caso in cui qualcun altro abbia già aggiornato il codice su github.com ). Questo aiuta a risolvere i conflitti localmente.

Normalmente ciò accade quando si git commit e si prova a git push modifiche git push prima che git pulling su quel ramo x dove qualcun altro ha già apportato modifiche.

Il stream normale sarebbe come sotto,

PASSO 1 : git stash tue modifiche locali non salvate su quel ramo.

PASSO 2 : git pull origin branch_name -v per pull and merge a modifiche localmente impegnate su quel ramo ( dare a questa unione un messaggio e correggere eventuali conflitti ) .

PASSO 3 : git stash pop le modifiche di stash ed editore ( Quindi puoi fare commit su file popped se vuoi o spingere per primo le modifiche già inserite (STEP4) e fare un nuovo commit ai file in seguito. )

PASSO 4 : git push origin branch_name -v le modifiche unite.

Sostituisci branch_name con master (per ramo master ).

A volte abbiamo dimenticato il pull e fatto un sacco di lavori nell’ambiente locale.

Se qualcuno vuole spingere senza tirare,

 git push --force 

sta lavorando. Questo non è raccomandato quando si lavora con altre persone, ma quando il tuo lavoro è una cosa semplice o un progetto di giocattolo personale, sarà una soluzione rapida.

Alcuni di voi potrebbero ricevere questo errore perché Git non sa quale ramo si sta tentando di spingere.

Se il tuo messaggio di errore include anche

 error: failed to push some refs to '[email protected]:jkubicek/my_proj.git' hint: Updates were rejected because a pushed branch tip is behind its remote hint: counterpart. If you did not intend to push that branch, you may want to hint: specify branches to push or set the 'push.default' configuration hint: variable to 'current' or 'upstream' to push only the current branch. 

quindi puoi seguire i consigli pratici di Jim Kubicek, Configura Git per spingere solo il ramo corrente , per impostare il ramo predefinito su corrente.

 git config --global push.default current 

Oltre alle risposte sopra, per me ha funzionato: –

Scenario –

  1. Ho spinto my_branch all’origine con successo.
  2. Ho apportato poche altre modifiche.
  3. Quando ho provato a spingere di nuovo, (dopo aver aggiunto, commit, ovviamente), ho ricevuto l’errore sopra menzionato.

Soluzione –

  1. git checkout **my_branch** 2. git add, commit your changes. 3. git pull origin **my_branch** (not origin, master, or develop) 4. git push origin **my_branch** 

Prova

 git pull origin branch_name --rebase 

Questo ha funzionato per me – il comando git pull origin branch_name --rebase le modifiche da remote branch_name all’inizio, quindi eseguirà il rebase ramo corrente in cima ad esso.

Ho avuto lo stesso problema, quello che ho fatto è stato prima spingerlo con la forza usando questo

 git push --force 

L’ho fatto dopo aver eseguito il commit dei file e ho ricevuto un errore. Avevi commesso tutti i file e li ha spinti. Poi la volta successiva che stavo spingendo verso il GitHub. Feci quello che mi chiedeva e andava bene allora. Spero che questo funzioni anche per te 🙂

Ho menzionato questo nel mio tutorial, Come usare GitHub: un tutorial per principianti .

Quando crei un nuovo repository su GitHub, GitHub potrebbe chiederti di creare un file Leggimi. Se crei un file leggimi direttamente su GitHub, dovrai prima effettuare una richiesta di “pull” prima che la richiesta “push” abbia esito positivo. Questi comandi “estrae” il repository remoto, lo uniscono ai file correnti e quindi “spinge” tutti i file su GitHub:

 git pull https://github.com/thomas07vt/MyFirstRepo.git master git push https://github.com/thomas07vt/MyFirstRepo.git master 

git push -f nome di origine di origine

Utilizzare il comando precedente solo se si è certi di non aver bisogno del codice di diramazione remoto, altrimenti fondersi prima e quindi premere il codice

Stavo ricevendo il messaggio di errore sopra menzionato quando ho provato a spingere il mio ramo corrente:

 git checkout foobar git push origin foo 

Risulta che ho avuto due filiali locali che seguono lo stesso ramo remoto:

 foo -> origin/foo (some old branch) foobar -> origin/foo (my current working branch) 

Ha funzionato per me per spingere il mio attuale ramo usando:

 git push origin foobar:foo 

… e per ripulire con git branch -d

Ho appena avuto lo stesso problema, ma nel mio caso ho digitato il ramo sbagliato sul telecomando. Quindi, sembra che sia un’altra fonte di questo problema … ricontrolla il tuo ramo corretto.

Ho avuto un problema simile e ho scoperto che il mio stream di lavoro per mantenere aggiornato il mio ramo era sbagliato. Stavo facendo quanto segue:

Nel mio “maestro” locale

 git fetch upstream git merge upstream/master --ff-only 

poi di nuovo nella mia filiale locale

 git rebase master 

Questo ha funzionato bene per un precedente stream git ma non con github. Il git rebase era il problema che causava problemi con la sincronizzazione (e ammetto che è qualcosa che ho dovuto accettare senza una piena comprensione) e sfortunatamente mi ha messo in una posizione in cui git push -f diventato probabilmente l’opzione più semplice. Non bene.

Il mio nuovo stream è di aggiornare il ramo direttamente usando git merge come segue:

Nella mia filiale locale

 git fetch upstream git merge upstream/master 

Nessun avanzamento veloce, poiché avrò apportato cambiamenti ovviamente nella filiale locale.

Come probabilmente puoi dire, non sono un esperto di git, ma sono sicuro che questo stream di lavoro probabilmente eviterà i problemi specifici che ho avuto.

Se non vuoi entrare nel tuo attuale progetto (e potenzialmente affrontare conflitti di fusione che non ti interessa risolvere) e non vuoi creare un altro ramo (Questo sarà noioso gestire un altro ramo), e tu don Non voglio fare alcun comando di force git rischioso e permanente (che anche dopo aver letto quello che fanno sono spesso sorpreso dalle implicazioni di farlo).

Soluzione : puoi semplicemente trascinare il contenuto della cartella in un’altra cartella, trascinare il progetto nella cartella ora vuota, trascinare il contenuto estratto nel cestino, quindi trascinare di nuovo il progetto corretto nella cartella. Dovresti essere in grado di spingere correttamente e ottenere i risultati desiderati. Mi ci vuole letteralmente meno di 10 secondi per farlo.

Per le persone che mi direbbero che questo non è corretto senza citare alcuna conseguenza, o la gente che mi dice di usare un comando che mi provoca fastidi futuri, dico: “Questo metodo richiede letteralmente meno di 10 secondi”. Se incontro un comando git che richiede meno di 10 secondi per implementare e ha lo stesso identico effetto, lo adotterò. Fino ad allora, sto usando questo metodo.

Uno svantaggio di questo metodo è che la cronologia dei commit apparirà lineare quando si è effettivamente uniti in un ramo senza che l’unione sia documentata. Questo potrebbe non essere il metodo migliore quando si lavora con i gruppi. Lavora sui rami in questi casi!

Nel mio caso, ho avuto “mybranch” estratto e ho fatto il git pull , quindi non sono riuscito a capire perché la spinta non funzionava. Alla fine, ho capito che stavo spingendo il ramo sbagliato. Stavo digitando git push origin master invece di git push origin mybranch .

Quindi, se hai già fatto git pull e git pull ancora questo messaggio, assicurati di spingere il ramo corretto.

Ho sperimentato lo stesso problema e ho scoperto che ero su un ramo diverso (locale) di quanto pensassi di essere E il ramo locale corretto era dietro in commit da remoto.

La mia soluzione: controlla il ramo corretto, seleziona il commit dall’altro ramo locale, git pull e git push

Stavo ottenendo un errore simile mentre spingevo le ultime modifiche a un repository Git che uso per gitweb . Nel mio caso non ho apportato alcuna modifica al repository nudo, quindi ho semplicemente cancellato il mio repository nudo e clonato nuovamente:

 git clone --bare   

Il nome del tuo ramo è uguale al nome del ramo remoto?

Se no, dovresti provare un nuovo ramo con lo stesso nome del ramo remoto e provare a spingerlo di nuovo.

Si supponga che il ramo remoto che si desidera inviare sia [ testing ] e il ramo locale sia denominato [ test ].

Se non si è nel ramo di test , passare prima ad esso.

 git checkout test 

Quindi apri un nuovo ramo e chiamalo test .

 git checkout -b testing 

Ora è il momento di spingerlo:

 git push [remote repo] testing 

Ho risolto questo problema nel mio repository GIT. Non è necessario rebase o force commit in questo caso. Usa i seguenti passaggi per risolvere questo –

 local_barnch> git branch --set-upstream to=origin/ local_barnch>git pull origin  local_barnch> git branch --set-upstream to=origin/master local_barnch>git push origin  

spero che possa essere d’aiuto

Prima e semplice soluzione

  • Prova questo comando git push -f origin master .
  • Questo comando eseguirà tutte le modifiche necessarie al tuo repository.

Soluzione raccomandata

  • Elimina la cartella .git dalla cartella.
  • Quindi esegui questi comandi:

     git init git add . git commit -m "First Commit" git remote add origin [url] git push -u origin master 

O

 git push -f origin master 

Utilizzare solo git push -f origin master se -u non funziona per voi.

Questo risolverà quasi tutti i tipi di errori che si verificano mentre si spingono i file.

Un’altra soluzione è far avanzare la testa del telecomando facendo un altro commit se puoi. Dopo aver tirato questa testa avanzata nella sottostruttura locale, sarai in grado di respingerla nuovamente.

Se sei sicuro che nessuno ha apportato modifiche al tuo repository git e che stai lavorando alla versione più recente, git pull non ha senso come soluzione nel tuo cuore …

Allora questo è probabilmente quello che è successo, hai usato git commit --amend

Ti consente di combinare le modifiche in fasi con il commit precedente invece di impostarlo come un’istantanea completamente nuova. Può anche essere usato per modificare semplicemente il precedente messaggio di commit senza cambiarne l’istantanea.

Tutorial ATLASSIANO: riscrittura della cronologia

Tuttavia, non è consigliabile eseguire git commit --amend se hai già premuto il commit su GitHub , questo perché “la modifica non altera solo il commit più recente – lo sostituisce interamente.” Per Git, sembrerà un nuovo commit “che significa per un altro sviluppatore sul tuo GitHub, la cronologia sembra A-> B-> C ma a te assomiglia ad A-> B-> D, se GitHub ti lascia push , tutti gli altri dovranno manualmente correggi la loro storia

Questo è il motivo per cui ricevi il messaggio di errore ! [rejected] master -> master (non-fast-forward) ! [rejected] master -> master (non-fast-forward) , se sai che nessuno ha tirato le tue ultime modifiche, puoi fare git push --force , questo cambierà la cronologia git nel tuo repository pubblico . Altrimenti … puoi eseguire git pull , ma credo che questo avrà lo stesso risultato di come non hai passato git commit --amend , creerà un nuovo commit (es: git history dopo git pull: A-> B-> C-> D)

per maggiori dettagli: Come cambiare il tuo ultimo commit

Il problema con il comando push è che il tuo repository locale e remoto non corrisponde. SE si inizializza readme per impostazione predefinita quando si crea un nuovo repository da git hub, quindi il ramo master viene creato automaticamente. Tuttavia, quando provi a spingere questo non ha alcun ramo. non si può spingere … Quindi, la procedura migliore è creare un repository senza inizializzazione predefinita del readme.

Un’altra causa di questo problema (apparentemente non così comune) …

Il mio server era dietro ~ 12 ore quando ho fatto una spinta

Ho configurato NTP sul server Sincronizza il mio orologio.

Ho eseguito una nuova git push che ha portato l’errore discusso in questo post.

Se per caso git pull Already up-to-date allora potresti voler controllare il parametro git push.default globale (in ~/.gitconfig ). Impostalo su simple se era in matching . La risposta qui sotto spiega perché:

Git – Qual è la differenza tra push.default “matching” e “simple”

Inoltre, vale la pena controllare se la tua filiale locale non è stata aggiornata usando git remote show origin e fare un pull, se necessario

usa git pull https://github.com/username/repository È perché Github e gli archivi remoti non sono sincronizzati. Se si pull il repository e poi si Push tutto sarà sincronizzato e l’errore andrà via.

`

git pull prints Già up-to-date

soluzione:

potresti essere creato un repository / progetto in remoto (server) e aggiunto qualche file lì, Poi di nuovo creato una cartella nel tuo locale e inizializzato git git init – questo è l’ errore , non dovresti creare git init in locale, ma clonare il progetto al tuo locale usando git clone

quindi tira

Un’altra opzione: rinominare localmente il tuo ramo con qualcosa di nuovo.

Sarai quindi in grado di inviarlo al repository remoto, ad esempio se questo è il tuo modo di conservare una copia (backup) e assicurarti che nulla vada perso.

Puoi recuperare il ramo remoto per avere una copia locale ed esaminare le differenze tra (i) cosa aveva il telecomando (con il vecchio nome del ramo) e (ii) quello che hai (con il nuovo nome del ramo), e decidere cosa fare . Dal momento che non eri a conoscenza delle differenze del telecomando in primo luogo (da qui il problema), semplicemente unire o forzare le modifiche da qualche parte è troppo brutale.

Guarda le differenze, scegli il ramo su cui vuoi lavorare, seleziona i cambiamenti che vuoi dall’altro ramo, o ripristina le modifiche che non vuoi sul ramo che hai, ecc.

Quindi dovresti essere in grado di decidere se vuoi forzare la tua versione pulita sul telecomando, o aggiungere nuove modifiche, o qualsiasi altra cosa.

A condizione che nessun altro stia lavorando con una filiale, la mia ipotesi è che tu abbia fatto quanto segue:

 1. $git commit #you committed your changes. 2. $git push origin  #you pushed your commit to remote origin (yeah, success!) 3. $git commit --amend #you did some changes locally and committed with --amend 4. $git push origin  #you pushed the "old", just amended commit to the remote origin and you thought "WTF?". 

Il passaggio 4. è la causa del tuo problema, imho …