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

Di recente ho avuto una discussione con persone assolutamente contrarie a una strategia di ribasatura dei rami delle funzioni su GIT. Sembra essere uno schema accettato per usare rebase solo per filiali locali e private, ma non usarlo mai quando ci sono diverse persone che lavorano su una stessa funzione e ramo, come da questa cosiddetta "Regola d'oro del rifacimento" (come spiegato qui: https : //www.atlassian.com/git/tutorials/merging-vs-rebasing/conceptual-overview )

Sono solo sorpreso che ci sia consenso su questo. Ho lavorato 3 anni con una strategia di rebasing completa, con circa 20 sviluppatori che lavorano insieme e indovina un po ', ha funzionato.

Il processo è sostanzialmente:

• Crei il tuo ramo delle caratteristiche, chiamiamolo "myfeature" e spingilo su origin / myfeature
• Altre persone possono verificarlo e lavorarci su
• A volte puoi rifarlo dal master: da "myfeature", git rebase origin / master ; e poi sì, devi forzarlo.
• Cosa succede quando altre persone vogliono spingere i propri impegni? Lo ribattevano semplicemente: git rebase origin / myfeature . Quindi ora sono in rapido avanzamento e possono spingerlo senza forzare.

L'unico principio da rispettare è che il ramo delle caratteristiche sia di proprietà di qualcuno . Il proprietario è l'unico che può spingere-forza.

Quindi, lo ammetto: non appena c'è una forza di spinta, c'è il rischio di fare errori. È vero. Ma ci sono anche molti modi per recuperare dagli errori e, in 3 anni di sviluppo, non ho visto molti errori di spinta forzata e quando è successo abbiamo sempre trovato il modo di recuperare correttamente.

Quindi, perché questa "Regola d'oro del rebase" è così ampiamente accettata? C'è qualcos'altro che mi è mancato? Capisco che richiede un minimo di organizzazione (ogni strategia richiede una certa organizzazione), ma funziona.

Il problema con la forzatura forzata non riguarda il ramo delle funzionalità e il master, ma di spingere il master verso il master di qualcun altro: tale sincronizzazione sovrascriverà il master con le modifiche, ignorando tutto ciò che è in punta.

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

Quindi forse la domanda è: perché ti stai ribellando? Per una cronologia "pulita" quando si riportano le funzionalità al master? Se è così, stai buttando via tutta la buona storia della ramificazione per motivi puramente di stile. Anche la fusione rapida IMHO non è una buona pratica, dovresti tenere tutta la cronologia in modo da poter vedere ciò che hai realmente fatto, non una versione disinfettata in seguito.

Rebase non è essenziale, come si dice che è per lo più cosmetici. 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. È improbabile che perda dati se sai abbastanza per non farti prendere dal panico e cercare le procedure di recupero, ma "hey nessuno spinge per un po 'che devo sistemare ..." non è eccezionale. Né qualcuno sta perdendo tempo nel recupero della ricerca e nei test quando avrebbe potuto aggiungere funzionalità o eliminare bug (o a casa con la famiglia).

Con questo compromesso i risultati di "pochissime persone fanno un ribasso e una spinta forzata" non è molto sorprendente.

Alcuni flussi di lavoro possono ridurre il rischio, ad esempio ridurlo a "zero, purché si ricordi quali rami è consentito forzare e quali non è possibile". In realtà potrebbero essere abbastanza sicuri da giustificare il rischio, ma la gente fa spesso delle scelte basate su un folklore più ampio. Poi di nuovo in realtà i benefici sono piuttosto piccoli, quindi quanto deve essere veramente piccolo il rischio?

Per aggiungere una voce diversa:

Sì, se lavori come descritto, non ci sono problemi con l'uso rebasee la spinta forzata. Il punto critico è: hai un accordo nella tua squadra.

Gli avvertimenti rebasee gli amici riguardano il caso in cui non esiste un accordo speciale. Normalmente, git ti protegge automaticamente, ad esempio, non consentendo una spinta non veloce. L'uso rebasee la spinta forzata prevalgono su quella sicurezza. Va bene se hai qualcos'altro in atto.

Nel mio team, a volte rifacciamo anche i rami delle funzionalità se la storia è diventata disordinata. O eliminiamo il vecchio ramo e ne creiamo uno nuovo con un nuovo nome, oppure coordiniamo semplicemente 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 fa qualcosa di simile: hanno un ramo di integrazione che viene regolarmente ricreato, chiamato "pu" ("aggiornamenti proposti"). È documentato che questo ramo viene ricreato regolarmente e che non è necessario basare nuovi lavori su di esso.

Quindi, lo ammetto: non appena c'è una forza di spinta, c'è il rischio di fare errori. È vero. Ma ci sono anche molti modi per recuperare dagli errori e, in 3 anni di sviluppo, non ho visto molti errori di spinta forzata e quando è successo abbiamo sempre trovato il modo di recuperare correttamente.

Il motivo per cui gli utenti di Git tendono a evitare la cronologia condivisa mutevole è perché non c'è evitamento o riparazione automatici di questi problemi. Devi sapere cosa stai facendo e devi sistemare tutto manualmente se sbagli. Consentire esattamente a una persona di eseguire la spinta forzata non è intuitivo e contrariamente al design distribuito di Git. Cosa succede se quella persona va in vacanza? Qualcun altro possiede temporaneamente la filiale? Come fai a sapere che non cammineranno dappertutto qualunque cosa il proprietario originale stesse facendo? E nel mondo open source, cosa succede se il proprietario della filiale si allontana gradualmente dalla comunità, senza andarsene ufficialmente? Potresti perdere molto tempo in attesa di passare la proprietà della filiale a qualcun altro.

Ma il vero problema è questo: se sbagli e non te ne accorgi immediatamente, i vecchi commit alla fine svaniranno dopo che è trascorso abbastanza tempo. A quel punto, il problema potrebbe essere irrecuperabile (o almeno, potenzialmente molto difficile da recuperare, a seconda dell'aspetto della storia di backup: esegui il backup di vecchie copie del tuo repository Git, cioè non solo dei cloni?).

In contrasto con il lavoro di evoluzione di Changesur di Mercurial (che, devo notare, non è ancora finito o stabile). Tutti possono apportare qualsiasi modifica alla cronologia che preferiscono, a condizione che le modifiche non siano contrassegnate come pubbliche. Questi emendamenti e ribassi possono essere spinti e tirati con totale impunità, senza bisogno di un proprietario di filiale. Nessun dato viene mai cancellato; l'intero repository locale è solo append. I cambiamenti che non sono più necessari sono contrassegnati come obsoleti, ma mantenuti indefinitamente. Alla fine, quando rovini la tua cronologia (che viene trattata come una parte normale del tuo flusso di lavoro quotidiano), c'è un comando ingegnoso per ripulirla automaticamente. Questo è il tipo di UX che le persone si aspettano prima di andare in giro a modificare la cronologia condivisa.