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

Di solito seguo questa regola:

• Ogni unione a master ramo deve lasciare il progetto in uno stato funzionante;
• Ogni unione per il mainline develop branch dovrebbe lasciare il progetto in uno stato funzionante (e deve creare almeno);
• Ogni altro commit individuo ha l'obiettivo principale di spiegare perché viene apportata la modifica, a cosa serve ea quali parti del progetto ha interessato. Tutti gli altri obiettivi, come lasciare il progetto in uno stato operativo, sono facoltativi.

Usa il tuo clone locale del repository per qualsiasi cosa ti renda constrongvole durante lo sviluppo.

Eseguo regolarmente il codice non corretto e quando sono pronto a rendere il codice disponibile ad 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), possibilmente interrotto, si impegna in un buon commit. Ti verrà presentato un editor che ti consentirà di scegliere in che modo vengono compressi quei commit. In genere ho segnato il primo commit del commit "pick" e contrassegno gli altri "squash".

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

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

Gli sviluppatori dovrebbero essere incoraggiati a ramificarsi e ad impegnarsi regolarmente, indipendentemente dal fatto che si sviluppi o meno. Rifiutare il permesso di ramificare o commettere errori è ostacolare i tuoi sviluppatori e fare un cattivo uso dei tuoi strumenti.

Detto questo, è una pratica eccellente richiedere che i commit su determinati rami vengano sempre creati. Molte organizzazioni si spingono oltre e proibiscono agli sviluppatori di impegnarsi in determinate filiali. Ad esempio, potrebbe essere necessario che gli sviluppatori uniscano 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.

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

Poi, nella nostra riproduzione centrale, ascoltiamo Jenkins e inizia la build e tutti i test. Se qualcosa non funziona, generalmente permettiamo alle persone di provare a ottenere la build corretta con un altro commit. Se non sembra buono, ripristinare il commit errato è facile.

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

È git push che colpisce gli altri utenti. Le politiche per ciò che dovrebbe essere spinto sono una questione che il team di sviluppo deve decidere. Spingere codice non funzionante sul ramo principale è presumibilmente un no-no, ma probabilmente è ok per spingere codice non funzionante su un ramo separato (a patto che nessun altro proverà a fare una build da quel ramo).

Stiamo utilizzando git flow sul posto di lavoro, e commettiamo anche incompiute o codice non funzionante - poiché si trova solo in rami locali o remoti creati per quel problema specifico. Solo una volta che l'attività è terminata, viene unita al 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 stanno pensando te e i tuoi colleghi. Personalmente, ritengo che i commit delle filiali siano a posto, in quanto potresti aver bisogno di una cronologia delle modifiche con un refactoring più grande o simile.

In fin dei conti tocca a te e alle persone con cui lavori o per, dato che git non impone alcuna regola.

La mia pratica è di evitare qualsiasi commit che faccia intenzionalmente peggiorare il sistema in modo significativo. Ogni commit dovrebbe o essere refactoring o implementare alcuni requisiti. Se eseguo un commit errato e lo scopro prima di inviarlo, correggo o rebase per rimuoverlo dalla cronologia.

Penso che sia più facile leggere il log git in una richiesta pull, dato che ogni commit dovrebbe essere indipendente come refactoring o implementazione di alcuni requisiti. L'aggiunta di un codice morto che verrà portato alla vita nel prossimo futuro conta come un refactoring. Questi sono i miei "pezzi logici".

Puoi comunque essere flessibile nel modo in cui strutturi i tuoi commit. Ad esempio, puoi scrivere i test in anticipo, ma contrassegnarli tutti come saltati nel primo commit, in modo che la tua suite di test non riporti un errore, quindi deselezionarli quando l'implementazione è completata.

Supponendo che si stiano utilizzando filiali e buoni messaggi di commit, l'inserimento di un codice "rotto" su un ramo con un messaggio di commit che lo rende chiaro andrebbe bene, purché il tuo team sia d'accordo che si tratti di un buon esercizio.

Inoltre clonate localmente il repository git, quindi potreste semplicemente avere un ramo locale con commit locali non spinto all'origine dove state commettendo codice "spezzato" mentre procedete; quindi, quando tutto funziona, puoi unirlo al master o ad un altro ramo ed eliminare il tuo ramo di lavoro con i vari commit "interrotti".

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