Can long lived feature branches be justified by merging master into the feature branch daily

Question

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.

Answer 1

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.

Answer 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.

Answer 3

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.

Answer 4

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.