Dovresti migliorare la qualità del codice mentre lavori su un ramo di caratteristiche

Dovresti solo "correggere" il codice in un ramo di funzione se stai modificando comunque quel pezzo di codice come parte della funzione.

Eg. Sto lavorando alla funzione 'print rabbits' e trovo il codice della stampante

Public class Printer(string type)
{
    If(type=="bunnies")
    {
        //print a bunny
    }
.....
}

Lo cambio in:

Public class Printer(string type)
{
     PrintFunctionDictionary[type].Print();
}

Perché:

• Sto lavorando al codice,
• Devo cambiarlo per aggiungere funzionalità,
• la funzionalità aggiunta suggerisce un modo refactored di affrontare il problema.

Non casualmente colpisco qualche altra parte della base di codice e "renderla migliore" in questo modo:

• Scontrati con persone che lavorano su altre funzioni.
• Utilizza il tempo che dovrebbe essere assegnato allo sviluppo della funzione.
• Aggiungi codice arbitrario a un ramo che, se la funzione non è terminata, non può essere unito al prodotto principale. Allo stesso modo, se ripristino la funzione, perdo il mio refactoring.

Se vuoi che i tuoi refactoring "vivano in modo indipendente" dal tuo attuale ramo delle funzionalità, non apportare le modifiche lì. Invece, esegui il refactoring sul ramo di sviluppo principale (o su un "ramo di refactoring", se è comune nella tua squadra non applicare le modifiche direttamente al ramo dev). Pertanto, chiunque del team (incluso te) può unire le modifiche ai rami delle funzioni attive su cui stanno lavorando. Tuttavia, fai attenzione a non applicare alcun refactoring globale su "metà della base del codice" senza chiedere prima il permesso ai tuoi colleghi - potrebbero non essere così felici se i tuoi refactoring interferiscono troppo con il loro attuale lavoro.

L'eccezione è qui quando i miglioramenti apportati sono locali alle parti della base di codice che tocchi esattamente in quel ramo di funzionalità, e non ha senso dar loro un ciclo di vita diverso dalla tua "nuova funzionalità".

Lo scopo dei tipi branch è di fornire intenzione per gestirli. Se stai seguendo uno stile di branching GitFlow, probabilmente hai tipi come feature , hotfix , release , ecc. Nel caso di un ramo di funzione, la sua intenzione è per incapsulare un'unione in un altro ramo (ad esempio develop ) che mostra lo sviluppatore responsabile della fusione, che cos'è questa funzionalità. Se il codice che stai pulendo non fa parte di quella funzione, non cambiarlo.

Trova invece il ramo più basso possibile in cui si trova il brutto codice (probabilmente develop ) e il ramo da lì. Cambia il codice e proponilo come una funzione. Se hai bisogno di quel codice su ciò su cui stai lavorando, e in particolare vuoi evitare conflitti di fusione, unisci quel ramo nel TUO ramo.

Ecco una spiegazione abbastanza buona delle diverse strategie: link

if I'm working on a feature branch, and I spot some ugly code, should I fix it?

Probabilmente è bello correggere "brutto codice" a vista, a seconda del tempo del progetto, della "bruttezza" del codice, ecc., ma cerca di non farlo sul ramo della funzione stessa.

• Se il tuo ramo di funzione è interamente locale, salva o salva le modifiche non salvate, controlla il ramo di sviluppo, apporta le modifiche, quindi torna al ramo delle funzionalità e disattiva lo sviluppo.
• Se non riesci a rebase dello sviluppo (ad esempio, il tuo ramo di funzione si trova su un server pubblico), puoi ancora selezionare i file che si impegnano a svilupparsi se ne hai bisogno o vuoi evitare conflitti in seguito.
• Se stai modificando un file e veramente devi impegnare la correzione sul brutto codice adesso e veramente non puoi passare allo sviluppo, puoi fare la correzione , usa git add -p per fare la correzione, commetti quel cambiamento solo e prima di unire / spingere (anzi, preferibilmente dopo il prossimo commit), usa rebase interattivo per spostare quel commit al punto più precoce possibile nel tuo ramo, o forse anche ciliegina sulla crescita, a seconda della tua storia.

Lo farei anche con qualsiasi altra cosa che 'fissa' il ramo di sviluppo (dove 'correzioni' sono modifiche che tu o qualsiasi altro sviluppatore potrebbero fare a vista per assicurarti che il codice aderisca agli standard). Questo aiuta ...

• per mantenere le tue correzioni e la tua funzionalità si impegna in diversi gruppi in modo che il registro sia più leggibile,
• per mantenere lo sviluppo il più vicino possibile all'essere rilasciabile in qualsiasi momento e
• per evitare la duplicazione del lavoro (più persone hanno risolto lo stesso problema in modi leggermente diversi su rami diversi).