Preservare la cronologia del commit della versione control rispetto a refactoring e documentazione

Non costa quasi nulla utilizzare la cronologia di commit gestita dal sistema di controllo della versione. Tuttavia, durante un grande progetto di refactoring (o riorganizzazione / pulizia), le funzioni, le classi e persino gli spazi dei nomi verranno spostati; a volte diversi file vengono uniti e altri file vengono suddivisi. Queste modifiche spesso portano alla perdita della cronologia di commit originale di alcuni file.

Secondo la mia opinione personale, il mantenimento dell'organizzazione del progetto è più importante del mantenimento della cronologia del codice sorgente. Una buona organizzazione del progetto consente di aggiungere continuamente nuove funzionalità con ragionevole sforzo, mentre il valore della cronologia del codice sorgente sembra essere discutibile.

Inoltre, con l'uso del test unitario, i problemi di regressione vengono rapidamente identificati. Finché l'ultima versione continua a soddisfare tutti i requisiti software, dobbiamo effettivamente preservare la cronologia del codice sorgente?

Comprendo che qualsiasi codice sorgente spedito deve essere conservato a causa della necessità di fornire supporto ai clienti senza richiedere loro di eseguire un aggiornamento della versione principale. Ma a parte questo, c'è qualche valore nel mantenere la cronologia dei commit del codice sorgente?

La cronologia del commit del codice sorgente ha un ruolo nelle comunicazioni tra i membri del team? Che cosa succede se aboliamo la cronologia di commit, ma invece facciamo affidamento su "codice sorgente" + "codice di test unitario" per la comunicazione?

L'esistenza della cronologia del commit rende compiaciuti della documentazione a lungo termine di informazioni importanti sul progetto, come i principali cambiamenti di progettazione / requisiti e i flussi di pensiero che hanno guidato tali cambiamenti?

Per utilizzare la cronologia di commit per più di commenti di tipo "apportato modifiche" o "bug corretti", è necessario collegarli al sistema di tracciamento dei problemi. Ogni modifica, ogni commit, dovrebbe avere qualche problema ad esso associato in modo da sapere cosa è cambiato, da chi e perché.

Finché l'ultima versione continua a soddisfare tutti i requisiti software, dobbiamo effettivamente preservare la cronologia del codice sorgente?

Il software sufficientemente complesso raramente ha tutti i requisiti implementati e tutti i bug corretti per una moltitudine di ragioni, quindi penso che la tua affermazione qui, diciamo, sia ottimista.

Supponi di essere sulla versione 7.8 del tuo programma. Ma stai supportando, sul campo, 12 diverse versioni attive, come 1.6, 2.2, 2.8 e così via. Ognuno di questi non verrà aggiornato all'ultima versione per una serie di motivi, quindi stai supportando tutti con correzioni di bug. Un cliente trova un bug nell'ultima versione 7.8. Lo aggiusti in 7.8. Come fai a sapere quante altre versioni devono essere riparate? Senza la cronologia delle fonti e il rilevamento dei problemi non è così.

il valore della cronologia del codice sorgente sembra essere dubbio.

Ho avuto ingegneri da diversi anni nel codice sorgente alla ricerca di risposte sul perché qualcosa è così. A volte il modo in cui le cose si sono evolute nel tempo è importante per comprendere un bug, ma non è qualcosa che viene in genere pensato quando si documentano le cose (e nemmeno necessariamente documentabile).

Inoltre, potrebbero esserci ottime ragioni legali per mantenere la cronologia del codice sorgente. La maggior parte delle immersioni in cassonetto del codice sorgente che ho dovuto fare (come ingegnere di costruzione / SCM) è stata su richiesta dell'ufficio legale della mia azienda.

Finché l'ultima versione continua a soddisfare tutti i requisiti software, dobbiamo effettivamente preservare la cronologia del codice sorgente?

Ma a parte questo, c'è qualche valore nel mantenere la cronologia dei commit del codice sorgente?

Sì ad entrambi. Può essere utile sapere quando qualcosa è stato cambiato, da chi e perché. Se perdi la tua storia, la tua capacità di farlo è influenzata.

La cronologia del commit del codice sorgente ha un ruolo nelle comunicazioni tra i membri del team? Che cosa succede se aboliamo la cronologia di commit, ma invece facciamo affidamento su "codice sorgente" + "codice di test unitario" per la comunicazione?

Sì lo fa. L'approccio "codice sorgente" + "codice unit test" non ti dice chi / quando / perché.

L'esistenza della cronologia del commit rende compiaciuti della documentazione a lungo termine di informazioni importanti sul progetto, come i principali cambiamenti di progettazione / requisiti e i flussi di pensiero che hanno guidato tali cambiamenti?

Suppongo che potresti dire che lo fa. Ma pochi sviluppatori documentano mai completamente i cambiamenti nei requisiti / nella progettazione. E certamente quasi nessuno registra il flusso di pensiero che ha guidato lo sviluppo iniziale o le successive modifiche. Avere la cronologia di commit (e in particolare i messaggi di log di commit) e i collegamenti incrociati al sistema di tracciamento dei problemi / bug almeno ti fornisce qualcosa da cui partire. E questo è meglio di niente, o una serie di istantanee di rilascio.