Quando lavoro su un ramo di una funzione, tendo a voler ripulire i commit nel ramo usando un rebase interattivo prima che il mio lavoro venga rivisto e integrato nel ramo principale.

Durante lo sviluppo della funzione, desidero trasferire il mio lavoro intermedio al repository remoto come misura di backup. Vale a dire quando il mio disco rigido si arresta in modo anomalo, non voglio perdere l'intero ramo delle funzionalità.

Tuttavia, questo porta al fatto che spesso devo fare un git push --forcerepository remoto dopo un rebase, un'azione che è generalmente disapprovata. O come dice la pagina github collegata:

Poiché la modifica della cronologia dei commit può rendere le cose difficili per tutti gli altri che utilizzano il repository, è considerato una cattiva pratica reimpostare i commit quando si è già passati a un repository.

Esiste una politica (generalmente accettata) che risolve questo conflitto?

Perché questo non è un duplicato di Git "Golden Rule of Rebasing" è così essenziale?

La mia domanda qui chiede una politica per risolvere il conflitto tra il voler fare il backup del tuo lavoro nel repository remoto e il riassegnare il tuo lavoro , mentre l'altra domanda cerca di negare l'esistenza di un conflitto e chiede perché alcune persone pensano che il conflitto esista affatto, e quindi chiede perché "è essenziale" non spingere i ribassi di forza?

La domanda chiave da porsi:

• Mantieni il tuo ramo remoto dopo la fusione nel master?

Se si elimina il ramo della funzionalità remota dopo l'unione in master, si sta già perdendo la cronologia. Supponendo che tu schiaccia / rinnovi il ramo prima di fare la tua unione / PR perdi questa storia. Tutta la tua spinta forzata in questo caso ti consente di usare github come backup.

La situazione in cui vorresti conservare la cronologia e non forzare la spinta è se il tuo ramo remoto persiste dopo essere stato unito e non esiste solo per un periodo di tempo temporaneo.

Suppongo che mi stai chiedendo se avrei mantenuto il ramo non basato? No, AFAIC. Tuttavia, la spinta forzata potrebbe teoricamente comportare la perdita di commit da parte di altri utenti che hanno spinto nello stesso ramo

Sembra che tu abbia più persone che spingono contemporaneamente verso quel ramo. Questo significa che si fanno a cuore la storia sul ramo.

Quello che potresti fare invece per il tuo lavoro intermedio è creare un fork di quel ramo. Puoi spingerlo fino a questo punto e poi riassegnare tutti i tuoi commit in un unico commit prima della fusione, quindi quando li unisci nel tuo ramo delle funzioni, hai solo 1 commit (con la cronologia rinnovata dell'intero ramo).

Sto elencando alcune possibilità qui che mi vengono in mente.

Rifare sempre su un nuovo ramo

Quando si dispone di un ramo disordinato some-feature, rifarlo su un nuovo ramo. Per esempio

$ git checkout -b some-feature-rebase
$ git rebase -i master # etc..

Quindi hanno some-feature-rebaserivisto e integrato.

Problema: un grande svantaggio qui è che, a rigor di termini, è necessario un nuovo ramo per ogni rebase. (Potresti avere più rebase se apporti modifiche dopo una revisione del codice, ad esempio)

Uso git push --force-with-lease

Ho appena saputo git push --force-with-leasedell'alternativa agit push --force , che

rifiuta di aggiornare un ramo a meno che non sia lo stato che ci aspettiamo; cioè nessuno ha aggiornato il ramo a monte.

Problema : questo sembra migliorare direttamente sulla situazione in cui usiamo solo --force, ma ha ancora alcuni avvertimenti, in particolare quando faccio un git fetchinvece di un git pull, che aggiorna i nostri rami a monte locali, inducendo --force-with-leasea pensare che non sono state apportate modifiche non combinate sul telecomando ramo.