Flusso di lavoro di Github: invio di piccole correzioni a remoto o mantenimento locale?

Preferibilmente spingerlo all'origine in quanto ciò significa che tutti gli altri vedranno che qualcun altro sta lavorando su una correzione. Inoltre, anche se qualcosa è una piccola correzione misurata dal numero di caratteri, può fare un'enorme differenza nell'esecuzione, quindi la dimensione della correzione non dovrebbe fare alcuna differenza nel modo in cui la risolvi.

Tuttavia, praticamente quando ho usato git ci è voluto così tanto tempo per sincronizzare che avrei unito un gruppo di piccole correzioni insieme e ho lasciato che altri sviluppatori lo sapessero via e-mail che stavo lavorando su di loro.

Dipende davvero da questo. Mi impegno in modo frenetico localmente, ma commetto solo (presumibilmente lavorando) punti cardine nel repository remoto. Storicamente, le migliaia di commit locali non aggiungono più valore alla più grande base di codice come le cose a livello di funzionalità (IMO). Crea clutter (IMO).

Se il tuo fix_123 è un commit completo e funzionale, forse una correzione di bug o qualche altra attività isolata, ha più senso impegnare ognuno di questi allo sviluppo. Se viene segnalato il numero di errore 10402030 e il commit e il push da local riguardano solo lo stato di correzione completo che non è una cosa così brutta.

Un modo per limitare l'ingombro sul repository remoto è quello di schiacciare alcuni commit rebasing come menzionato QUI . Io uso solo git in progetti personali al di fuori del mio lavoro retribuito, quindi se sono viziato nei miei metodi non mi dispiace commenti correttivi.

Su tutto questo, le pratiche di controllo della versione possono quasi essere come discutere di religione. Avrai opinioni e pratiche selvaggiamente diverse, ma in realtà dipende da cosa si adatta al progetto e all'organizzazione.