Utilizzo dei messaggi di commit per il monitoraggio del tempo

Ho visto anche questa funzione, e sono anche cauta. Se dovessi articolare il mio ragionamento, direi che confonde la pulizia e l'intento di un messaggio di commit. Quando mi chiedo "qual è l'intento di un messaggio di commit?", È come se fosse una sorta di pangrattato per me e per gli altri su ciò su cui stavo lavorando e su come ho cercato di migliorarlo.

A tal fine, un messaggio di commit con un numero di rilascio è in realtà una cosa buona , perché sia io che un altro programmatore ci si potrebbe davvero interessare e usarlo come riferimento. Avere solo un numero di problema senza descrizione non è particolarmente utile senza lo strumento di tracciamento del problema, quindi cerco di evitarlo e mantengo almeno una breve descrizione. Avere un numero di problema anche senza accedere al bug tracker potrebbe ancora aiutare i miei occhi a individuare facilmente i commit relativi.

Ma il monitoraggio del tempo? Tra sei mesi, non mi avvantaggeranno né io né un altro programmatore. Inoltre, renderà il log di commit disordinato.

Non vedo nulla di sbagliato in questo, a patto che non oscuri lo scopo originale del commit dei messaggi - dicendo di cosa tratta il cambiamento. Se usi questi strumenti, perché dovresti avere qualcosa contro cui essere meglio integrato l'uno con l'altro?

Se il tuo CI è integrato con il repository, puoi seguire un singolo link da una build fallita all'elenchannel che lo ha causato, e da lì al ticket di emissione e le revisioni del codice della modifica, è semplicemente una comoda scorciatoia per cose dovresti comunque cercare te stesso. Penso che possiamo essere d'accordo.

Questa funzione fa un ulteriore passo in avanti. E anche se non mi interessa molto per il monitoraggio del tempo, non è che ci voglia molto tempo per farlo manualmente: creare o aggiornare una recensione con una singola riga sarebbe fantastico.