Come integrare le versioni con changelog?

Question

Come integrare le versioni con changelog?

#1 da (7 voti)

5

Prima di iniziare la domanda, voglio dirvi che sono nuovo in questo tipo di flusso di lavoro. Le aziende precedenti che ho lavorato non hanno usato Version Control e / o changelogs. Inoltre, ho lavorato come libero professionista per qualche tempo, quindi non ho mai sentito la necessità di farlo. Ma ora sto provando ad avere una migliore organizzazione dei miei progetti e sto provando ad usare i cangianti e il controllo della versione.

Leggevo anche altre domande qui e ho capito lo scopo di un controllo di versione, un log delle modifiche, una versione semantica (che è il tipo di versione che userò), attualmente sto usando SourceTree (localmente), ho anche capito il concetto per ogni commit, ramo, ecc ...

Ciò che non capisco molto bene è come integrare il controllo della versione (commit) con un log delle modifiche dettagliato. Cosa dovrebbe andare nel registro delle modifiche? Quanto spesso dovrei aggiornarlo? Come dovrebbe essere segmentato?

Ad esempio, se aggiornerò il log delle modifiche per ogni commit, può essere molto esteso, ma è anche importante avere informazioni dettagliate sullo stato di avanzamento del progetto.

Poiché il terzo numero è correlato a correzioni di bug, invece di funzionalità, dovrei segmentare il log delle modifiche in base al numero di versione della funzione? Ad esempio:

# 1.2.0
- Description of this version.
- Fixes
    + 1.2.1 - This is the fix number 01
    + 1.2.2 - This is the fix number 02
    + 1.2.3 - This is the fix number 03
    + 1.2.4 - This is the fix number 04
# 1.1.0
- Description of this version.
- Fixes
    + 1.1.1 - This is the fix number 01
    + 1.1.2 - This is the fix number 02
    + 1.1.3 - This is the fix number 03
    + 1.1.4 - This is the fix number 04

O quali altre considerazioni devo avere quando adotta questo tipo di flusso di lavoro? Tieni presente che sono nuovo in questo scenario, quindi ogni tipo di informazione per me sarebbe molto apprezzata!

version-control web-development change

posta celsomtrindade 10.04.2017 - 18:31

fonte

1 risposta

Leggi altre domande sui tag version-control web-development change

Approccio per l'analisi e l'indicizzazione di file molto grandi In ASP.Net Core, come si risolvono i riferimenti circolari?

score 7 · Accepted Answer

I messaggi di commit in un repository di controllo versione hanno un pubblico diverso rispetto ai log delle modifiche.

Il punto di controllo della versione è tracciare l'evoluzione di una base di codice in modo che tu possa capire in seguito perché qualcosa è stato cambiato e in modo da poter annullare le modifiche se sono problematici. Questo è come un "punto di salvataggio" in un videogioco: se incasini qualcosa, puoi semplicemente tornare indietro. Inoltre, un VCS consente a più sviluppatori di collaborare a un progetto, senza sovrascrivere accidentalmente le modifiche l'uno dell'altro.

Per questi motivi, il pubblico dei messaggi di commit VCS è altri sviluppatori o il tuo sé futuro. Il messaggio di commit sarà spesso piuttosto breve ("implementa la funzione Foo-Bar", "codice reformat"), ma alcuni commit potrebbero anche contenere ampie spiegazioni di questi cambiamenti. Nella mia esperienza, i messaggi di commit per le modifiche alla progettazione o le correzioni dei bug beneficiano di una spiegazione più approfondita.

Al contrario, i log delle modifiche sono per gli utenti . Un log delle modifiche è marketing per i nuovi utenti e assiste gli utenti esistenti quando si aggiornano. Il registro delle modifiche dovrebbe indicare nuove funzionalità, bug risolti o comportamento modificato del tuo software . Qualsiasi modifica dovrebbe essere menzionata qui che, da sola, incrementerebbe il numero di versione. Le modifiche interne che non cambiano il comportamento visibile all'utente non dovrebbero essere menzionate nel registro delle modifiche, anche se meritano il proprio commit.

Ci sono anche delle differenze quando si scrive o si scrive il registro delle modifiche:

Dovresti impegnarsi ogni volta che hai completato un'azione autonoma (come implementare una piccola funzionalità) e commettere separatamente le modifiche separate. Per esempio. se vuoi implementare alcune nuove funzionalità, ma devi prima cambiare il tuo progetto, dovresti avere un commit per la modifica del design, e poi un altro commit per la feature effettiva - mantenere i commit abbastanza piccoli e coesi rende più facile comprenderli in seguito. Inoltre, dovresti impegnarti ogni volta che hai fatto qualcosa che non vorresti perdere. A seconda dello stile personale, questo può comportare più commit all'ora (specialmente quando si effettuano molti piccoli miglioramenti non collegati) o in un commit ogni pochi giorni (ad esempio per lavori sperimentali in cui non si è sicuri di dove si sta andando). In ogni caso, ogni commit dovrebbe rappresentare uno stato funzionante e ben noto dell'applicazione - test prima di eseguire il commit !

Un registro modifiche viene in genere scritto come parte di un processo di rilascio . Prima di rendere disponibile la nuova versione, rivedi tutte le modifiche apportate a questa versione, quindi spiegale agli utenti. Questo spesso implica passare attraverso la cronologia VCS per vedere cosa è cambiato, ma molti commit non sono rilevanti per gli utenti, e quasi tutto dovrà essere formulato in modo diverso in modo che abbia senso per gli utenti. Non è possibile generare automaticamente un log delle modifiche dalla cronologia VCS.