Ogni commit git dovrebbe lasciare il progetto in uno stato funzionante?

Sono curioso di sapere qual è la migliore pratica prevalente. I commit di git devono essere applicati in modo tale che il progetto sia in uno stato di funzionamento (viene compilato correttamente, tutti i test superano ecc.) Oppure il commit del codice non funzionante è corretto?

Ad esempio, se si rinuncia a questo requisito, si può essere più flessibili con i commit (usarli come blocchi logici, anche se l'app non è in uno stato funzionante, ecc.). Tuttavia, se lo imponi, otterrai la flessibilità di essere in grado di selezionare in modo preciso qualsiasi dato impegno in seguito ...

Di solito seguo questa regola:

• Ogni unione alla masterfiliale deve lasciare il progetto in uno stato funzionante;
• Ogni unione al developramo principale dovrebbe lasciare il progetto in uno stato di lavoro (e deve almeno costruirlo);
• Ogni altro impegno individuale ha l'obiettivo primario di spiegare perché il cambiamento è stato fatto, a cosa serve e quali parti del progetto ha interessato. Tutti gli altri obiettivi, come lasciare il progetto in uno stato di lavoro, sono facoltativi.

Usa il clone locale del repository per qualsiasi cosa ti faccia sentire a tuo agio durante lo sviluppo.

Commetto regolarmente il codice non funzionante e quando sono pronto a renderlo disponibile per altri sviluppatori, utilizzo una funzionalità eccezionale:

git rebase -i HEAD~4

Questo mi permette di comprimere il mio intermedio (in questo caso 4 di essi), eventualmente interrotto, si impegna in un buon commit. Ti verrà presentato un editor che ti consentirà di scegliere come compattare tali commit. In genere ho contrassegnato il primo commit del commit 'pick' e contrassegno gli altri 'squash'.

Quindi posso spingere quel commit atomico, o in effetti quello che faccio se la mia nuova funzionalità è davvero pronta, è usare 'git cvsexportcommit' per portare il mio lavoro nel repository CVS esistente.

Due dei grandi vantaggi del controllo delle versioni sono che consente agli sviluppatori di ripristinare le versioni precedenti del loro lavoro e consente agli sviluppatori di provare contemporaneamente modifiche diverse, forse in conflitto. Il controllo della versione offre agli sviluppatori la libertà di provare idee che potrebbero fallire.

Gli sviluppatori dovrebbero essere incoraggiati a diramare e impegnare il proprio lavoro regolarmente, sia che si sviluppi o meno. Rifiutare di consentire ramificazioni o impegni non funzionanti significa ostacolare i tuoi sviluppatori e fare uno scarso uso dei tuoi strumenti.

Detto questo, è una pratica eccellente richiedere che si impegni sempre in determinati rami. Molte organizzazioni vanno oltre e vietano agli sviluppatori di impegnarsi in determinate filiali. Ad esempio, agli sviluppatori potrebbe essere richiesto di ricollegare il loro lavoro al ramo di sviluppo principale, ma solo allo sviluppatore principale potrebbe essere consentito unire tali modifiche dallo sviluppo al ramo di produzione.

Generalmente seguiamo entrambi gli approcci. Nel repository locale sulla mia scatola, commetto tutto ciò che voglio. Quando è il momento di spingere nel repository centrale del mio team, prima faccio un rebase interattivo e modifico i miei commit in pacchetti logici. In genere un commit per storia, con l'ID storia (o difetto) incluso nel commento (siamo un negozio basato su kanban).

Quindi nella nostra riproduzione centrale abbiamo Jenkins che ascolta e dà il via alla build e a tutti i test. Se qualcosa non riesce, generalmente consentiamo alle persone di provare a ottenere la build corretta con un altro commit. Se non ha un bell'aspetto, è facile ripristinare il commit errato.

Poiché git commitinfluisce solo sulla propria copia del repository, non è necessario che il progetto sia in uno stato operativo dopo ogni commit. Vai avanti e impegnati ogni volta che vuoi salvare il lavoro svolto. Probabilmente una buona regola empirica è che un commit è appropriato quando puoi descrivere le modifiche che hai fatto nel messaggio di commit.

È git pushquello che colpisce altri utenti. Le politiche per ciò che dovrebbe essere spinto sono una decisione del team di sviluppo. Spingere il codice non funzionante sul ramo principale è presumibilmente un no-no, ma probabilmente va bene spingere il codice non funzionante su un ramo separato (purché nessun altro proverà a fare un build da quel ramo).

Stiamo usando git flow al lavoro e commettiamo anche codice incompiuto o non funzionante, poiché atterra solo in filiali locali o remote create per quel problema specifico. Solo una volta terminata, l'attività viene unita nel ramo di sviluppo (che rappresenta la copia di lavoro corrente nel modello di flusso). In questo modo, possiamo anche collaborare al codice (alcuni colleghi sono in un'altra città, incluso il responsabile del progetto) e aiutarci a vicenda.

Tuttavia, dipende da come tu e i tuoi colleghi state pensando. Personalmente, penso che i commit delle filiali siano a posto, dato che potresti aver bisogno di una storia di cambiamenti con un refactor più grande o simile.

In definitiva dipende da te e dalle persone con cui lavori o per, dal momento che git non impone alcuna regola.

La mia pratica è quella di evitare qualsiasi impegno che intenzionalmente peggiori significativamente il sistema. Ogni commit dovrebbe essere refactoring o implementare alcuni requisiti. Se commetto un errore e lo scopro prima di inviarlo, lo modificherò o rifarò per rimuoverlo dalla cronologia.

Penso che ciò renda più semplice la lettura del log git in una richiesta pull, poiché ogni commit dovrebbe essere autonomo come refactoring o implementazione di alcuni requisiti. L'aggiunta di codice morto che prenderà vita nel prossimo futuro conta come refactoring. Questi sono i miei "pezzi logici".

Puoi ancora essere flessibile con il modo in cui strutturi i tuoi commit. Ad esempio, è possibile scrivere i test in anticipo, ma contrassegnarli tutti come ignorati nel primo commit, in modo che la suite di test non riporti un errore e quindi annullarli al termine dell'implementazione.

Supponendo che tu stia usando filiali e buoni messaggi di commit, commetti codice "rotto" su una filiale con un messaggio di commit che chiarisca che andrà bene, a patto che il tuo team accetti che sia una buona pratica lavorativa.

Clonate anche il repository git localmente, quindi potreste semplicemente avere una filiale locale con commit locali non trasferiti all'origine dove state commettendo codice "rotto" mentre procedete; quindi, quando tutto funziona, puoi unirlo a master o qualche altro ramo ed eliminare il tuo ramo di lavoro con i vari commit "rotti".

Per me, si tratta di concordare con la tua squadra ciò che è accettabile; alcuni team non accetteranno il codice rotto anche su una filiale, altri lo faranno.