Gli aggiornamenti sono stati rifiutati perché la punta del tuo ramo attuale è dietro

Sono nuovo di Git, quindi sentiti libero di trattarmi come un principiante.

Il nostro flusso di lavoro è tale. Abbiamo un ramo chiamato al devquale posso raggiungere origin/dev. Quando facciamo le modifiche, creiamo un ramo fuori da dev:

git checkout -b FixForBug origin / dev

Ora ho un ramo chiamato FixForBugche sta monitorando (penso che sia la parola giusta) origin/dev. Quindi, se faccio un git pull, porterà nuovi cambiamenti da origin/devcui è fantastico. Ora, quando ho finito con la mia correzione, spingo in un ramo remoto chiamato la stessa cosa.

Per prima cosa abbasso tutte le modifiche origin/deve faccio un rebase:

git pull --rebase

Quindi invio le modifiche a un ramo remoto con lo stesso nome:

git push origin FixForBug

Ora, c'è un ramo sul server remoto e posso creare una richiesta pull per l'approvazione e la fusione di quella modifica nel ramo dev. Non spingo mai niente a origin/devme stesso. Immagino che questo sia un flusso di lavoro piuttosto comune.

La prima volta che faccio un git push, funziona benissimo e crea il ramo remoto. Tuttavia, se premo una seconda volta (diciamo durante la revisione del codice, qualcuno segnala un problema), ottengo il seguente errore:

errore: impossibile inviare alcuni riferimenti a ' https://github.limeade.info/Limeade/product.git ' suggerimento: gli aggiornamenti sono stati rifiutati perché la punta del ramo corrente è dietro suggerimento: la sua controparte remota. Integra le modifiche remote (es. Suggerimento: 'git pull ...') prima di premere di nuovo. suggerimento: vedere la "Nota sull'avanzamento rapido" in "git push --help" per i dettagli.

Tuttavia, se lo faccio git statusdice che sono in anticipo di origin/dev1 commit (il che ha senso) e se seguo il suggerimento e corro git pull, dice che tutto è aggiornato. Penso che sia perché sto spingendo verso un ramo diverso dal mio ramo a monte. Posso risolvere questo problema eseguendo:

git push -f origin FixForBug

In tal caso, invierà le modifiche al ramo remoto, dicendo (aggiornamento forzato) e tutto sembra andare bene sul ramo remoto.

Le mie domande:

Perché è -frichiesto in questo scenario? Di solito quando stai forzando qualcosa, è perché stavi facendo qualcosa di sbagliato o almeno contro la pratica standard. Sto bene facendo questo, o rovinerà qualcosa nel ramo remoto o creerà una seccatura per chi alla fine dovrà unire le mie cose in sviluppo?

Il -f è in realtà necessario a causa della rebase. Ogni volta che fai un rebase dovrai fare una spinta forzata perché il ramo remoto non può essere inoltrato velocemente al tuo commit. Devi sempre assicurarti di fare un tiro prima di spingere, ma se non ti piace forzare push a master o dev per quella materia, puoi creare un nuovo ramo da spingere e quindi unire o creare un PR .

Per assicurarsi che FixForBug della filiale locale non sia in anticipo rispetto a FixForBug della filiale remota, estrarre e unire le modifiche prima di eseguire il push.

git pull origin FixForBug
git push origin FixForBug

Se vuoi evitare di dover usare -f, puoi usare solo

git pull

invece di

git pull --rebase

Il non-rebase recupererà le modifiche origin/deve le unirà nel tuo FixForBugramo. Quindi, sarai in grado di eseguire

git push origin FixForBug

senza usare -f.

the tip of your current branch is behind its remote counterpartsignifica che ci sono state modifiche sul ramo remoto che non hai localmente. e git ti dice di importare nuove modifiche REMOTEe unirle con il tuo codice e poi pusha distanza.

È possibile utilizzare questo comando per forzare le modifiche al server con repo locale ().

git push -f origin master

con il -ftag sostituirai Remote Brach codecon il tuo codice.

Il comando che ho usato con Azure DevOps quando ho riscontrato il messaggio "gli aggiornamenti sono stati rifiutati perché la punta del ramo corrente è dietro" era / è questo comando:

git pull origin master

(o può iniziare con una nuova cartella ed eseguire un clone) ..

Questa risposta non risponde alla domanda posta, in particolare, Keif ha risposto sopra, ma risponde al testo del titolo / titolo della domanda e questa sarà una domanda comune per gli utenti di Azure DevOps.

Ho notato un commento: "Avresti sempre voluto assicurarti di fare un tiro prima di spingere" in risposta da Keif sopra!

Ho anche usato lo strumento Git Gui oltre allo strumento da riga di comando Git.

(Non ero sicuro di come fare l'equivalente del comando da riga di comando "git pull origin master" all'interno di Git Gui, quindi sono tornato alla riga di comando per farlo).

Un diagramma che mostra vari comandi git per varie azioni che potresti voler intraprendere è questo:

Questo mi è appena successo.

• Ieri ho fatto una richiesta pull al nostro maestro.
• Il mio collega lo stava rivedendo oggi e ha visto che non era sincronizzato con il nostro ramo principale, quindi con l'intenzione di aiutarmi, ha unito il maestro al mio ramo.
• Non sapevo che lo avesse fatto.
• Quindi ho unito master localmente, ho provato a spingerlo, ma non ci sono riuscito. Perché? Perché il mio collega si fonde con il master ha creato un commit extra che non avevo localmente !

Soluzione: Tirare giù la mia propria filiale in modo da ottenere quel qualcosa in più commit. Quindi rispediscilo al mio ramo remoto.

letteralmente quello che ho fatto sul mio ramo è stato:

git pull
git push

Ecco come ho risolto il mio problema

Supponiamo che il ramo a monte sia quello da cui hai biforcato e l'origine è il tuo repository e vuoi inviare un MR / PR al ramo a monte.

Diciamo già circa 4 commit e stai ottenendo Updates were rejected because the tip of your current branch is behind.

Ecco cosa ho fatto

Per prima cosa, schiaccia tutti e 4 i tuoi commit

git rebase -i HEAD~4

Otterrai un elenco di commit con pickscritto su di essi. (aperto in un editor)

esempio

pick fda59df commit 1
pick x536897 commit 2
pick c01a668 commit 3
pick c011a77 commit 4

per

pick fda59df commit 1
squash x536897 commit 2
squash c01a668 commit 3
squash c011a77 commit 4

Successivamente, è possibile salvare il commit combinato

Il prossimo

Dovrai riporre il tuo commit

Ecco come

git reset --soft HEAD~1
git stash

ora rebase con il tuo ramo upstream

git fetch upstream beta && git rebase upstream/beta

Ora fai scoppiare il commit stash

git stash pop

impegnare questi cambiamenti e spingerli

git add -A
git commit -m "[foo] - foobar commit"
git push origin fix/#123 -f

Deve essere perché l'impegno è in anticipo rispetto all'attuale spinta.

1) git pull origin "nome del ramo che vuoi spingere"

2) git rebase

se git rebase ha successo, allora va bene. Altrimenti, hai risolto tutti i conflitti di unione a livello locale e continua fino a quando il rebase con il telecomando ha esito positivo.

3) git rebase --continua

Ho avuto questo problema quando provavo a inviare un rebase dopo il Visual Studio Code, il mio problema è stato risolto semplicemente copiando il comando dalla finestra di output di git ed eseguendolo dalla finestra del terminale in Visual Studio Code.

Nel mio caso il comando era qualcosa del tipo:

git push origin NameOfMyBranch:NameOfMyBranch

Devi aver aggiunto nuovi file nei tuoi commit che non sono stati inviati. Controllare il file e spingerlo nuovamente e il tentativo pull / push funzionerà. Questo ha funzionato per me ..