953
we did a little bit of branch fuckery
(lemmy.dbzer0.com)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 09 Oct 2025
953 points (99.5% liked)
Programmer Humor
27224 readers
1452 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 2 years ago
MODERATORS
in the projects i work in i always try to force semi linear history to avoid all of this, never merge (unless it's the MR) always rebase.
this leaves a very readable history, with each feature branch highlighted and no mixture in the commits...
i haven't found any downside yet... maybe that some ci/cd are built to push to main, but making them do branch pr automerge is not that difficult
How does a rebase play out? I know what it is conceptually, but usually just do the difficult merges myself
A rebase rewrites the history of your branch, so that it's as if you just branched off and then coded all your changes in one sitting.
It will go through each of your commits and try to apply them one after another. If something changed on the base branch that conflicts with your changes, it will prompt you to adjust your commit. You adjust it so that looks as if you just coded it on top of the base branch.
When you have lots of commits on your branch, this can mean that while you're rebasing, you have to then also change your following commits which happened to touch the same lines as a previous commit. This can mean additional, stupid work.
As such, a workflow using rebases ("trunk-based workflow") works best, if you can rebase often and merge back early. You won't get merge conflicts when merging back, nor merge commits, because you resolved these while rebasing.
In particular in smaller teams where you have tight-knit communication, this workflow is absolutely stellar. It completely bypasses so many pain points that folks have with Git.
Merge conflicts are significantly reduced when you merge often and a trunk-based workflow removes the ceremony that typically prevents teams from doing just that.