54

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.

Improve this question
8
  • 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. Commented Jan 12, 2017 at 9:56
  • 1
    @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. Commented 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. Commented Jan 12, 2017 at 10:08
  • 3
    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! Commented Jan 12, 2017 at 10:08
  • 2
    @MrCochese Your advice is good as default guideline but falls prey to assuming that nothing ever drops off of the radar. It is well documented that codebases have a tendency to accrue technical debt over time. Cleaning as you go is ideal but I have yet to see anyone 100% guarantee that their on-the-go cleaning covers any and all tech debt that they may incur. Commented Sep 26, 2024 at 1:29

3 Answers 3

Reset to default
71

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

Improve this answer
2
  • 2
    thank you. This sounds reasonable. I will wait a bit more, and if there are no other answers, I will accept yours. Commented Jan 13, 2017 at 11:36
  • Good answer - I agree. Commented Oct 18, 2022 at 18:32
1

I'd say it depends on following cases:

  1. If maintaining the main branch, the correct place is hotfix/.
  2. If maintaining the release/ branch, the correct place is bugfix/.
  3. The best case scenario (and if possible) is to maintain refactoring candidates in the feature/ branch right away.

Keep in mind that the options 1. and 2. are real world scenarios and covered by the git flow strategy because of meeting release deadlines or saving costs (or better gaining profit in time or money). So I don't see any troubles in organizing that way since git flow updates main, develop and feature/ branches in order.

Comment: If you have never expirienced case 1 or 2 so far this might change if development goes on.

EDIT: 2025-01-21 10:45 Since I'm still convinced with my answer a further approach came into my mind. Why not refactoring the release-branch if there shall be a unique rule? According to the well known picture of nvie.com the release branch might be an accepted candidate for refactorings since it's also a place for bugfixes. The refactoring changes are going to develop and main branch which meets all criterias. Source: https://nvie.com/img/git-model@2x.png

Improve this answer
0

Sorry for Necro - but wanted to share that I have learned that minimizing "branch depth" is something that is integrated behavior introduced from programming logistics (reducing nesting/depth generally improves everything).

To answer this question specifically: /refactor exists across all branch structures.

In the case of Repository tracking this made things difficult - until accepting that there SHOULD be hanging feature branches, acting as default tags! This allow you to append individual work-item branches from these features. This behavior prevents your local working changes from becoming an overwhelming hodge-podge belonging to many branches; which makes everything else complicated - as you will have to deal with merge conflicts, stash/apply, or cherry-pick nightmare.

TLDR: Don't be afraid of branch-depth! This help narrow down changes to specific intents. If you are having trouble with branch-cycling, your concept of branch design is likely hurting you.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.