Ogni VCS che ho visto include un mezzo (e talvolta ti richiede) per fare un registro di ciò che fa un particolare commit. Se questa cronologia viene mantenuta correttamente, qual è lo scopo di mantenere manualmente la stessa cronologia in un file normale?
Notare che non sto postulando che il log delle modifiche è inutile, ma non ne vedo l'uso da solo. Ci sono altri strumenti che usano il changelog?
Fondamentalmente, hai completamente ragione. Tutte le informazioni dovrebbero essere anche nel VCS e, come hanno detto i commentatori, i changelog sono spesso generati da informazioni VCS.
Tuttavia, i changelog preparati hanno alcuni notevoli vantaggi:
Un log delle modifiche non richiede la connessione al VCS, forse prima installa il client VSC corretto, scorrendo tonnellate di commit e tali seccature. Invece, fornisce rapidamente le informazioni richieste in un documento ben formattato senza troppo carico.
Il pubblico che legge il log delle modifiche può essere uno sviluppatore, ma spesso non lo è. O se sono sviluppatori, non hanno le conoscenze necessarie per interpretare correttamente i dati VCS non elaborati. Quindi, anche se i changelog devono essere generati dai dati VCS, i dati grezzi possono essere ancora ripuliti, consolidati o riformattati per rendere alcuni punti più chiari al pubblico. Ciò diventa più importante, più il pubblico dell'utente differisce (rispetto agli internauti tecnici) dagli sviluppatori / contributori del prodotto.
Se usato correttamente, VCS ha troppi dettagli. Ogni piccolo cambiamento viene registrato, quando un log delle modifiche è in genere per le modifiche visibili all'utente di grandi dimensioni. In breve, il pubblico di destinazione per un log delle modifiche non è lo stesso dei messaggi di commit del VCS.
Se sei disciplinato, un log delle modifiche può essere un sottoinsieme generato automaticamente di ciò che è in VCS, sebbene nella mia esperienza la maggior parte dei team non lo faccia.
Modificando a mano il log delle modifiche, tu (si spera!) finisci con qualcosa di ben fatto, facile da leggere e con il diritto di informazione per il pubblico di destinazione. Sort-of "Clif Notes" di ciò che è cambiato.
What's the purpose of keeping a changelog if everyone uses their VCS properly?
...
If this history is being properly kept, what is the purpose of manually keeping the same history in a regular file?
La tua domanda è buona, ma stai facendo due grandi assunzioni.
Dato una squadra con un disciplinato check-in storia, si sta assumendo che il changelog dovrebbe riflettere o essere equivalente alla storia del check-in. Questo non è il caso. Nel tempo, gli sviluppatori fanno molti tipi diversi di commit a un progetto, alcuni dei quali sono di natura tecnica. Questi includono modifiche alla configurazione e al programma di installazione. Alcuni di questi sarebbero privi di significato per qualcuno che non ha familiarità con l'applicazione o il codice. Mentre alcuni changelog del progetto includono tutto quanto sopra, alcuni sono più focalizzati sugli oggetti più carnosi. [In definitiva, è una sentenza.]
Si sta ipotizzando che una squadra del software potrebbe essere disciplinato abbastanza in modo che il check-in storia potrebbe servire come il log delle modifiche. Ci sono due fattori principali che limitano con questa visione utopistica: 1.) errori di ortografia, errori di grammatica, l'apatia degli sviluppatori, e la fatica degli sviluppatori producono un imperfetto check-in storia. In genere, i team di sviluppo non hanno il tempo, l'inclinazione o il permesso di tornare indietro dopo il fatto e ripulire la cronologia del check-in. 2.) Anche se si considera eccellenti modelli di ramificazione (come GitHub flusso ), la gente si commettono errori e dovranno fare il check-in "quella piccola cosa" che hanno perso dopo il loro "big boss". Ancora una volta, questo è il motivo per cui ci sono delle differenze tra la cronologia del check-in e il registro delle modifiche.
Leggi altre domande sui tag version-control project-management changes