I recently started working with GitFlow model as implemented by bitbucket. And there is one thing that is not completely clear to me.

We try to regularly address our technical debt by backlogging, planning, and implementing the refactoring tasks. Such refactoring branches end with pull-requests that are merged in develop. My question is where do the refactoring branches belong in GitFlow?

  • Using feature prefix seems the most logical, however it does not feel entirely right, because refactoring does not add any new functionality.
  • However using bugfix prefix seems not right as well as there is no actual bug refactoring fixes.
  • Creating a custom prefix on the other hand seems like complicating if not over-engineering the things.

Did you have such situation? Which practice do you use to address this? Please explain why.

  • Why do you need a branch for refactors at all? They don't alter the functionality of the product by definition, so you should be able to do them directly in develop.
    – jonrsharpe
    Jan 12, 2017 at 9:56
  • @jonrsharpe in short, it is more convenient and controllable. There is usually a Jira ticket for the refactoring and it is also code-reviewed during the pull request. In addition builds and tests are run for it, before it is merged. We try to keep develop branch green.
    – AMA
    Jan 12, 2017 at 10:03
  • 4
    You're over-engineering things - in this case, the process. Refactor as you as work on the system, not as a discrete work package.
    – Mr Cochese
    Jan 12, 2017 at 10:08
  • 2
    In that case: 1. You have my sympathies; and 2. I'd say use refactor, then it's clear what transform each merge is expected to do to the product (bugfix: fix broken behaviour, feature: add new behaviour, refactor: retain previous behaviour). But @MrCochese is right, it should really be a part of the other work you're doing not a separate task. Note also that if your refactors break the build, they aren't refactors!
    – jonrsharpe
    Jan 12, 2017 at 10:08
  • Some of the refactoring work you're doing should really be part of the main work proper. I certainly wouldn't make refactor branches routinely, but only as part of a larger cleanup effort. Making this a habit will encourage other bad habits, such as deferring cleanup work to the "refactor" branch. Jan 12, 2017 at 14:41

1 Answer 1


Refactoring work should go in a feature branch.

The prefix "feature" is just a word to describe a discrete programming task, you could choose any word you like, any branch from development is either a "feature" branch or a "release" branch

Adding a new prefix such as "refactoring" is problematic. As you will often do some refactoring when adding a feature, you are simply giving yourself a naming problem and adding confusion. ie. "some of our feature branches are called 'refactoring', no they don't contain all the refactoring work and sometimes they have bug fixes or features in them'

similarly "hotfix" branches are not called hotfix because they contain hotfixes, but because they branch from master rather than develop

  • 2
    thank you. This sounds reasonable. I will wait a bit more, and if there are no other answers, I will accept yours.
    – AMA
    Jan 13, 2017 at 11:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.