Feature branches slow me down, but not with merge conflicts

OssiDev - Apr 1 '22 - - Dev Community

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?

. . . . .
Terabox Video Player