Dove si trova il refactoring nel modello di denominazione dei rami di GitFlow?

10

Recentemente 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 eseguendo backlogging, pianificando e implementando le attività di refactoring. Tali rami di refactoring terminano con richieste di pull che vengono unite in develop . La mia domanda è dove appartengono i rami di refactoring in GitFlow ?

  • L'uso del prefisso feature sembra il più logico, tuttavia non sembra del tutto corretto, perché il refactoring non aggiunge alcuna nuova funzionalità.
  • Tuttavia, l'uso del prefisso bugfix sembra non essere corretto così come non esistono correzioni di refactoring bug .
  • La creazione di un prefisso personalizzato dall'altra parte sembra complicare se non sovrascrivere le cose.

Hai avuto una situazione del genere? Quale pratica usi per affrontare questo? Per favore spiega perché.

    
posta AMA 12.01.2017 - 10:40
fonte

1 risposta

16

Il lavoro di refactoring dovrebbe andare in un ramo di funzionalità.

Il prefisso "funzione" è solo una parola per descrivere un'attività di programmazione discreta, puoi scegliere qualsiasi parola che ti piace, qualsiasi ramo da sviluppo è un ramo "funzione" o un ramo "rilascio"

L'aggiunta di un nuovo prefisso come "refactoring" è problematica. Dato che spesso esegui dei refactoring quando aggiungi una funzione, ti stai semplicemente dando un problema di denominazione e aggiungendo confusione. vale a dire. "alcuni dei nostri rami di funzionalità sono chiamati" refactoring ", no non contengono tutti i lavori di refactoring e talvolta hanno correzioni di bug o funzionalità in essi"

allo stesso modo i rami "hotfix" non vengono chiamati hotfix perché contengono hotfix, ma perché si diramano dal master piuttosto che svilupparsi

    
risposta data 12.01.2017 - 11:17
fonte

Leggi altre domande sui tag