Come gestire la completa riscrittura del progetto in git?

Question

Come gestire la completa riscrittura del progetto in git?

#1 da (1 voti)

2

Sto sviluppando una libreria software che ho iniziato durante il mio dottorato e utilizzata nella mia tesi. Da allora ho iniziato una posizione di ricerca e, come esperimento, ho voluto provare a riscrivere le parti per vedere se potevo semplificarlo. Ciò si è rivelato molto più efficace di quanto mi aspettassi. Ho riscritto anni di lavoro in poche settimane e il risultato finale è molto più pulito di quello che avevo prima.

Ora voglio rendere pubblica la mia riscrittura, ma non sono sicuro di cosa fare sulla cronologia delle revisioni. Mi riferisco a specifici commit nella vecchia versione della mia tesi, quindi mi piacerebbe averli conservati per i posteri (e quindi posso ridere del mio codice spazzatura in seguito.) Posso pensare a 3 opzioni:

Elimina tutto il vecchio codice in un unico commit. Estrai tutti i commit dalla riscrittura come patch e applicali uno per uno nel vecchio repository.
Crea un tag tag per il vecchio codice, ad esempio my-lib-0.0.1 , spiegando che si trattava di una versione nascente del codice di quando ero giovane e sciocco. Aggiungi la riscrittura come remoto per il vecchio codice, quindi git reset --hard rewrite/master . Questo sostituirà la cronologia delle revisioni del vecchio codice con quella della riscrittura.
Spiega in README per il vecchio repository che è deprecato e mantieni la riscrittura in un repository completamente nuovo.

Non mi piace l'opzione 3, perché preferirei avere tutto nello stesso repository. Inoltre, c'è ancora una discreta quantità di codice condiviso tra la vecchia e la nuova versione. L'opzione 2 ha il merito di mantenere la cronologia delle revisioni abbastanza pulita (gli utenti non dovranno clonare più di 400 commit di spazzatura da quando non sapevo cosa stavo facendo) ma mantenendo la cronologia lì nell'improbabile evento che qualcuno fa voglio vederlo. D'altra parte, non mi piace l'idea di "riscrivere la storia", e per evitare la clonazione di immondizia, posso sempre dire alla gente di fare cloni superficiali.

Quale di queste opzioni è la meno cattiva? Ce ne sono altri che non ho considerato?

git version-control

posta korrok 11.05.2017 - 20:12

fonte

1 risposta

Leggi altre domande sui tag git version-control

Devo posizionare le configurazioni della mia app in un file JSON o in un modulo JS? Modello multilingue in DDD

score 1 · Answer 1

Questa è una situazione molto tipica nello sviluppo del software.

Dal mio punto di vista, dovresti prima taggare la versione finale del tuo vecchio codice (non c'è bisogno di diramarti dato che puoi sempre diramarti dal tag se necessario). Inoltre, la riscrittura si svolge in modo incrementale e ciò significa che si impegna a cambiare gradualmente. Quando raggiungi la tua nuova versione ti tagghi di nuovo e così via. In ogni versione (tagging) includi un documento sulle note di rilascio.

Ciò che potresti incontrare, però, sono le modifiche al codice del freno. In questo caso, li comunichi modificando il numero di versione e le note di rilascio.