Il git "Golden Rule of Rebasing" è così essenziale?

Il problema con la forza di spinta non riguarda il tuo ramo e il tuo master, ma quello di spingere il tuo maestro verso il master di qualcun altro - che la sincronizzazione sovrascriverà il master con i tuoi cambiamenti, ignorando tutto ciò che è sulla loro punta.

Considerando questo pericolo, c'è un motivo per cui non dovresti usarlo affatto a meno che le cose non si siano rovinate e tu, assolutamente, devi assolutamente usarlo per effettuare riparazioni. Un sistema SCM non dovrebbe mai essere costretto in questo modo, se lo fa perché qualcosa è andato terribilmente storto (e il mio primo approccio in questi casi sarebbe quello di ripristinare i backup e ripetere le operazioni per mantenere intatta la cronologia).

Quindi forse la domanda è: perché stai ribasando? Per la cronologia "pulita" quando si riportano le funzionalità sul master? Se è così, stai buttando via tutta la buona storia della ramificazione per ragioni puramente stilistiche. Anche la fusione rapida di IMHO non è una buona pratica, dovresti tenere tutta la cronologia in modo da poter vedere cosa hai fatto realmente, non dopo una versione sterilizzata.

Rebase non è essenziale, come dici tu è principalmente cosmetico. A volte è molto più semplice di una fusione. Quindi può avere un valore "effettivo", ma solo "a volte"

L'uso improprio di rebase può essere costoso. Difficile perdere dati se ne sai abbastanza da non andare nel panico e cercare le procedure di recupero, ma "hey nessuno spinge per un po 'che devo aggiustare ..." non è grandioso. Né si sta facendo perdere tempo a qualcuno per il recupero e il test della ricerca quando avrebbero potuto aggiungere funzionalità o schiacciare i bug (o essere a casa con la famiglia).

Con questo trade il risultato di "pochissime persone fanno un rebase e una spinta forzata" non è molto sorprendente.

Alcuni flussi di lavoro possono ridurre il rischio, ad esempio ridurlo a "zero fintanto che ricordi quali rami sei autorizzato a forzare e quali non puoi". In realtà potrebbero essere abbastanza sicuri da giustificare il rischio, ma spesso le persone fanno delle scelte basate su un folclore più ampio. Poi di nuovo in realtà i benefici sono piuttosto piccoli, quindi quanto piccolo deve davvero essere il rischio?

Per aggiungere una voce diversa:

Sì, se lavori come descrivi, non ci sono problemi con l'utilizzo di rebase e di force-push. Il punto critico è: Hai un accordo nella tua squadra.

Gli avvisi su rebase e gli amici sono per il caso in cui non vi è alcun accordo speciale. Normalmente, git ti protegge automaticamente, ad esempio, non consentendo una spinta non veloce. Usando rebase e forzando la forzatura sovrascrive quella sicurezza. Va bene se hai qualcos'altro sul posto.

Nel mio team, a volte rebase i rami delle funzionalità se la cronologia è diventata complicata. Eliminiamo il vecchio ramo e ne creiamo uno nuovo con un nuovo nome, o ci limitiamo a coordinare in modo informale (il che è possibile perché siamo una piccola squadra e nessun altro lavora nel nostro repository).

Si noti che anche il progetto git stesso fa qualcosa di simile: hanno un ramo di integrazione che viene ricreato regolarmente, chiamato "pu" ("aggiornamenti proposti"). È documentato che questo ramo è ricreato regolarmente e che non dovresti basare nuovo lavoro su di esso.

So, I admit: as soon as there's a push-force, there's a risk to do errors. That's true. But there's also many ways to recover from errors, and really, in 3 years of development, I didn't saw a lot of force-pushing mistakes, and when it came to happen we always found a way to recover properly.

La ragione per cui gli utenti di Git tendono ad evitare la cronologia mutabile condivisa è perché non vi è alcuna elusione o riparazione automatica di questi problemi. Devi sapere cosa stai facendo e devi aggiustare tutto manualmente se ti rovini. Permettere a esattamente una persona di fare forza-spinta non è intuitivo e contrariamente al design distribuito di Git. Cosa succede se quella persona va in vacanza? Qualcun altro possiede temporaneamente il ramo? Come fai a sapere che non cammineranno su tutto ciò che il proprietario originale stava facendo? E nel mondo open source, cosa succede se il proprietario della filiale si allontana gradualmente dalla comunità, senza partire ufficialmente? Potresti perdere molto tempo in attesa di trasferire la proprietà della filiale a qualcun altro.

Ma il vero problema è questo: se ti incasini e non lo realizzi immediatamente, i vecchi commit saranno eventualmente svanire dopo che è trascorso un tempo sufficiente. A quel punto, il problema potrebbe essere irrecuperabile (o almeno, potenzialmente molto difficile da ripristinare, a seconda di come appare la tua storia di backup: esegui il backup delle vecchie copie del tuo repository Git, cioè non solo dei cloni?).

Confrontalo con il Evoluzione dei changeset di Mercurial (che, dovrei notare, non è ancora finito o stabile) . Tutti possono apportare modifiche alla cronologia che preferiscono, a condizione che i changeset non siano contrassegnati come pubblici. Queste ammende e ribelli possono essere spinti e tirati con totale impunità, senza bisogno di un proprietario di una filiale. Nessun dato viene mai cancellato; l'intero repository locale è append-only. I changeset che non sono più necessari sono contrassegnati come obsoleti, ma mantenuti indefinitamente. Infine, quando si incasina la cronologia (che viene trattata come una normale parte del flusso di lavoro quotidiano), c'è un comando elegante per ripulirlo automaticamente. Questo è il tipo di persone UX che si aspettano prima di andare in giro a modificare la cronologia condivisa.