The mixed-revisions bug was fun… Also cannot clean history or make shitty branches everywhere, it was one of my worst experience. Nowadays Jujutsu is my favorite.
Comment on Yeah
dan@upvote.au 8 months ago
The bottom picture should be SVN. I miss incremental revision numbers.
6nk06@sh.itjust.works 8 months ago
original_reader@lemmy.zip 8 months ago
SVN is still great if there a need for strict access controls and central control matters a lot. Auditing is also a bit easier with SVN.
It caters more for a linear workflow, though. So modern large teams won’t find joy with SVN.
dan@upvote.au 8 months ago
modern large teams won’t find joy with SVN
For what it’s worth, I work at a FAANG company and (at least in the repo I work in) we don’t use branches at all. Instead, we use feature flags.
All code changes have to go though code review before they can be committed to the main repo. Pull requests are usually not too large (we aim for ~300-400 lines max), aren’t long-lived, can be stacked to handle dependencies between them (“stacked diffs”), and a whole stack can be landed together. When merged, everything is committed directly to the main branch, which all developers are working off of.
I know that both Google and Meta take this approach, and probably other companies too.
boonhet@sopuli.xyz 8 months ago
What’s the difference between that and feature branches? Sounds like you still have PRs that get merged to main from somewhere - forked repos I guess?
dan@upvote.au 8 months ago
Usually, feature branches mean that all the work to implement a particular feature is done on that branch. That could be weeks of work from several developers. The code isn’t merged until the feature is complete. It’s more common in the industry compared to trunk-based development.
My previous employer had:
- Feature branches for each new feature.
- A dev branch, where new features were merged once they were done.
- A beta branch, branched from dev once per week.
- A live/prod branch, branched from beta four times per year.
This structure is very common in enterprise apps. Customers that need stability (don’t want things to change a lot, for example if they have their own training material for their staff) use the live branch, while customers that want the newest features use the beta branch.
Bug fixes were annoying since you’d have to first do them in the live branch then port them to the beta and dev branches (or vice versa).
original_reader@lemmy.zip 8 months ago
This makes me happy. 🙂
deadbeef79000@lemmy.nz 8 months ago
Trunk based dev is GOAT.
bananabread@lemmy.zip 8 months ago
git rev-list HEAD | wc -l