Di recente ho iniziato a lavorare con il modello GitFlow implementato da bitbucket. E c'è una cosa che non mi è completamente chiara.
Cerchiamo di affrontare regolarmente il nostro debito tecnico mediante backlog, pianificazione e implementazione delle attività di refactoring. Tali filiali di refactoring terminano con richieste pull che vengono unite develop. La mia domanda è: dove appartengono i rami del refactoring in GitFlow ?
- L'uso del
featureprefisso sembra il più logico, tuttavia non sembra del tutto corretto, poiché il refactoring non aggiunge alcuna nuova funzionalità. - Tuttavia, l'utilizzo del
bugfixprefisso non sembra corretto in quanto non esistono correzioni di refactoring dei bug effettive . - La creazione di un prefisso personalizzato, d'altra parte, sembra complicare se non sovraccaricare le cose.
Hai avuto una situazione del genere? Quale pratica usi per affrontare questo? Per favore, spiega perché.
Perché hai bisogno di una filiale per i refactor? Non alterano la funzionalità del prodotto per definizione, quindi dovresti essere in grado di farlo direttamente in fase di sviluppo.
—
jonrsharpe,
@jonrsharpe in breve, è più conveniente e controllabile. Di solito c'è un biglietto Jira per il refactoring ed è anche revisionato durante la richiesta pull. Inoltre, build e test vengono eseguiti per esso, prima che venga unito. Cerchiamo di mantenere lo sviluppo del ramo verde.
—
AMA,
Stai ingegnerizzando troppo le cose - in questo caso, il processo. Rifattorizza mentre lavori sul sistema, non come un pacchetto di lavoro discreto.
—
Sig. Cochese,
In tal caso: 1. Hai le mie simpatie; e 2. Direi uso
—
jonrsharpe,
refactor, quindi è chiaro quale trasformazione ci si aspetta da ogni unione per il prodotto (correzione di bug: correzione del comportamento non funzionante, funzionalità: aggiunta di un nuovo comportamento, rifattore: mantenimento del comportamento precedente). Ma @MrCochese ha ragione, dovrebbe davvero essere una parte dell'altro lavoro che stai facendo non un compito separato. Nota anche che se i tuoi refactors rompono la build, non sono refactor!
Alcuni dei lavori di refactoring che stai facendo dovrebbero davvero far parte del lavoro principale vero e proprio. Certamente non farei regolarmente i rami dei refattori , ma solo come parte di un più grande sforzo di pulizia. Rendere questa abitudine incoraggerà altre cattive abitudini, come rinviare il lavoro di pulizia al ramo "refactor".
—
Robert Harvey,