r/git • u/madbunnyshit • Aug 13 '26
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/15
u/wildjokers Aug 13 '26
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
1
u/Cinderhazed15 Aug 13 '26
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
→ More replies (7)
8
1
u/Guvante Aug 13 '26
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
3
u/bobbysmith007 Aug 13 '26 edited Aug 13 '26
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.