È git schiacciare una buona pratica per l'attività ordinaria?

Un altro possibile scenario di utilizzo di git squash potrebbe essere quando si sviluppa una funzionalità davvero grande nel ramo di funzionalità.

Di solito, quello che preferisco è, quando lavoro in una succursale, per schiacciare i miei impegni, al fine di mantenere la storia serrata. (È qualcosa come tag nei tuoi rami).

Quando si tratta di unire il mio ramo funzionale al master ho due opzioni: o spingere tutte le pietre miliari in uno solo per rendere possibile il ripristino più facile (nota che questo non ripristinerà l'unione) o lasciarlo con pietre miliari e unirlo così com'è.

Anche se non penso che ci sia un problema nel fare un sacco di piccoli commit git significativi, sono d'accordo sul fatto che non vuoi un sacco di commit "testing" (questo potrebbe rendere qualsiasi conflitto durante un rebase davvero doloroso da gestire come li ripete).

Analizzerei qualsiasi strumento tu stia utilizzando per la distribuzione nel cloud e ci dovrebbe essere un modo per testare / distribuire / ridistribuire manualmente (ad esempio, invece di lasciare che un githook si inneschi in modo uniforme, attivarlo facendo clic ricostruzione / replica). Conosco Jenkins, Travis-CI e Circle-CI, tutti hanno questa funzionalità, e mi aspetto che la maggior parte degli altri servizi di build / implementazione lo consentano.

Nel caso in cui ogni commit deve testare una configurazione di distribuzione / build, come .travis.yml , in modo che tu possa avere 10 commit ma solo l'ultimo apporta la modifica che desideri. I team su cui ho lavorato hanno utilizzato git merge --squash come @gnat suggerisce in questi casi (o git reset --hard con copia e ritorno nel file desiderato ma questo è meno "pulito").