2

I've always considered long lived feature branches a symptom of some underlying problem, but I've recently moved jobs and the company I am working for now encourages long lived feature branches. They say it's fine as long as you merge master (well, the Dev branch, but whatever branch we all work off of) into the feature branch daily. They say you don't end up with conflicts that way or if you do they are small conflicts. I don't personally understand this, is there any truth behind the idea that the difficulties surrounding long lived feature branches can be negated by merging master into the branch frequently?

Edit: I'm going to try to clarify what I'm asking because I don't want it to be opinion based. I'm really looking for what issues we might run into by using long lived feature branches, regardless of whether we merge master in daily. I'm also interested in any issues that are avoided by the merging of master into the feature branch.

  • 2
    As long as you're working on the feature, it's not really a problem as it just adds a little bit of additional regular work to do. When there is a significant time between finishing a feature and merging it into master maybe because the powers-that-be can't make up their mind whether they really want it) you either need to merge after the master changed quite a bit, or you need to update the feature branch occasionally even though no one works on it anymore. – Hans-Martin Mosner Jul 10 at 8:23
  • I imagine your history looks like this: twitter.com/HenryHoffman/status/694184106440200192 – jonrsharpe Jul 10 at 9:19
  • After how much time do you consider a feature branch to be "long lived"? It makes quite a bit of difference if that is "1 week after creation" or "1 week after the last work on the feature". – Bart van Ingen Schenau Jul 11 at 8:29
2

Yes, this is true! But it also illustrates the problem of long-lived feature branches: you have to continue paying "rent" until you finally merge it, because you need to regularly merge master into the feature branch.

When you merge Git branches, you only need to unify the changes after the most recent common ancestor commit (called the merge base). When you regularly merge master into a feature branch, the merge base is the master commit that you previously merged into feature. So in the next merge, you will only have to deal with:

  • all the changes on feature since the branch started
  • all the changes on master since the last merge

but not: all the changes on master since the branch started. This is the crucial difference that makes merging back feasible.

Whether you merge or rebase the feature branch is irrelevant here and generally produces the same outcomes. However, rebasing doesn't create merge commits, which generally makes the Git history easier to handle.

When merging, there is also the question in which direction you merge the branch: merging master into feature will look backwards from the perspective of the master branch. Some people therefore update feature by merging in reverse: create a merge branch from master, merge feature into merge-branch, fast-forward feature to the merge commit, delete the merge-branch.

2

This will work only and only if: you only have 1 long-lived-feature-branch.

Let's take the following scenario: 3 developers all working on 3 different long-lived-feature-branches. Every day they merge develop into their branch.

And......achieve nothing, because develop will be the same as the day before, unless 1 of those long-lived-feature-branches gets merged into develop.

And then you will have merge conflicts the next day when you want to merge the now new develop into your still going long-lived-feature-branch.

1

As the other post already said, you constantly pay some cost. And things like refactoring can become very expensive.

But the real problem will hit you when you ever merge your branch into the main branch, because then the main branch _ will_ have a massive number of changes, and you will have massive numbers of conflicts with other branches.

1

Probably not.

Frequently merging mainline into your long-lived feature branch ensures you're not building up big conflicts with mainline, but if there is a second long-lived feature branch being developed in paralel that touches the same part of the codebase then you can build up conflicts between the two.

Whichever branch is merged into mainline first will have no problem with the merge, but the other branch will have to deal with the conflicts, which may prevent automatic merging. You can read about this 'merge ambush' issue in Neal Ford's 'How CI removes the pain'.

Even worse, the conflicts might be 'semantic merge conflicts', where your version control system will perform the merge automatically, but in doing so it will create a version of the product that doesn't run or produces wrong results, even though each parent of the merge is good by itself.

In any case preventing difficult merge conflicts is only one of the reasons for avoiding long-lived feature branches and prefering Trunk Based Development (TBD). TBD is also good for getting fast feedback from the whole team on your work.

  • Now this is exactly what I've always believed, and I've always done trunk based development for exactly these reason but plainly feature branches are working for people as the other answers suggest and the enthusiasm from the rest of my current team. – Jamie Twells Jul 10 at 10:53
  • It's a very contentious issue. This is a great twitter thread on that: twitter.com/jezhumble/status/982988915740168192 – bdsl Jul 10 at 11:00

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.