Tipo di commit in stile AngularJS per un bump di versione

Question

Tipo di commit in stile AngularJS per un bump di versione

#1 da (1 voti)

-1

Il formato dei messaggi di commit di AngularJS è un insieme di regole su come dovrebbe apparire il tuo messaggio di commit. È stato adottato da AngularJS e altri progetti. In base a queste regole, un commit deve essere etichettato nel suo oggetto con uno dei seguenti tipi di commit:

feat: A new feature

fix: A bug fix

docs: Documentation only changes

style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)

refactor: A code change that neither fixes a bug nor adds a feature

perf: A code change that improves performance

test: Adding missing or correcting existing tests

chore: Changes to the build process or auxiliary tools and libraries such as documentation generation

Che tipo dovrebbe avere un commit se solo urta un numero di versione che è memorizzato nel codice? Ad esempio, potrebbe essere il messaggio che il programma foo stampa quando si esegue foo --version o il valore di ritorno di your_framework.version() . Non sembra un compito perché cambia ciò che fa il codice stesso. È un impresa ? (Non ho trovato tali commit nella storia di AngularJS e in un altro progetto, quindi potrebbe essere che non vengano utilizzati.)

git version-control programming-practices

posta nwk 06.11.2017 - 16:21

fonte

1 risposta

Leggi altre domande sui tag git version-control programming-practices

Oggetto nullo ed eccezioni L'autenticazione basata su criteri rimuove la sicurezza di refactoring?

score 1 · Accepted Answer

Come per qualsiasi altro processo, adottalo in base alle tue esigenze. Il valore della convenzione offerta da AngularJS è che ogni commit rimane necessariamente focalizzato e che l'ambito / impatto di un commit può essere valutato più facilmente. Fintanto che aderisci allo spirito di questo processo, non ci sono problemi con l'estensione o la modifica di questa categorizzazione.

Potresti espandere il significato di chore per includere il lavoro amministrativo che porta a una versione (ad esempio, il bumping delle versioni in vari punti).
Potresti introdurre un altro formato di messaggio di commit come release v1.2.3 utilizzato per i candidati al rilascio.

A seconda della modalità di distribuzione del software, è possibile decidere di non codificare alcun numero di versione in qualsiasi momento. Invece, il numero di versione è inserito nel software dal processo di compilazione. Questo è per lo più appropriato per i programmi compilati in cui il codice sorgente non viene eseguito direttamente. Ma anche per i linguaggi "interpretati" è spesso una buona idea eseguire il controllo delle versioni solo con il controllo del codice sorgente e il sistema di generazione, e non duplicare il numero di versione nel codice.