Se mi imbatto in un errore di battitura non critico (ad esempio, un apostrofo errante in un'istruzione print (errore)), vale la pena fare un commit per risolvere quell'errore, o dovrebbe semplicemente essere lasciato da solo?
In particolare, sono curioso di valutare la gommatura del log di commit rispetto al valore della risoluzione di questi refusi non critici. Sono propenso a risolverli. Sono pedante?
La mia sensazione personale è che il miglioramento della qualità valga il piccolo inconveniente di una voce aggiuntiva del registro di commit, anche per piccoli miglioramenti. Dopo tutto, i piccoli miglioramenti contano molto quando si tiene conto dell'effetto della finestra rotta .
Potresti anteporre il prefisso a un tag TRIVIAL: o contrassegnarlo come banale se il tuo VCS lo supporta.
Non sei pedante, ed è meglio risolverli individualmente. Più è atomica una modifica, meglio è - non vuoi che una correzione di bug che si sta arrestando sia mescolata con 500 commenti / errori di battitura.
È sempre utile per aumentare la manutenibilità del tuo software.
Provaci.
... e se non sei il caposquadra, controlla con lui .
Sono d'accordo con gli altri sul fatto che dovresti almeno scrivere qualcosa che lo distingua dai commit "feature", se si tratta solo di correggere un refuso isolato.
Una pratica comune è quella di avere alcuni compiti inanimati nel tuo tracker dei problemi per tenere traccia di cambiamenti senza tempo e senza fine. Ad esempio, non è raro avere un compito per:
Devi solo essere cauto sul fatto che questi non vengano usati come ID delle attività di lancio per qualsiasi cosa, quando le persone diventano pigre nella creazione di biglietti correttamente documentati. Soprattutto se respingi commit che non sono collegati a un ID (che è una buona cosa, ma compiti di questo tipo saranno ancora più interessanti per gli sviluppatori pigri).
Gli errori di battitura dovrebbero essere aggiunti come commit. La correzione di parole errate o errori grammaticali aumenterà la leggibilità del tuo codice.
L'uso di un messaggio di commit come "Errore di battitura fisso" o "Errore di battitura fisso in file.c" ti aiuterà a distinguere questi commit da altri, importanti commit di codice.
Sì, dovresti assolutamente farlo, soprattutto all'inizio di un progetto.
Perché? Due punti:
Probabilmente non saprai se un refuso è "critico" o meno finché non è troppo tardi. Alcune correzioni probabilmente non vengono risolte perché tutti pensano che non sarà un grosso problema. Finché non lo è.
Risolvere un errore prima e deliberatamente sarà molto più facile che risolverlo dopo aver eseguito centinaia di linee di chiamate di codice / funzione. Ancora una volta, gli hack temporanei possono diventare semi-permanenti sorprendentemente rapidamente. Questo è il motivo per cui devo occuparmi di oggetti che hanno entrambi i metodi "CollapseAll" E "ColapseAll".
Per gli errori grammaticali che possono essere visti da un utente finale, allora sì, con tutti i mezzi vale la pena fare il commit in quanto è del tutto possibile che un utente o un QA possa venire e segnalare l'errore e che dovrebbe essere rintracciato. Se è già stato risolto, potrebbe accelerare il tempo necessario per risolvere il problema.
Se si tratta di un errore grammaticale nei commenti attorno al codice, tuttavia, non farei nulla al riguardo a meno che non faccia parte delle modifiche al codice reale e nel qual caso si aggiorni la documentazione del codice.
Se sei preoccupato di gommare il registro di commit, allora stai facendo qualcos'altro. :-) Impegni frequenti sono una buona cosa! Ho commesso errori di battitura tutto il tempo. Prendili nella codebase ASAP e accelera il ciclo di sviluppo!
Io voto di sì. Controllili dentro Ho lavorato per una società che odiava le persone che controllano le cose. Voglio dire quasi tutto. Le recensioni del codice erano estese e quindi se hai fatto il check in una modifica che ha corretto solo un errore di battitura ti sei lamentato. Puoi immaginare lo stato del codice. In realtà il codice non era terribile, ma emanava melassa piuttosto che scorrere come vino.
Il processo di gestione delle modifiche lo consente?
Nel mio ambiente, ogni commit che faccio deve essere legato a una richiesta di modifica che è stata richiesta dagli utenti aziendali o da una modifica obbligatoria a livello di sistema, completa dei corrispondenti processi di test dell'utente finale. Un semplice refuso come quello che stai descrivendo probabilmente non verrebbe registrato come uno di quelli (ho trovato errori di battitura e grammatica in una delle mie app che esisteva da oltre 4 anni senza che nessuno se ne accorgesse), quindi se / quando i revisori è arrivata la chiamata Avrei avuto un momento molto difficile per spiegarmi.
Vorrei salvare un cambiamento come quello che stai descrivendo (e in realtà ne ho uno, in effetti - un nome di metodo è miserpato e l'ho appena scoperto) per un periodo in cui ho un cambiamento "reale" che deve essere fatto anche e mettere "corretti vari errori di battitura" nel registro.
Se sei preoccupato per una cronologia dei commit pulita, valuta di svolgere il tuo lavoro principale in rami delle funzionalità . Se ti capita di lavorare con un VCS distribuito , puoi facilmente modificare la cronologia dei commit prima di inviarla al ramo principale. Se sei su SVN, prova Git - può interagire bidirezionalmente con Subversion e puoi anche modificare la cronologia prima in realtà impegnandosi in Subversion.
Se non vuoi o non puoi modificare la cronologia dei commit, non esiste alcun motivo funzionale per eseguire un commit anticipato o atomico per un errore di battitura minore che non influisce sui test o sulla compilazione automatici . In questo caso, a mio parere, mantenere la cronologia dei commit pulita dovrebbe essere più importante rispetto a fare commit davvero atomici. La miscelazione di una o due correzioni di errore con una modifica "regolare" non danneggerà alcun potenziale processo di revisione. Potresti tuttavia voler raggruppare diverse correzioni banali in un commit, magari quando "ripulisci" dopo una sessione di codifica più grande.
Tieni presente che bug funzionali devono ancora essere commessi al più presto in un commit atomico.
Il tono generale delle risposte qui sembra suggerire una strategia di "commit tutto veloce" anche per errori di battitura minori. Tendo a non essere d'accordo e benvenuto alla discussione.
Leggi altre domande sui tag version-control grammar