What annoys me about this is that every branch ends up being "private" and people don't collaborate (In practice). So you end up with: "I can't start work on X until feature Y is merged, and there's a lot of PR comments left unaddressed so let's just merge Y since X is urgent and fix the PR comments later..."
If feature Y is incomplete, then sharing a feature branch (which sounds like a road to a messy commit history) doesn't change that. You could also use the unmerged feature branch Y temporarily as a base for X if you need some code from it.
People I know used to temp-merge multiple work in progress features into a so-called frankenbranch for testing purposes. It was broadly acknowledged to be a huge smell and reached for only as a last resort.
Most PRs happen against the main branch, maybe after a private feature branch, maybe not.
Meanwhile, major developments happen in a feature branch, and these are almost always owned by a single person who is responsible for rebasing against the main branch (and eventually merging back there).
But maybe our development team and pace are not good tests for this model.
Off topic, but thank you for having a perfectly modern and beautiful skeuomorphic GUI in Ardour. Tactile buttons with descriptive names instead of vague flat squares with incomprehensible icons; I wish more software offered this kind of interface.
> and these are almost always owned by a single person who is responsible for rebasing against the main branch
That still seems very annoying. People have unplanned time-off all the time, live in different timezones, or perhaps are l just busy ATM and can't do the rebase.
- Unplanned time off means the feature just doesn’t make it in
- Living in different time zones means that you just wait and work slows down
In either event, there is rebase and squash auto merge from major git providers like GitHub which helps with this a ton. With that enabled unless the repo is super high traffic usually this is an afterthought unless there is merge conflicts which is semi rare.
That being said, that’s just the reality of what I’ve seen play out in various organizations. I personally like to work off other people branches a lot more than my peers because I work in platform engineering and very often developers come to me with feature branches that need some CI/infra/other change or optimization and very often it’s easiest for me to just drop a commit into their existing branch. The change falls under their ownership and it gets mainlined along with their feature.
This can be mostly avoided with short-lived branches that are merged by the end of each day. If that isn't feasible, people can still collaborate on a feature branch as long as a single person is nominated to rebase it at the end.
My team ran into this early on when attempting to adopt a rebase-preferred workflow for feature branches...
...then we got used to it. A few workflow changes were necessary:
- configure pull.rebase=true. This is kinda just nice in general, but critical if someone might have rebased the branch you're working on overnight.
- get used to pushing up your changes regularly - at very least before you quit for the day.
- get used to pulling remote changes regularly - at very least before you start work on a branch each day. Rebase after pulling - especially important if you've branched off another feature branch (which may have been rebased). This way you avoid doing a bunch of work on an out of date base.
- *Talk to each other.* If it isn't already obvious what a collaborator is doing... Ask them! And err on the side of over communicating what you're doing.
It turns out, all of these behaviors are kinda just generally useful, and after a bit you forget about rebase being the motivation and just enjoy having a bit less friction when working together.
Do you think that works any better if you're using merges Vs rebasing though?
If the problem is that you urgently need some small fix in an otherwise broken branch, you can always just cherry-pick that across to your own fresh pr.
