Il tuo progetto dovrebbe usare quasi sempre il tempo passato . In ogni caso, il progetto dovrebbe sempre usare lo stesso tempo per coerenza e chiarezza.
Comprendo alcuni degli altri argomenti che sostengono di usare il presente, ma di solito non si applicano. I seguenti punti elenco sono argomenti comuni per la scrittura nel presente e la mia risposta.
- Scrivere nel tempo presente dice a qualcuno cosa farà l'applicazione del commit , piuttosto che cosa hai fatto.
Questo è il motivo più corretto per cui si vorrebbe usare il tempo presente, ma solo con il giusto stile di progetto. Questo modo di pensare considera tutti gli commit come miglioramenti o funzionalità opzionali e sei libero di decidere quali commit mantenere e quali rifiutare nel tuo specifico repository.
Questo argomento funziona se hai a che fare con un progetto veramente distribuito. Se hai a che fare con un progetto distribuito, probabilmente stai lavorando a un progetto open source. Ed è probabilmente un progetto molto grande se è realmente distribuito. In effetti, probabilmente è il kernel Linux o Git. Dato che Linux è probabilmente ciò che ha causato la diffusione e la popolarità di Git, è facile capire perché le persone considerino il suo stile l'autorità. Sì, lo stile ha senso con quei due progetti. O, in generale, funziona con progetti distribuiti di grandi dimensioni, open source .
Detto questo, la maggior parte dei progetti nel controllo del codice sorgente non funziona in questo modo. Di solito non è corretto per la maggior parte dei repository. È un modo moderno di pensare a un commit: i repository Subversion (SVN) e CVS potrebbero a malapena supportare questo stile di check-in di repository. Di solito un ramo di integrazione gestiva il filtraggio dei check-in non validi, ma quelli generalmente non erano considerati "opzionali" o "funzionalità utili".
Nella maggior parte degli scenari, quando si esegue il commit in un repository di origine, si sta scrivendo una voce del diario che descrive cosa è cambiato con questo aggiornamento, per rendere più facile per gli altri in futuro capire perché è stata apportata una modifica. Generalmente non si tratta di un cambiamento facoltativo: altre persone nel progetto sono tenute a fondersi o rifarsi su di esso. Non scrivi una voce del diario come "Caro diario, oggi incontro un ragazzo e mi saluta ", ma invece scrivi "Ho incontrato un ragazzo e mi ha salutato".
Infine, per tali progetti non distribuiti, il 99,99% delle volte in cui una persona leggerà un messaggio di commit è per leggere la storia - la storia viene letta al passato. 0,01% delle volte deciderà se applicare o meno questo commit o integrarlo nel proprio ramo / repository.
- Consistenza. È così in molti progetti (incluso Git stesso). Anche gli strumenti git che generano commit (come git merge o git revert) lo fanno.
No, ti garantisco che la maggior parte dei progetti mai registrati in un sistema di controllo della versione ha avuto la sua storia al passato (non ho riferimenti, ma probabilmente è giusto, considerando che l'argomento del presente è nuovo dopo Git). I messaggi di "revisione" o di commit dei messaggi al presente hanno iniziato a dare un senso solo a progetti realmente distribuiti - vedere il primo punto sopra.
- Le persone non solo leggono la storia per sapere "cosa è successo a questo codebase", ma anche per rispondere a domande come "cosa succede quando seleziono questo commit" o "che tipo di cose nuove accadranno alla mia base di codice a causa di questi commit Potrei o meno unirmi in futuro ".
Vedi il primo punto. Il 99,99% delle volte in cui una persona leggerà un messaggio di commit è per la lettura della cronologia: la cronologia viene letta al passato. 0,01% delle volte deciderà se applicare o meno questo commit o integrarlo nel proprio ramo / repository. Il 99,99% batte lo 0,01%.
Non ho mai visto un buon argomento che dice che usare un tempo / grammatica impropri perché è più breve. Probabilmente risparmierai solo 3 caratteri in media per un messaggio standard di 50 caratteri. Detto questo, il tempo presente in media sarà probabilmente più corto di alcuni caratteri.
- Puoi assegnare un nome ai commit in modo più coerente con i titoli dei ticket nel tracker del numero / funzione (che non usano il tempo passato, anche se a volte in futuro)
I biglietti sono scritti come qualcosa che sta accadendo (ad esempio, l'app mostra un comportamento sbagliato quando faccio clic su questo pulsante) o qualcosa che deve essere fatto in futuro (ad esempio, il testo avrà bisogno di una revisione da parte dell'editor).
La cronologia (ovvero i messaggi di commit) è scritta come qualcosa che è stato fatto in passato (ad esempio, il problema è stato risolto).