I recently did the mistake of working on a long lived feature branch that was active for over a week. I try to avoid this as much as possible, but sometimes I slip. The branch got a bit big and that in itself slows the review process down because some developers are either afraid, or don't want to commit their time, into reviewing it.
I've never had major issues with merge conflicts when using feature branches. Typically the teams I've worked on, even in big monolithic systems, have their work segregated so we don't really work on the same files and have these kinds of issues. If we do, resolving those issues is rather easy. What is an issue however, is that now I have to continue working with that specific feature, and I need the original branch as a base to continue, and it's sitting on the PR queue. I adjusted my ways of working through our retrospective, and split my stories so small that I can complete those tasks through short lived feature branches (customer's teams don't do trunk based development), but I can't start until that base branch is merged into the development branch. Otherwise I'd have to create a new branch from the base, and then wait until it's merged so I can open another PR and so on. It might be in the queue for days.
Have you experienced this issue and how did you manage it?
Top comments (2)
If you work with feature branches, are these kept, after delevopment for certain tasks has been finished?
You could always create new branches for working on tasks and merge after these have been finished.
I mean, I am completely biased as I work for LaunchDarkly, but this one of the core use cases for feature flags and LaunchDarkly. Rather than have a long living feature branch, the code gets merged back into main but sits behind a flag, so you and others you choose can test it in a test environment (or even in prod) but the rest of the world cannot see it. This avoids the long living feature branch and the merge conflicts and makes for a better, more flexible testing environment.