this post was submitted on 18 Jul 2026
82 points (100.0% liked)
Programming
27817 readers
265 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
TIL git history.
That said, I'm trying to figure out what the target workflow is, specifically for the "autorebases all your branches to match" functionality. Assuming we are not talking about rewriting published history -- and nobody should ever really be doing that anyway, when multiple commiters are using the same branch -- I presume this is a situation where the dev has multiple, unpushed features that are WIP, each in their own local branch and building on each other. The trouble I'm having is the number of commits per feature.
If the number of commits per feature is 1, then that means each branch just has one commit that its dependent branch doesn't have. What is the point of the branch then? Just have a single WIP branch and keep building a linear commit history. If you need to give someone one of the features, then give them the commit which inplemtns that feature and nothing afterwards.
If the number of commits per feature is >1, then this is certainly more difficult to work with, and the appeal of git history starts to shine when dealing with WIP commirs. But why is the dev in this situation, where they're building multiple dependent features but they're none are fully complete yet? Because if they were complete, then I presume the dev should squash the commits so the number of commits per completes feature is 1.
My current thought is that having >1 commits to implement a single feature is a transient condition, and good practice is to get to 1 commit per feature. Is there something I'm missing?
Yep. There are also situations where rewriting history on branches under review is ok and desired - systems like gerrit work that way. But not github (you can push to an own work-in-progress branch on github, or even push to a branch with a merge request, but the github ui is not designed to review that).
Especially large organizations favour history that is easier to read and mostly linear. This is not needed for a mom and pop web project of a company with three developers.
In respect to the number of commits per feature - one commit per feature can be good. But often changes can be compartmentalized in doing preparatory refactoring, adding the feature, adding tests, and his can be easier to review because the scope of each commit is smaller.
This is the use-case I hadn't considered. And it makes sense now that I think of it. Though I personally haven't come across it, since I don't typically work on multiple, cascaded features at a time. Most of my work as been with waterfall models, so I can understand that other approaches may indeed have cascading features in parallel.
Thanks!
You are welcome!