Quando impegnarsi a lavorare in git?

Quando si lavora localmente commit quando:

• Aggiungi un nuovo test case.
• I tuoi test passano.
• Hai apportato qualsiasi modifica che funzioni, non importa quanto insignificante.
  • Rinominato una variabile? Impegnalo.
  • Ha estratto un metodo? Impegnalo.
  • Invertito una condizione? Impegnalo.
• Fondamentalmente, ogni volta che il codice viene compilato.

Quindi, prima di inviarlo a un repository condiviso, schiaccia i commit in un unico, cambiamento di lavoro.

I vantaggi qui sono che hai una cronologia completa di ogni cambiamento che hai fatto mentre lavoravi su qualsiasi funzione / correzione di bug su cui stai lavorando. Se ti ritrovi 3/4 fatto e ti rendi conto che devi tornare al punto in cui eri 1/4 lungo la strada, va bene perché puoi . Schiacciare prima di condividere il codice garantisce che ogni commit nel repository condiviso rappresenti un codice funzionante. Chiunque può effettuare il checkout di un dato commit e avere ancora un codice funzionante. È bello avere una cronologia pulita quando SHTF e qualcuno deve tornare.

Un principio di Git è commetti presto, commetti spesso .

Vuoi impegnarti ogni volta che fai progressi tangibili, non sei sicuro di pentirti di perdere improvvisamente.

Se ritieni che questo comporti nella tua cronologia git di finire con troppi commit senza senso con messaggi di commit vaghi, puoi schiacciare questi commit in uno prima di inviarli al ramo principale usando git rebase .

This is why I have started to commit at the end of the work on the component I'm working on. This means I could do changes without the head-ache of correcting previous commit.

Secondo me, questo può essere un grosso errore se lavori in una squadra. È un errore particolarmente grande quando si lavora part-time sull'attività A, part-time sull'attività B, part-time sull'attività C, ecc. (La mia vita), mentre il resto della squadra sta bruciando. È probabile che si ottengano conflitti a bizzeffe nel tentativo di unire il proprio lavoro nel progetto generale se si attende qualche settimana o più per assicurarsi che il codice funzioni perfettamente. (A parte: il tuo codice non è mai perfetto.)

È molto meglio effettuare il commit localmente con estrema frequenza e unire più spesso il lavoro più grande nel ramo. In un progetto in rapido movimento, mi impegno più volte al giorno e mi unisco una volta al giorno, minimo. Frequenti fusioni significano che puoi parlare con la persona che ha scritto il codice che ha violato il tuo codice e forse raggiungere un accordo. Le fusioni poco frequenti significano che quelle modifiche che hanno infranto il tuo codice sono molto probabilmente bloccate nella pietra.

Il mio primo commit relativo ad alcune attività è in genere uno pseudo-codice che compila (lo pseudo-codice è quasi tutti i commenti) ma che fallisce ogni test. Quando lascerò il progetto A per lavorare sul progetto B, mi impegnerò e mi unirò. Quando torno al progetto A, la prima cosa che faccio è tirare il ramo di sviluppo nel mio repository locale e poi unirlo nel mio branch di funzionalità. Di conseguenza, vedo raramente conflitti.

A lot of code means a lot of bugs.

Questo non è necessariamente vero. Quel che è vero è che un sacco di codice non testato, non revisionato e scritto male significa molti bug. Potrebbe andar bene se quello che stai scrivendo è codice in cui gli errori non hanno un costo molto alto (ma ciò significa anche che non ha molto valore). Se stai scrivendo software in cui gli errori possono costare milioni di dollari o anche peggio possono uccidere, semplicemente non vuoi farlo. Ci sono tecniche, alcune vecchie, altre molto nuove, che permettono di scrivere un codice che è in gran parte privo di errori.