Suggerimenti: buon formato per messaggi brevi / di commit per User Story e attività secondarie

1

Vorrei che la tua opinione riguardo a un buon stile / formato per i messaggi brevi durante il commit in un repository (GIT o SVN).

Considerando che stiamo utilizzando un approccio di sviluppo di un ramo di funzionalità, con un ramo per funzionalità assegniamo a un solo sviluppatore in qualsiasi momento e sono interessato a impegnarmi spesso nel repository.

Immaginiamo di avere un "User Story / Case" da codificare, ad esempio:

  • User Story 125: aggiunta dello stile di base all'immagine del widget

"User Story" è suddiviso in sottocomponenti, questi sono particolarmente tecnici, esempio:

  • 01 Modifica il tag immagine CSS.
  • 02 Aggiornamento decoratore.
  • 03 widget di aggiornamento istanza in Pannello.

....

Al momento utilizziamo questo formato / stile quando eseguiamo il commit:

STATUS - USER CASE - TASK

Esempio:

PROGRESS : User Story 125: Adding basic style to widget Image - 01 Change CSS image tag

con significato:

  • Il primo compito per una User Story specifica è stato in competizione, ma la User Story non è ancora completata.

Questo viene ripetuto per ogni sottoprocesso completato.

Quando tutte le attività secondarie sono state completate, utilizzo questo formato:

STATUS - USER CASE

Esempio:

  • FATTO: User Story 125: aggiunta dello stile di base all'immagine del widget

Lo stesso approccio è usato per i bug.

Quando il ramo è marge alla linea principale usiamo:

DONE - USER CASE

Senza menzionare le sotto-attività.

Vorrei avere la tua opinione su:

  • Vedi qualche CONS per questo approccio?
  • Come cambieresti / migliorerai di conseguenza con alcune buone pratiche?
  • Per GIT, ha senso utilizzare "staging" sul ramo sviluppatore quando si eseguono sottoprocessi?

Grazie in anticipo per il tempo dedicato a questo.

    
posta GibboK 16.03.2016 - 12:41
fonte

1 risposta

2

Molti strumenti usano la prima frase o la prima riga del messaggio di commit come sommario e il formato che hai scelto è molto prolisso. Questi strumenti hanno spesso una quantità limitata di spazio e la brevità (insieme alla chiarezza) in generale è buona per i messaggi di commit.

Ad esempio, con un prefisso lungo e solo 32 caratteri per mostrare il riepilogo, i progressi su tre attività a cui tutti chiedono di aggiungere qualcosa potrebbero essere:

  • PROGRESS: User Story 125: Addin ...
  • PROGRESS: User Story 125: Addin ...
  • PROGRESS: User Story 125: Addin ...

Confrontalo in una forma più concisa che utilizza un'abbreviazione per la storia e ometti "PROGRESS:":

  • # 125: aggiunta dello stile di base a widg
  • # 125: aggiunta di test per il nuovo stile
  • # 125: aggiunta di correzione per documentati

Questo è un esempio un po 'forzato. Il punto è che con il tuo formato, la parte unica del tuo messaggio - la parte interessante - è molto a destra del messaggio.

Proprio come con il codice, devi ottimizzare per chiarezza. A meno che tu non abbia davvero bisogno di "PROGRESS" e "User Story", consiglio di ometterli a favore di qualcosa di più conciso. In particolare, "PROGRESS" sembra assolutamente inutile - non tutti i progressi sono in corso? Puoi ancora usare "DONE" per il passaggio finale e assumere che se non hai "DONE", allora deve essere "PROGRESS".

Per ulteriori letture, ecco alcuni buoni articoli:

risposta data 16.03.2016 - 17:17
fonte

Leggi altre domande sui tag