Quando deve essere cancellata la cronologia VCS di un progetto? [duplicare]

Lo spazio di archiviazione è economico, mantienilo.

A volte devi controllare se qualche bug era presente nella versione pre-refactor o fare riferimento a qualche vecchio pezzo di codice.

Se sei veramente preoccupato della percentuale di checkout di git , allora puoi andare ed eliminare la cronologia, ma ti suggerirei di iniziare un nuovo repository in questo caso e lasciare il refactor commit in quello vecchio, in modo che quando ne hai davvero bisogno, quindi puoi collegarli facilmente.

Una nota specifica di git : se non vuoi la cronologia per il checkout corrente (perché vuoi semplicemente compilare il progetto o creare patch per il problema corrente) puoi usare --depth=1 , poi git vinto ' t clonare qualsiasi storia. Seconda cosa: puoi creare un ramo --orphan che non condividerà alcuna storia con altri rami in repository, puoi quindi clonare solo questo ramo e la sua cronologia omettendo tutti gli altri oggetti nel repository remoto di git.

La mia "regola empirica" sulla durata della cronologia delle versioni in qualsiasi tipo di VCS: mantenere attiva la cronologia delle versioni finché è necessario mantenere quel software specifico.

Per esempio, sto lavorando qui con un prodotto che è più vecchio di 10 anni e mantenuto ed evoluto costantemente. Il nostro repository di subversion per quel prodotto ha circa 500 MB, ma in realtà si tratta di "peanuts". Avere il registro completo disponibile per tutta la durata del prodotto è stato spesso molto utile per capire le cose accadute qualche tempo fa in passato.

Suggerirei di conservare l'intera cronologia dei commit git in quanto aiutano a tenere registri e mantenere la cronologia delle modifiche maggiori e minori. Ma vorrei suggerire di bifrare il codice in un altro repository una volta rilasciato l'aggiornamento principale, aggiungendo solo aggiornamenti minori o correzioni di bug alle versioni precedenti e concentrandomi maggiormente sulla nuova versione principale.

Ciò aiuta a mantenere una buona struttura di sviluppo e aiuta anche a ridimensionare la velocità di crescita del repository. Questa è la principale struttura di gestione delle revisioni, seguita da molti progetti open source.

Sono un tipo Mercurial, uso anche un piccolo idiota.

Posso dirti che in modifica / rimozione di Mercurial è scoraggiato, ma non impossibile. Tutti vivono tranquilli con questo modo di fare le cose e penso che sia un modo migliore per andare. Perché modificare la cronologia a meno che non si rovini?

Git ti consente di modificare la cronologia, ma ciò non significa che dovresti. Questo crea problemi alle persone, da ciò non deriva nulla di buono tranne una cronologia più ordinata, ma non dovresti preoccuparti se tieni i tuoi impegni rivedibili. La mia percezione è che con Git, le persone possono diventare OCD con il potere di modifica della cronologia.

Se devi assolutamente, modificare la storia mai e poi mai e poi mai dopo , rendi le persone pazze .