I messaggi di commit dovrebbero essere scritti al presente o al passato? [chiuso]

102

Quindi qual è che ritieni sia migliore e più intuitivo?

Fixed the XXX bug in YYY
Fix the XXX bug in YYY
Fixes the XXX bug in YYY
Fixing the XXX bug in YYY

Fornisci le tue motivazioni. Nota che lo chiedo dal tuo punto di vista generale, il che significa che non dovresti provare ad associarlo ai tuoi strumenti svn / cvs o linguaggi di programmazione preferiti, ma piuttosto pensarlo come qualcosa che dovrebbe / può essere applicato a qualsiasi strumento e linguaggio di programmazione.

version-control coding-style

— Her
fonte

Qualcuno al tuo lavoro è troppo pedante, spero che non sia tu. Chiunque sia dovrebbe considerare il presente perfetto contro il presente imperfetto, e l'enigma filosofico se il commento di commit viene letto come se fosse stato tipizzato o come fosse stato esso stesso persistito nel repository. In quest'ultimo caso, usa il presente perfetto per un'azione completata. Nel primo caso, usa imperfetto per un'attività presente incompleta.

— Heath Hunnicutt

1

Non una vittima di quella domanda. Questo sta chiedendo un piccolo aspetto, non linee guida generali.

3

Per fortuna non lo è. Stavo chiedendo, cercando di scoprirlo, vorrei sapere qual è la pratica generale là fuori. Se devo dirti la verità, questa è in realtà la domanda più insignificante che abbia mai fatto su SO, ma ehi, è ancora una domanda, no? La domanda stessa ha ottenuto tre voti, il che (se non ovvio per te) dice che non sono l'unico là fuori a pensare che questa domanda sia valida in sé. Cerco risposte costruttive e tu non mi stai affatto aiutando.

— Il suo

1

Se pensavi che le persone non dovessero preoccuparsi troppo dei tempi nei messaggi di commit, dillo bene, indica le tue ragioni e le tue preferenze. Molto più utile e utile del tuo commento sarcastico sopra.

— Il suo

10

Prendo molto seriamente questa domanda. È un'ottima domanda. Essere coerenti è molto importante quando si sviluppa un software, ed essere così dovrebbe interessare tutti i visitatori interessati all'argomento di questo sito web. Questa è la mia opinione.

— Niklas Berglund

39

Penso a questi messaggi come appaiono agli altri sviluppatori. Non hanno ancora applicato le modifiche e c'è la domanda implicita: "cosa farà l'applicazione di questo changeset / patch?" "Risolverà il bug XXX in YYY"!

Per altri verbi, scriverli come un comando sembra più naturale e funziona meglio se hai un obiettivo specifico in anticipo: puoi letteralmente scrivere il riepilogo del commit insieme a test iniziali prima che il lavoro sia finito.

Non ci metto un peso enorme, ma per me questo è il percorso di minor resistenza pur mantenendo la coerenza.

— Roger Pate
fonte

8

Ricordo di aver trovato qualcosa nella documentazione di git che consigliava fortemente questo tempo, ma trovo ancora imbarazzante.

— keithjgrant

1

Questo è il pezzo di documentazione di Git da cui proviene.

— sschuberth

31

Personalmente vado con il passato ("riparato") poiché nel momento in cui arrivo a eseguire il commit il bug è stato risolto (o non lo farei).

— Cletus
fonte

Puoi fare un esempio di questo?

— bzlm

15

un esempio di questo.

— Reverendo Gonzo

Si chiama "Commit History". La storia è sempre scritta al passato. Quindi il passato ha più senso. Quando esamini anche la cronologia dei commit di un repository, stai osservando cosa è stato fatto ... in passato!

— Shiva

13

Preferisco vedere i messaggi di commit al presente. In questo modo il messaggio descrive cosa fa il diff (perché potresti tirare quel diff o anche l'intero commit in un ramo diverso). Pertanto, il messaggio di commit non descrive cosa "ha fatto" fare ... Descrive cosa "fa" il commit stesso. Quindi dovrebbe essere al presente.

Immagina di guardare un diff da solo e provare a decidere se lo applicherai. Non ha senso che abbia un titolo al passato.

— TedPavlic
fonte

1

"cosa fa il diff" ma il diff è creato da un commit che è stato commesso , è già nella cronologia di git, quindi era già "applicato".

— Iulian Onofrei

9

IMHO se vuoi che sia descrittivo senza bisogno di considerare il contesto, allora "Fisso" è sicuramente l'unica variante giusta.

Per quanto riguarda l'intuitività - se guardo qualche changelog capirò sicuramente che intendi il bug corretto poiché conosco il contesto in cui viene usata la parola, ma il mio cervello lo coglierà molto più velocemente se la parola è scritta in questo sé- specificando il modo.

"Fixing" è la scelta peggiore IMHO in quanto può essere interpretato non solo come una descrizione di ciò che la patch fa (è per) ma anche come uno stato di bug, il che significherebbe che si sta lavorando e non è ancora risolto.

— Ivan
fonte

7

Fix the XXX bug in YYY
Teach the XXX to be more ZZZ
Correct typos in javadoc

In generale: {verbo imperativo} l '{oggetto interessato} {qualificatori facoltativi}

La forma imperativa si adatta a tutti i casi d'uso quando prendo in considerazione un patchset.

Cosa farai qui?
Cosa fa questo patchset?
Perché è stato creato questo patchset? (per correggere il bug xxx ...)
Ho bisogno di correggere il bug xxx in yyy. C'è un commit su un altro ramo che lo fa già?

Indipendentemente dalla tua scelta, trovo che la coerenza aiuti immensamente la leggibilità. Scegline uno e mantienilo.

— phord
fonte

4

Ottime ragioni. Lo considero sempre come se il messaggio dicesse "Sono una patch e io [messaggio]". In questo modo inizi sempre con un verbo imperativo.

— florisla

5

Penso che scrivere del commit corrente al presente sia una buona idea, perché lo rende più chiaro quando ti riferisci a commit precedenti al passato.

— Ken Bloom
fonte

1

Sono d'accordo. Se il commit fa riferimento a se stesso, è anche vero, come in "Questo commit risolve il bug F00F".

— bzlm

4

Non credo che importi davvero. Lo scopo è:

1) Trasmettere ciò che è stato o è stato fatto, in modo che i bug possano essere trovati più facilmente, i problemi possono essere ripristinati più facilmente e in genere è possibile mantenere il progetto più facilmente.

2) Comunica quali ticket sono stati corretti, se ce ne sono, in modo che i revisori (se utilizzati nella tua azienda possono vedere quali modifiche corrispondono a quali ticket).

Infine, se è già stato corretto, "Fixing" non ha senso, e se ci stai ancora lavorando, "Fixed" non è corretto.

— Reverendo Gonzo
fonte

1

Certo, a rigor di termini, è vero che non ha molta importanza. Ma se devi sceglierne uno, quando hai corretto un bug nel tuo albero locale e vuoi confermare le modifiche apportate, dici "Fixes XXX" o "Fixes XXX" o "Fix XXX"?

— Il suo

1

Penso che sia importante se il testo è troppo breve. A volte vedo messaggi di commit che mi fanno domandare se 1. un bug è stato trovato o effettivamente risolto, o 2. se una correzione è stata concessa o effettivamente applicata, o 3. se un comportamento erroneo complesso è stato parzialmente o effettivamente risolto completamente. E a volte diversi commit si riferiscono allo stesso bug. In "Questo commit risolve il problema del rimbalzo in DrawBall () e chiude il ticket 666" il tempo non ha importanza, perché il testo è dettagliato. Ma per "DrawBall () rimbalza male", cosa ha fatto il commit?

— bzlm

2

" Fix bug X " è di 2 caratteri più corto di " Fixed bug X ".
E 3 in meno rispetto a " Fixing bug X ".

Dal punto di vista della scrittura di messaggi brevi, il tempo presente a volte / di solito salva pochi caratteri?
Che in realtà penso che importi un po ', ad esempio con la raccomandazione di Git di meno di 50 caratteri sulla prima riga del messaggio di commit.
Inoltre, meno testo -> hai letto più velocemente?

— KajMagnus
fonte

1

Un messaggio di commit descrive il motivo per cui hai scritto il codice che viene sottoposto a commit.

"Risolto problema 3124" o "Risolve problema 3124" sembra corretto perché dice che questo codice ha risolto | risolve il problema 3124.

Tuttavia, la grammatica può anche dipendere dal motivo per cui contrassegna il bug come risolto. Se puoi contrassegnare il bug come corretto dopo aver eseguito il commit, allora "Fixed" va bene, ma se il bug verrà contrassegnato come corretto da qualcun altro dopo aver verificato il tuo codice, allora "Fixes" potrebbe essere più appropriato.

— parag
fonte

0

Penso che la risposta più importante a una domanda del genere sia: tutti dovrebbero usare ciò che funziona per un progetto specifico e mantenerlo almeno un po 'coerente.

Anche se vedo i vantaggi dell'uso del tempo presente (e in effetti mi sono imbattuto in questo post perché ho visto alcuni messaggi sul presente in progetti open source), probabilmente non userò mai il tempo presente per i miei progetti. È il modo consigliato per Linux e Git, e probabilmente altri progetti open source più grandi, ma onestamente non mi interessa finché non faccio parte di questi progetti.

Sono uno sviluppatore indie e utilizzo la prima riga di un messaggio di commit per le note di rilascio mentre la descrizione nelle righe seguenti mi dà un'idea dei dettagli di implementazione. È un flusso di lavoro incentrato sull'utente rispetto al presente approccio basato sullo sviluppatore. Posso risparmiare un po 'di tempo in questo modo. Sarebbe estremamente innaturale fornire ai miei utenti istruzioni nelle note di rilascio. Il mio lavoro è correggere i bug e aggiungere funzionalità. Devo risparmiare tempo, perché sono un indie. Non ho uno "scrittore di note di rilascio" nel mio team.

Usa le regole di un progetto se sono già stabilite, ma rimani pragmatico e fai tutto ciò che renderà il tuo lavoro più facile o più veloce.

— Rafael Bugajewski
fonte

-1

Penso che "Fixes XXX bug"abbia più senso che "Fix XXX bug"se la ragione per usare il tempo presente fosse "renderlo più descrittivo di ciò che fa il commit" piuttosto che ciò che ha fatto il committer.

— technophyle
fonte

-4

Se si tratta di un piccolo commit utilizzo il present continuous:

Correzione del bug 304

o

Aggiunta di commenti

Se è un grosso impegno, faccio più di un registro delle modifiche:

Risolve i bug 453, 657 e 324
Aggiunta della sintassi dell'espressione
Refactored la classe Operator.

— tster
fonte

9

in altre parole li mischi tutti volenti o nolenti B-)

— Brian Postow

Abbastanza. Perché alla fine, i messaggi di commit non devono essere le regine inglesi.

— tster

2

Non dovresti comunque fare molte cose diverse in un commit.

— florisla