Is using “feature branches” compatible with refactoring?

feature branches is when each feature is developed in its own branch and only merged into the main line when it has been tested and is ready to ship. This allows the product owner to choose the features that go into a given shipment and to “park” feature that are part written if more important work comes in (e.g. a customer phones up the MD to complain).

refactoring is transforming the code to improve its design so as to reduce to cost of change. Without doing this continually you tend to get uglier code bases which is more difficult to write tests for.

  • Git squash commits with merged branch
  • Git: set the tip of a branch to a particular commit
  • How do I create a new git branch from the changes I have in the working tree?
  • What is a good repository layout for releases and projects in Subversion?
  • In git, is there a simple way of introducing an unrelated branch to a repository?
  • How do you get the git branch name for a given shasum?
  • In real life there are always customers that have been sold new features and due to politics all the customers have to see that progress is being made on “their” group of features. So it is very rarely that there is a time without a lot of half-finished features sitting on branches.

    If any refactoring has been done, the merging in the “feature branches” become a lot harder if not impossible.

    Do we just have to give up on being able to do any refactoring?

    See also “How do you handle the tension between refactoring and the need for merging?”

  • Make unable to branch merge
  • How to perform merge?
  • Git: How to merge local branch with remote tracking automatically without fetching
  • How to update my working Git branch from another branch (develop) ?
  • How does one work on a new git branch that depends on another git branch that is not yet merged?
  • Git - switching between branches in the middle of work
  • 4 Solutions collect form web for “Is using “feature branches” compatible with refactoring?”

    Feature branches certainly make refactoring much harder. They also make things like continuous integration and deployment harder, because you are ballooning the number of parallel development streams that need to be built an tested. You are also obviating the central tenet of “continuous integration” — that everyone is working on the same codebase and “continuously” integrating their changes with the rest of the team’s changes. Typically, when feature branches are in use, the feature branch isn’t continuously built or tested, so the first time the “feature branch” code gets run through the production build/test/deploy process is when it is “done” and merged into the trunk. This can introduce a whole host of problems at a late and critical stage of your development process.

    I hold the controversial opinion that you should avoid feature branches at (nearly) all costs. The cost of merging is very high, and (perhaps more importantly) the opportunity cost of failing to “continuously integrate” into a shared code base is even higher.

    In your scenario, are you sure you need a separate feature branch for each client’s feature(s)? Could you instead develop those features in the trunk but leave them disabled until they are ready?. Generally, I think it is better to develop “features” this way — check them in to trunk even if they aren’t production-ready, but leave them out of the application until they are ready. This practice also encourages you to keep your components well-factored and shielded behind well-designed interfaces. The “feature branch” approach gives you the excuse to make sweeping changes across the code base to implement the new feature.

    I like this provoking thesis (‘giving up refactoring’), because it enriches discussion 🙂

    I agree that you have to be very careful with bigger refactoring when having lots of parallel codelines, because conflicts can increase integration work a lot and even cause introducing regression-bugs during merging.

    Because of this with refactoring vs. feature-branches problem, there are lots of tradeoffs. Therefore I decide on a case by case basis:

    • On feature-branches I only do refactorings if they prepare my feature to be easier to implement. I always try to focus on the feature only. Branches should differ from trunk/mainline at least as possible.
    • Taking it reverse I sometimes even have refactoring branches, where I do bigger refactorings (reverting multiple steps is very easy and I don’t distract my trunk colleagues). Of course I will tell my team, that I am doing this refactoring and try to plan to do it during a clean-up development cycle (call it sprint if you like).
    • If your mentioned politics are a big thing, then I would encapsulate the refactoring efforts internally and add it to estimation. In my view customers in middle-terms will see faster progress when having better code-quality. Most likely the won’t understand refactoring (which makes sense, because this out of their scope…), so I hide this from them
    • What I would never do is to refactor on a release-branch, whose target is stability. Only bug-fixes are allowed there.

    As summary I would plan my refactorings depending on codeline:

    • feature-branch: only smaller ones (if they “help” my feature)
    • refactoring-branch: for bigger ones, where the refactoring target isn’t completely clear (I often call them “scribble refactorings”)
    • trunk/mainline: OK, but I have to communicate with developers on feature-branches to not create an integration nightmare.
    • release-branch: never ever

    Refactoring and merging are the two combined topics Plastic SCM focuses on. In fact there are two important areas to focus: one is dealing (during merge) with files that have been moved or renamed on a branch. The good news here is that all the “new age” SCMs will let you do that correctly (Plastic, Git, Hg) while the old ones simply fail (SVN, Perforce and the even older ones).

    The other part is dealing with refactored code inside the same file: you know, you move your code and other developer modifies it in parallel. It is a harder problem but we do focus on it too with the new merge/diff toolset. Find the xdiff info here and the xmerge (cross-merging) here. A good discussion about how to find moved code here (compared to “beyond compare”).

    While the “directory merging” or structure merging issue is a core one (whether the system does it or not), the second one is more a tooling problem (how good your three-way merge and diff tools are). You can have Git and Hg for free to solve the first problem (and even Plastic SCM is now free too).

    Part of the problem is that most merge tools are just too stupid to understand any refactoring. A simple rename of a method should be merged as a rename of the method, not as an edit to 101 lines of code. Therefore for example additional calls to the method in anther branch should be cope with automatically.

    There are now some better merge tools (for example SemanticMerge) that are based on language parsing, designed to deal with code that has been moved and modified. JetBrains (the create of ReShaper) has just posted a blog on this.

    There has been lots of research on this over the years, at last some products are coming to market.

    Git Baby is a git and github fan, let's start git clone.