Va bene aver rotto i commit intermedi, a patto che il commit finale in qualsiasi push lavori?

Dipende in gran parte dalla strategia di branching del tuo outfit, ma penso che avere dei commit errati sui rami di sviluppo abbia un senso in generale - la vera grande "vittoria" nell'uso del controllo del codice sorgente è di essere in grado di ripristinare piccoli cambiamenti e a volte ne stai facendo un mucchio e devi rompere le uova per fare omelette.

Il modo semplice per mantenere il commit individuale senza padrone inquinante è utilizzare i rami. Puoi inserire il materiale di rottura / sperimentale in modo che tu possa avere una storia a grana fine senza inquinare la storia del ramo principale.

I commit corrotti sono qualcosa che "semplicemente accade", non dovrebbe significare la fine del mondo. Ho una piccola voce fastidiosa nella parte posteriore della mia testa che mi dice che non dovremmo consapevolmente controllare codice non funzionante, in linea di principio e quindi includendo versioni storiche, tuttavia non è qualcosa che io andare in guerra.

Il modello di branching molto elogiato di Git rende possibile mantenere i commit interrotti su rami specifici, ad es. se il tuo team adotta gitflow o una sua versione semplificata. Qualunque cosa abbia una politica "clean master". In questo caso, è possibile effettuare il check in nella versione finale, funzionante, come commit di unione, in cui le versioni storiche (interrotte) sono disponibili nel repository ma fuori dalla linea principale.

Se la tua squadra non ha adottato un modello di ramificazione di questo tipo, allora hai una scusa valida per spingere l'intero lotto a padroneggiarlo e farla finita.

No, non va bene.

Se hai mai fatto un git bisect (e chi non ama quella caratteristica killer), conosci il valore di una storia in cui ogni commit si costruisce.

Se hai molti commit durante un bisect che non si genera, avrai un sacco di git bisect skip s che rende difficile trovare l'ultimo commit buono.

Se finisci un ramo di funzione e lo unisci in master, ripulisci il ramo prima della fusione in modo che la cronologia sia chiara e in costruzione.

Has anyone encountered difficulties due to broken historical commits in master?

Sì. Backport, reverts e bisects sono più difficili. Così sta leggendo la cronologia (vedi sotto).

If so, is there a simple way to avoid such difficulties, without discarding individual commit messages and changes?

Non lo so, anche se i rami sono una soluzione decente.

Tuttavia, penso che scartare (o meglio schiacciare) i singoli commit sia la cosa giusta da fare.

Durante lo sviluppo, specialmente quando si fa TDD, si commette presto e spesso è buono. Vuoi la traccia completa di quello che stai facendo in modo che tu possa tornare indietro, o capire esattamente quando le cose hanno iniziato a andare storte (o forse ti sei messo in un refactoring più grande di quanto puoi masticare). Impegnati.

Tuttavia, una volta che una funzionalità / cambiamento è pronta per essere spinta, un commit è una modifica pacchettizzata - idealmente atomico in modo che possa essere [rivisto, ribasato, unito, selezionato, ripristinato, visualizzato nell'annotazione] come indipendentemente dagli altri cambia il più possibile.

Guardando la storia di un progetto, un cambiamento di software dovrebbe essere valutato da solo. Costruisce? Viene con i test? Funziona? Che cosa fa? Quali file dovevano essere modificati per fornire quella funzionalità?

Dovendo assemblare i commit, mentre possibile (e aiutato dalla fusione), rende più difficile. Pertanto, penso che ripulire la cronologia prima di spingere sia appropriata, anche se significa perdere traccia di come sei arrivato dove sei.

Risposta breve: Sì

Test:

Lo sviluppo guidato dai test implica la scrittura di test che si interrompono (ovvero mostrano errori).
Quindi scrivi il codice per far funzionare i test.

Sviluppo:

Impegnati in piccole, Impegnati spesso.
Ogni commit è un punto di rollback. Se ti accorgi di essere sulla strada sbagliata, puoi eseguire il rollback su un punto precedente in modo relativamente semplice. Se i commit sono abbastanza precisi, è possibile eseguire il rollback al punto corretto.

Caveat:

Questo non significa

1) Controlla il codice rotto nel master.
2) Devi spingere tutti i micro commit a tutti da recensire.

Usa i rami per fare il tuo lavoro. Comprimi potenzialmente micro-commit per i processi di revisione in modo che siano in unità logicamente distinte con commenti appropriati. Se stai usando git, non perderai l'insieme originale di commit, puoi solo creare un nuovo set più logico di commit per le procesioni di revisione che saranno unite in master.

Penso che finché i commit sono locali e non vengono trasmessi agli altri non è solo ok, è in realtà un buon modo di lavorare. Basta non spingere il codice rotto ad altri.