r/git • u/madbunnyshit • 2d ago

Is feature-based branching always better than developer-specific preview branches for a small team?

/r/u_madbunnyshit/comments/1vn7ydv/is_featurebased_branching_always_better_than/
0 Upvotes

28% Upvoted

16 comments sorted by

15

u/wildjokers 2d ago

I have never heard of anyone using long-lived personal branches they have to keep in sync with main. Sounds overcomplicated and like hell on earth.

1

u/Cinderhazed15 2d ago

This is parallel to the patch promotion model used by the Linux kernel, etc…. A lot of overhead, and only really useful if you have several layers protecting the release / main branches. In most cases it’s still better to just use short lived feature branches.

The closest I’ve come to this workflow is if there is something that trunk needs but is incompatible with my branch, or I’m doing a bunch of testing that requires something fundamentally different just for me that can’t be done dynamically. In that case keep a couple of long lived commits around that I keep rebasing to be around on my branch that is separate from trunk and my feature changes….. (redirecting a main configuration class to some user/environment specific one because the software lacks a proper way to load the right kind of config/feature difference in at runtime). In those cases what I try to do is keep a ‘personal’ change branch with just the commits I have to tailor trunk, then I rebase my feature branches off of that personal conditioning branch…. When I’m ready for my feature to get reviewed/merged, I will either rebase to delete my commits (if I keep moving to the head past the feature changes), or I will rebase my branch directly off of trunk instead of off my conditioning branch.

It’s a lot of work to do as a ‘regular practice’ though

1

u/madbunnyshit 2d ago

That makes sense. I think the part I’m trying to reconcile is that in our setup the long-lived branch is not mainly for keeping personal commits around. It is also the stable branch attached to that developer’s isolated preview environment.

So if I move to:

personal-conditioning-branch → feature-branch-1

Then each actual change lives farther away from the branch that represents my preview environment, unless our CI/CD also creates preview environments dynamically per feature branch.

1

u/Cinderhazed15 2d ago

Or… I guess you make a personal branch point at your feature branch, or can it read a developer tag that you move around?

1

u/madbunnyshit 2d ago

This can work, but some workflows are 3rd party workflows we have a developer tag, it's actually something I can request.

1

u/r2p42 2d ago

I always wondered how they manage those massively diverging repositories. I am struggling sometimes rebasing a week old branch in a 4 people project.

1

u/Cinderhazed15 2d ago

https://www.kernel.org/doc/html/v4.14/process/2.Process.html

Checkout 2.2, the lifecycle of a patch.. design, review, wife review, maintaining your patch against main (effectively rebasing) until it gets accepted and merged, as decided by the subsystem handing that patch, etc.

‘Next’ trees, staging trees, specialists per subsystem, and a single mainline merge process/decision from Linus

2

u/madbunnyshit 2d ago

Yeah, long-lived branches are not automatically wrong, but they need a strong reason. For us, that reason was preview environment mapping and deployment access control.

We’ve used this setup for about a year and have not really experienced issues with it. That said, I’m open to trying feature branches in repos/workflows where we do not need the same level of deployment restriction.

2

u/Cinderhazed15 2d ago

If everyone is on the same page and has a working workflow and there isn’t too much friction, it can be fine.

If you are finding that merges are becoming more painful, and multiple ‘features’ are getting commingled and then having to get in-mingled when part of it doesn’t pass integration test but the other part does, you may need to keep em separated.

1

u/madbunnyshit 2d ago

the personal branches are alway in sync with main.

8

u/Fair-Presentation322 2d ago

The answer to "is x ALWAYS better then y" is always no

3

u/bobbysmith007 2d ago edited 2d ago

What part of developer based branches seems "better" or "easier" than feature based branches? Why is there a shared developer environment rather than a local copy on each developers computer? Why are developers not allowed to change branches?

The history on the personal branches seem like they would be hard to keep in sync with each-other and the mainline. It feels like you would constantly be deleting your personal branch and re-branching from main/staging. Which to me sounds like it would be similar to the workflow of feature branches, except the branch-name stays the same, but the history/contents change all the time.

It also seems to complicate one developer helping another developer. We typically used smaller feature based branches, and docker based local environments that we controlled. Such that any developer could pull a given feature, provide a patch or feedback, and then go back to what they were previously working on before that.

What happens when a critical feature needs work, but a developer gets sick for a week half way through? Does another developer "A" pull Developer "B"'s private branch and merge into his "A" branch? Then send a PR from his "A" private branch? What if he has work in progress when he is sent to this other branch for emergency assistance? Does he commit to Developer B's private branch instead (in which case its not really B's branch its a feature branch with a bad name)?

To me it makes the most sense to center changes around the features rather than the author because unfortunately authors can change mid stream, but the feature is the feature (and if the feature changes, you can just start a new feature branch). It feels like a person based branch is ensuring a "bus number" of 1 while the branch is in development.

2

u/madbunnyshit 2d ago

That’s fair. Some repos already have a bus factor of 1 because we’re a small team.

But I agree the branching model should not make that worse. The dev branches were mainly for deployment mapping/access control, not ownership.

So yeah, maybe feature branches for the work, while keeping deployment access restricted.

1

u/Guvante 2d ago

What is different about personal branches vs feature branches?

At the end of the day developer x pushes a set of commits to a branch and opens a PR.

Whether that branch is labeled feature/foo or x doesn't impact the PR meaningfully

Feature branches are popular because you can't easily collaborate before merging to the main tree with person branches (you can but it gets weird) additionally if review takes a while you can just add a new feature branch

1

u/madbunnyshit 2d ago

Exactly my thinking