Ho lavorato come sviluppatore solitario per molto tempo. Durante questo periodo, ho sviluppato un modo di formulare e ordinare i messaggi di commit: prima Refactor, descrivere esattamente il motivo del commit nel messaggio, link al tracker del problema, ... C'è persino uno script per creare diversi tipi di log delle modifiche (pubblico, azienda interna, sviluppatore) dalla cronologia dei commit. In questo modo, lo so sempre, quando e perché il codice nel codebase è cambiato allo stato in cui è ora.
Con l'avvento del rebase interattivo e il riordino dei commit, posso facilmente assicurarmi che la cronologia (e, quindi, la documentazione) appaia esattamente nel modo in cui voglio che sia. Il codice errato non entra nemmeno nella cronologia. Quindi, ogni commit ha il suo scopo ben definito.
Mi ci sono voluti anni per evolvere questa pratica, che considero buona. (È vero?) Tuttavia, applicarlo alle modifiche al codice di qualcun altro (ad esempio, riscrivere la cronologia delle modifiche di qualcun altro) è, per me, un compito che richiede molto tempo. Ho provato questo per identificare modifiche non necessarie o addirittura errate. La dimensione totale della patch in questione è leggermente troppo grande per essere rivista come una singola unità e ci sono alcune modifiche al codice discutibili.
In effetti, risulta che non posso permettermi di controllare il codice base come un "dittatore". Costa solo troppo tempo. Quindi mi piacerebbe perdere il controllo mantenendo una buona qualità del codice. Al momento, non vedo come ottenere ciò.
"Quanto pulito" dovrebbe essere la storia di un progetto? Quale formato e granularità per i commit dovrei richiedere? Dovrei chiedere allo sviluppatore di riformattare la cronologia (ad es. Per dividere un commit), anche se richiederebbe un'istruzione su come dividere un commit dopo il fatto? Devo insegnare agli sviluppatori a lavorare su rami delle funzionalità ? È possibile aiutare modelli di commit ? Con quale frequenza dovrebbero essere rivisti i cambiamenti degli altri?