So che molti di voi consiglierebbero di seguire la strategia e la metodologia del progetto.
Tuttavia ho una domanda veloce, dal punto di vista senior, cosa sarebbe meglio vedere rapide piccole commit da uno sviluppatore, o una grossa porzione di codice inviata al ramo?
Non ha molta importanza per le dimensioni, ma il commit deve essere il più atomico possibile. Con ciò intendo che commit non deve rompere la build, dovrebbe risolvere un bug specifico, o aggiungere una caratteristica specifica ed essere indipendente da qualsiasi altro commit. Se una funzione richiede molto codice, beh, così sia. Ma di solito questa strategia produce naturalmente piccoli e frequenti commit.
Ci sono dei limiti, ma preferisco i piccoli commit atomici.
In primo luogo, semplifica le cose quando ci si riferisce al motivo per cui è stata apportata una modifica. In secondo luogo, riduce drasticamente il costo di un errore.
Due note di cautela però:
Se utilizzi un VCS centralizzato, esegui il commit solo quando il codice viene generato e test eseguito. (Se stai usando DVCS, sostituisci "commit" con "push".)
Non fare implicitamente riferimento a un commento di commit da un altro.
351: pdr: Stop foo from grommiting.
352: pdr: Ooops, got that wrong, let's try again.
353: dan: New launch page.
354: pdr: Third time lucky.
Quel genere di cose. Non farlo È molto allettante quando commetti spesso, perché ricordi il commit che hai fatto cinque minuti fa, e il commento inizia a sembrare una conversazione con te stesso. Ma controllati. Non ha senso per la persona povera, due anni nel tuo futuro, che fa una ricerca dell'ultimo commit su determinati file.
Leggi altre domande sui tag teamwork version-control