Va bene avere commessi intermedi rotti, a condizione che il commit finale in qualsiasi push funzioni?

Correlati: ogni commit git dovrebbe lasciare il progetto in uno stato funzionante?

Supponiamo che esegua i seguenti commit a livello locale:

• Modifica lo schema del database, interrompendo l'applicazione.

• Aggiorna l'applicazione in modo che sia nuovamente compatibile con lo schema del database.

Finché spingo entrambi gli impegni, masterrimane in uno stato di lavoro. Tuttavia, una versione storica è rotta.

Sono consapevole che posso usare git rebase -iper schiacciare i commit insieme. Tuttavia, il commit risultante sarà ampio e meno descrittivo. Se devo cercare nella cronologia del commit per scoprire perché ho cambiato qualcosa, preferirei trovare il commit originale che mostra cosa ho fatto e perché.

Le mie domande sono:

• Qualcuno ha incontrato difficoltà a causa di impegni storici rotti nel master?

• In tal caso, esiste un modo semplice per evitare tali difficoltà, senza eliminare i singoli messaggi di commit e le modifiche?

Dipende in gran parte dalla strategia di branching del tuo outfit, ma penso che avere interrotto gli impegni sui rami di sviluppo abbia un sacco di senso in generale - la vera grande "vittoria" nell'uso del controllo del codice sorgente è quella di essere in grado di ripristinare i piccoli cambiamenti ea volte lo sei preparandone un mucchio e devi rompere le uova per fare delle omelette.

Il modo semplice per mantenere i singoli commit senza inquinare il master è utilizzare i rami. Puoi mettere le cose di rottura / sperimentali lì in modo da poter avere una storia a grana fine senza inquinare la storia del ramo principale.

I commit rotti sono qualcosa che "succede", non dovrebbe significare la fine del mondo. Ho una piccola voce assillante nella parte posteriore della mia testa che mi dice che non si dovrebbe controllare consapevolmente il codice rotto, per una questione di principio e quindi includendo versioni storiche, tuttavia non è qualcosa su cui andrei in guerra.

Il modello di branching molto apprezzato di Git rende possibile tenere interrotti i commit da rami specifici, ad esempio se il tuo team adotta gitflow o una sua versione semplificata. Qualsiasi cosa con una politica "clean master". In questo caso, è possibile verificare la versione finale funzionante come commit di unione, in cui le versioni cronologiche (interrotte) sono disponibili nel repository ma fuori dalla riga principale.

Se la tua squadra non ha adottato un modello così ramificato, allora hai una scusa valida per spingere l'intero lotto da padroneggiare e finirlo.

No, non va bene.

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

Se hai molti commit durante un bisectnon build, avrai molti git bisect skips che rendono difficile trovare l'ultimo buon commit.

Se finisci un ramo di funzionalità e lo unisci in master, pulisci il ramo prima di unirlo in modo che la cronologia sia chiara e in costruzione.

Qualcuno ha incontrato difficoltà a causa di impegni storici rotti nel master?

Sì. Backport, revert e bisec sono più difficili. Quindi sta leggendo la storia (vedi sotto).

In tal caso, esiste un modo semplice per evitare tali difficoltà, senza eliminare i singoli messaggi di commit e le modifiche?

Non che io lo sappia, anche se i rami sono una soluzione decente.

Tuttavia, penso che scartare (o piuttosto schiacciare) l'individuo commetta sia la cosa giusta da fare.

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

Tuttavia, una volta che una funzione / modifica è pronta per essere inviata, un commit è un cambiamento impacchettato - idealmente atomico, in modo che possa essere [rivisto, riformulato, unito, selezionato, ripristinato, visualizzato in annotazione] nel modo più indipendente possibile dalle altre modifiche .

Guardando la storia di un progetto, una modifica del software dovrebbe essere valutata da sola. Costruisce? Viene fornito con i test? Funziona? Che cosa fa? Quali file devono essere modificati per offrire quella funzione?

Dover riunire gli impegni, se possibile (e aiutato dalle fusioni), rende tutto più difficile. Pertanto, penso che ripulire la tua storia prima di spingere sia appropriato, anche se significa perdere la traccia di come sei arrivato a dove ti trovi.

Risposta breve: Sì

test:

Lo sviluppo guidato da test significa che si scrivono test che si interrompono (ad es. Mostrare errori).
Quindi scrivi il codice per far funzionare i test.

Sviluppo:

Commettere in piccolo, Commettere spesso.
Ogni commit è un punto di rollback. Se ti rendi conto di essere sulla strada sbagliata, puoi tornare a un punto precedente relativamente facilmente. Se si è impegnati abbastanza bene, è possibile tornare al punto corretto.

Avvertimento:

Questo non significa

1) Controlli il codice non funzionante nel master.
2) È necessario inviare tutti i microimpegni affinché tutti possano esaminarli.

Usa i rami per fare il tuo lavoro. Comprimere potenzialmente i micro commit per i processi di revisione in modo che si trovino in unità logicamente distinte con commenti appropriati. Se stai usando git non perderai il set originale di commit, puoi semplicemente creare un nuovo set più logico di commit per i processi di revisione che verranno uniti in master.

Penso che fintanto che gli impegni sono locali e non spinti verso gli altri non è solo ok, è in realtà un buon modo di lavorare. Basta non spingere il codice rotto ad altri.