Git push rifiutato dopo il rebase del ramo della funzione

OK, ho pensato che fosse uno scenario git semplice, cosa mi sto perdendo?

Ho un masterramo e un featureramo. Faccio un po 'di lavoro master, alcuni su feature, e poi altri ancora su master. Finisco con qualcosa del genere (l'ordine lessicografico implica l'ordine dei commit):

A--B--C------F--G  (master)
       \    
        D--E  (feature)

Non ho problemi a git push origin mastermantenere masteraggiornato il telecomando , né con git push origin feature(quando acceso feature) per mantenere un backup remoto per il mio featurelavoro. Fino ad ora, stiamo bene.

Ma ora voglio ribadire featurein cima agli F--Gimpegni sul master, quindi io git checkout featuree git rebase master. Ancora buono. Ora abbiamo:

A--B--C------F--G  (master)
                 \
                  D'--E'  (feature)

Problema: nel momento in cui voglio eseguire il backup del nuovo rebased featureramificato git push origin feature, la spinta viene rifiutata poiché l'albero è cambiato a causa del rebasing. Questo può essere risolto solo con git push --force origin feature.

Odio usare --forcesenza essere sicuro di averne bisogno. Quindi ne ho bisogno? Il rebasing implica necessariamente che il prossimo pushdovrebbe essere --forcecompleto?

Questo ramo delle funzionalità non è condiviso con nessun altro sviluppatore, quindi non ho alcun problema di fatto con la spinta forzata, non perderò alcun dato, la domanda è più concettuale.

Il problema è che si git pushpresume che il ramo remoto possa essere inoltrato rapidamente al proprio ramo locale, cioè che tutta la differenza tra i rami locali e remoti sia nel locale con alcuni nuovi commit alla fine in questo modo:

Z--X--R         <- origin/some-branch (can be fast-forwarded to Y commit)
       \        
        T--Y    <- some-branch

Quando esegui i git rebasecommit, D ed E vengono applicati alla nuova base e vengono creati nuovi commit. Ciò significa che dopo rebase hai qualcosa del genere:

A--B--C------F--G--D'--E'   <- feature-branch
       \  
        D--E                <- origin/feature-branch

In tale situazione, la filiale remota non può essere inoltrata rapidamente al locale. Tuttavia, in teoria il ramo locale può essere unito in remoto (ovviamente non è necessario in quel caso), ma poiché git pushesegue solo un avanzamento rapido si fonde genera ed errore.

E quale --forceopzione fa è semplicemente ignorare lo stato del ramo remoto e impostarlo sul commit che stai spingendo in esso. Quindi git push --force origin feature-branchsemplicemente sostituisce origin/feature-branchcon locale feature-branch.

A mio avviso, la reimpostazione dei rami delle funzioni mastere il loro reinserimento forzato nel repository remoto è OK purché tu sia l'unico che lavora su quel ramo.

Invece di usare -f o --force gli sviluppatori dovrebbero usare

--force-with-lease

Perché? Perché controlla il ramo remoto per le modifiche che è assolutamente una buona idea. Immaginiamo che James e Lisa stiano lavorando allo stesso ramo di funzioni e Lisa abbia fatto un commit. James ora rinnova il suo ramo locale e viene respinto quando tenta di spingere. Ovviamente James pensa che ciò sia dovuto al ribasso e usa - force e riscriverebbe tutti i cambiamenti di Lisa. Se James avesse usato - force-with-lease, avrebbe ricevuto un avvertimento in merito al fatto che sono stati commessi da qualcun altro. Non vedo perché qualcuno dovrebbe usare --force invece di --force-with-lease quando spinge dopo un rebase.

Vorrei invece usare "checkout -b" ed è più facile da capire.

git checkout myFeature
git rebase master
git push origin --delete myFeature
git push origin myFeature

quando si elimina si impedisce di inserire un ramo in uscita che contiene ID SHA diverso. In questo caso sto eliminando solo il ramo remoto.

Una soluzione a questo è di fare ciò di msysgit merge rebasing script fa - dopo la rebase, unione nella vecchia testa di featurecon -s ours. Si finisce con il grafico di commit:

A--B--C------F--G (master)
       \         \
        \         D'--E' (feature)
         \           /
          \       --
           \    /
            D--E (old-feature)

... e la tua spinta featuresarà un avanzamento veloce.

In altre parole, puoi fare:

git checkout feature
git branch old-feature
git rebase master
git merge -s ours old-feature
git push origin feature

(Non testato, ma penso che sia giusto ...)

Può darsi che non ci sia o meno un solo sviluppatore su questo ramo, che ora (dopo il rebase) non è in linea con l'origine / funzione.

Come tale, suggerirei di utilizzare la seguente sequenza:

git rebase master
git checkout -b feature_branch_2
git push origin feature_branch_2

Sì, nuova filiale, questo dovrebbe risolverlo senza --force, che penso sia generalmente un grosso svantaggio.

Il mio modo di evitare la spinta della forza è quello di creare un nuovo ramo e continuare a lavorare su quel nuovo ramo e, dopo un po 'di stabilità, rimuovere il vecchio ramo che è stato riformato:

• Rebasing locale del ramo estratto
• Diramazione dal ramo rinnovato a un nuovo ramo
• Spingendo quel ramo come nuovo ramo sul telecomando. ed eliminando il vecchio ramo sul telecomando

Altri hanno risposto alla tua domanda. Se rinnovi un ramo dovrai forzare a spingere quel ramo.

Rebase e un repository condiviso generalmente non vanno d'accordo. Questa è la riscrittura della storia. Se altri stanno usando quel ramo o si sono ramificati da quel ramo, rebase sarà piuttosto spiacevole.

In generale, rebase funziona bene per la gestione delle filiali locali. La gestione remota delle filiali funziona al meglio con fusioni esplicite (--no-ff).

Evitiamo inoltre di unire master in un ramo di funzionalità. Invece, passiamo al master ma con un nuovo nome di ramo (ad esempio aggiungendo un suffisso di versione). Ciò evita il problema della re-assegnazione nel repository condiviso.

Cosa c'è di sbagliato con a git merge mastersul featureramo? Ciò preserverà il lavoro svolto, mantenendolo separato dal ramo principale.

A--B--C------F--G
       \         \
        D--E------H

Modifica: Ah scusa non ho letto la tua dichiarazione di problema. Avrai bisogno di forza mentre esegui a rebase. Tutti i comandi che modificano la cronologia avranno bisogno --forcedell'argomento. Questo è un modo sicuro per evitare di perdere il lavoro (il vecchio De Esarebbe perso).

Quindi hai eseguito un git rebaseaspetto che faceva sembrare l'albero (anche se parzialmente nascosto come De Enon si trova più in un ramo denominato):

A--B--C------F--G
       \         \
        D--E      D'--E'

Quindi, quando provi a spingere il tuo nuovo featureramo (con D'e E'in esso), perdi De E.

Per me seguire i semplici passaggi funziona:

1. git checkout myFeature
2. git rebase master
3. git push --force-with-lease
4. git branch -f master HEAD
5. git checkout master
6. git pull

Dopo aver fatto tutto quanto sopra, possiamo eliminare anche il ramo myFeature seguendo il comando:

git push origin --delete myFeature

Per me funziona quanto segue:

git push -f origin branch_name

e non rimuove nessuno dei miei codici.

Ma, se vuoi evitare questo, puoi fare quanto segue:

git checkout master
git pull --rebase
git checkout -b new_branch_name

quindi puoi selezionare tutti i tuoi commit nella nuova filiale. git cherry-pick COMMIT ID e quindi spingere il tuo nuovo ramo.

Dato che l'OP capisce il problema, cerca solo una soluzione migliore ...

Che ne dici di questo come pratica?

• Avere un vero ramo di sviluppo delle funzionalità (dove non si ribatte e non si fa mai forza, quindi i tuoi colleghi sviluppatori di funzioni non ti odiano). Qui, prendi regolarmente quei cambiamenti da main con una fusione. Storia più incasinata , sì, ma la vita è facile e nessuno si interrompe nel suo lavoro.

• Avere un secondo ramo per lo sviluppo di funzionalità, in cui un membro del team di funzioni spinge regolarmente tutti gli impegni a cui è stato impegnato, in effetti ribassati, in effetti forzati. Quindi, quasi in modo pulito, basato su un commit principale abbastanza recente. Al termine della funzione, spingere quel ramo sopra il master.

Potrebbe esserci già un nome di modello per questo metodo.