Come faccio a inviare il commit modificato al repository Git remoto?

Quando ho lavorato un po 'con il mio codice sorgente, ho fatto il mio solito impegno e poi ho spinto in un repository remoto. Ma poi ho notato che ho dimenticato di organizzare le mie importazioni nel codice sorgente. Quindi eseguo il comando di modifica per sostituire il commit precedente:

> git commit --amend

Sfortunatamente il commit non può essere rinviato al repository. Viene rifiutato in questo modo:

> git push origin
To //my.remote.repo.com/stuff.git/
 ! [rejected]        master -> master (non-fast forward)
error: failed to push some refs to '//my.remote.repo.com/stuff.git/'

Cosa dovrei fare? (Posso accedere al repository remoto.)

In realtà una volta ho spinto --forcee .gitrepository e sono stato sgridato da Linus BIG TIME . In generale, ciò creerà molti problemi per altre persone. Una semplice risposta è "Non farlo".

Vedo che gli altri hanno dato la ricetta per farlo comunque, quindi non li ripeterò qui. Ma ecco un suggerimento per riprendersi dalla situazione dopo aver eliminato il commit modificato con --force (o + master).

1. Usa git reflogper trovare il vecchio commit che hai modificato (chiamalo olde chiameremo il nuovo commit che hai creato modificando new).
2. Crea una fusione tra olde new, registrando l'albero di new, come git checkout new && git merge -s ours old.
3. Uniscilo al tuo padrone con git merge master
4. Aggiorna il tuo master con il risultato con git push . HEAD:master
5. Sposta il risultato.

Poi le persone che hanno avuto la sfortuna di avere basato il loro lavoro sulla commit si cancellato dalla modifica e costringendo una spinta vedrà l'unione risultante vedrà che sei a favore newsopra old. Le loro successive fusioni non vedranno i conflitti tra olde newrisultanti dalla tua modifica, quindi non devono soffrire.

Stai vedendo una funzione di sicurezza Git. Git si rifiuta di aggiornare il ramo remoto con il proprio ramo, poiché il commit principale del proprio ramo non è un diretto discendente dell'attuale head commit del ramo verso cui si sta spingendo.

Se così non fosse, allora due persone che spingono nello stesso repository nello stesso momento non saprebbero che ci sarebbe stato un nuovo commit in arrivo allo stesso tempo e chiunque avesse spinto per ultimo avrebbe perso il lavoro del precedente spintore senza nessuno dei due realizzando questo.

Se sai di essere l'unica persona che spinge e desideri inviare un commit modificato o inviare un commit che riavvolge il ramo, puoi "forzare" Git ad aggiornare il ramo remoto usando l' -finterruttore.

git push -f origin master

Anche questo potrebbe non funzionare poiché Git consente ai repository remoti di rifiutare spinte non veloci dall'altra parte usando la variabile di configurazione receive.denynonfastforwards. In questo caso, il motivo del rifiuto sarà simile al seguente (notare la parte "rifiutato a distanza"):

 ! [remote rejected] master -> master (non-fast forward)

Per ovviare a questo, è necessario modificare la configurazione del repository remoto o come hack sporco è possibile eliminare e ricreare il ramo in questo modo:

git push origin :master
git push origin master

In generale, l'ultimo parametro git pushutilizza il formato <local_ref>:<remote_ref>, dove local_refè il nome del ramo nel repository locale ed remote_refè il nome del ramo nel repository remoto. Questa coppia di comandi utilizza due shorthands. :masterha un local_ref nullo che significa che spinge un ramo null sul lato remoto master, cioè cancella il ramo remoto. Un nome di ramo senza :mezzi spinge il ramo locale con il nome dato al ramo remoto con lo stesso nome. masterin questa situazione è l'abbreviazione di master:master.

Rapidità: il fatto che nessuno abbia pubblicato qui la semplice risposta dimostra l'ostilità disperata dell'utente mostrata dalla CLI di Git.

Ad ogni modo, il modo "ovvio" per farlo, supponendo che tu non abbia provato a forzare la spinta, è quello di tirare per primo. Ciò estrae la modifica che hai modificato (e quindi non è più presente) in modo da averla nuovamente.

Dopo aver risolto eventuali conflitti, puoi spingere di nuovo.

Così:

git pull

Se ricevi errori in pull, forse qualcosa non va nella configurazione del tuo repository locale (ho avuto un riferimento sbagliato nella sezione del ramo .git / config).

E dopo

git push

Forse riceverai un ulteriore impegno con il soggetto che parla di una "unione triviale".

Risposta breve: non inviare commit modificati a un repository pubblico.

Risposta lunga: alcuni comandi Git, come git commit --amende git rebase, in realtà riscrivono il grafico cronologico. Questo va bene fino a quando non hai pubblicato le modifiche, ma una volta fatto, non dovresti davvero andare in giro con la cronologia, perché se qualcuno ha già le tue modifiche, quindi quando provano a tirare di nuovo, potrebbe fallire . Invece di modificare un commit, dovresti semplicemente effettuare un nuovo commit con le modifiche.

Tuttavia, se vuoi davvero inviare un commit modificato, puoi farlo in questo modo:

$ git push origin +master:master

Il +segno principale forzerà la spinta, anche se non si traduce in un commit "avanzamento rapido". (Un commit ad avanzamento rapido si verifica quando le modifiche che si stanno spingendo sono un diretto discendente delle modifiche già presenti nel repository pubblico.)

Ecco un modo molto semplice e pulito per inviare le modifiche dopo aver già effettuato una commit --amend:

git reset --soft HEAD^
git stash
git push -f origin master
git stash pop
git commit -a
git push origin master

Che fa quanto segue:

• Ripristina la diramazione sul commit principale.
• Stash questo ultimo commit.
• Forza la spinta verso il telecomando. Il telecomando ora non ha l'ultimo commit.
• Fai scoppiare la tua scorta.
• Impegnati in modo pulito.
• Premere sul telecomando.

Ricordarsi di cambiare "origine" e "master" se si applica questo a un ramo o telecomando diverso.

Ho risolto scartando il mio commit modificato locale e aggiungendo le nuove modifiche in cima:

# Rewind to commit before conflicting
git reset --soft HEAD~1

# Pull the remote version
git pull

# Add the new commit on top
git add ...
git commit
git push

Ho avuto lo stesso problema.

• Modifica accidentale dell'ultimo commit che è stato già sottoposto a push
• Ha apportato molte modifiche a livello locale, impegnate circa cinque volte
• Ho provato a spingere, ho ricevuto un errore, sono andato nel panico, hanno unito il telecomando, ho ricevuto molti file non personali, ho spinto, fallito, ecc.

Come novizio Git, ho pensato che fosse FUBAR completo .

Soluzione: un po 'come suggerito da @bara + è stato creato un ramo di backup locale

# Rewind to commit just before the pushed-and-amended one.
# Replace <hash> with the needed hash.
# --soft means: leave all the changes there, so nothing is lost.
git reset --soft <hash>

# Create new branch, just for a backup, still having all changes in it.
# The branch was feature/1234, new one - feature/1234-gone-bad
git checkout -b feature/1234-gone-bad

# Commit all the changes (all the mess) not to lose it & not to carry around
git commit -a -m "feature/1234 backup"

# Switch back to the original branch
git checkout feature/1234

# Pull the from remote (named 'origin'), thus 'repairing' our main problem
git pull origin/feature/1234

# Now you have a clean-and-non-diverged branch and a backup of the local changes.
# Check the needed files from the backup branch
git checkout feature/1234-gone-bad -- the/path/to/file.php

Forse non è una soluzione rapida e pulita e ho perso la mia storia (1 commit invece di 5), ma mi ha salvato un giorno di lavoro.

Se non hai inviato il codice al tuo ramo remoto (GitHub / Bitbucket) puoi modificare il messaggio di commit sulla riga di comando come di seguito.

 git commit --amend -m "Your new message"

Se stai lavorando su un ramo specifico, fai come segue:

git commit --amend -m "BRANCH-NAME: new message"

Se hai già inviato il codice con un messaggio sbagliato, devi fare attenzione quando cambi il messaggio. cioè dopo aver modificato il messaggio di commit e provare a spingerlo di nuovo, si verificano problemi. Per renderlo uniforme, attenersi alla seguente procedura.

Si prega di leggere l'intera risposta prima di farlo

git commit --amend -m "BRANCH-NAME : your new message"

git push -f origin BRANCH-NAME                # Not a best practice. Read below why?

Nota importante: quando si utilizza la forza forzata direttamente, si potrebbero riscontrare problemi di codice che altri sviluppatori stanno lavorando sullo stesso ramo. Quindi, per evitare quei conflitti, devi estrarre il codice dal tuo ramo prima di far spingere la forza :

 git commit --amend -m "BRANCH-NAME : your new message"
 git pull origin BRANCH-NAME
 git push -f origin BRANCH-NAME

Questa è la procedura consigliata quando si modifica il messaggio di commit, se è stato già inviato.

Se sai che nessuno ha eseguito il commit non modificato, utilizza l' --force-with-leaseopzione di git push.

In TortoiseGit, puoi fare la stessa cosa sotto le opzioni "Push ..." "Forza: può scartare" e controllare "modifiche conosciute".

Force (può scartare le modifiche note) consente al repository remoto di accettare una spinta più sicura non in avanti veloce. Ciò può causare la perdita di commit del repository remoto; usalo con cura. Ciò può impedire di perdere modifiche sconosciute da altre persone sul telecomando. Verifica se il ramo del server punta allo stesso commit del ramo di tracciamento remoto (modifiche note). Se sì, verrà eseguita una spinta forzata. Altrimenti verrà rifiutato. Poiché git non ha tag di tracciamento remoto, i tag non possono essere sovrascritti usando questa opzione.

Stai ricevendo questo errore perché il telecomando Git ha già questi file di commit. Devi forzare a spingere il ramo affinché questo funzioni:

git push -f origin branch_name

Assicurati anche di estrarre il codice dal telecomando poiché qualcun altro nella tua squadra potrebbe aver spinto nello stesso ramo.

git pull origin branch_name

Questo è uno dei casi in cui dobbiamo forzare il push del commit in remoto.

Ecco un modo molto semplice e pulito per inviare le modifiche dopo aver già effettuato un git add "your files"e git commit --amend:

git push origin master -f

o:

git push origin master --force

Se si utilizza Visual Studio Code, è possibile provare questa estensione per semplificare.

https://marketplace.visualstudio.com/items?itemName=cimdalli.git-commit-amend-push-force

Come puoi capire dal suo nome, esegue i comandi consecutivamente

• git commit --amend
• git push --force

Ho dovuto risolvere questo problema estraendo dal repository remoto e gestendo i conflitti di unione che sono sorti, impegnati e quindi inviati. Ma sento che esiste un modo migliore.

Ho continuato a fare quello che Git mi ha detto di fare. Così:

• Impossibile eseguire il push a causa del commit modificato.
• Faccio un tiro come suggerito.
• L'unione fallisce. quindi lo aggiusto manualmente.
• Crea un nuovo commit (etichettato "unisci") e invialo.
• Sembra funzionare!

Nota: il commit modificato è stato l'ultimo.

Quanto segue ha funzionato per me quando ho cambiato Autore e Committer di un commit.

git push -f origin master

Git è stato abbastanza intelligente da capire che si trattava di delta identici che differivano solo nella sezione delle meta informazioni.

Sia i capi locali che quelli remoti hanno indicato gli impegni in questione.

Ecco, come ho risolto una modifica in un precedente commit:

1. Salva il tuo lavoro finora.
2. Metti da parte le modifiche per ora, se apportate: git stashora la tua copia di lavoro è pulita allo stato del tuo ultimo commit.
3. Apporta le modifiche e le correzioni.
4. Conferma le modifiche in modalità "modifica" :git commit --all --amend

5. Il tuo editor verrà a chiedere un messaggio di registro (per impostazione predefinita, il vecchio messaggio di registro). Salva ed esci dall'editor quando sei soddisfatto.

   Le nuove modifiche vengono aggiunte al vecchio commit. Guarda tu stesso con git logegit diff HEAD^

6. Riapplica le modifiche nascoste, se apportate: git stash apply