cross-posted from: https://lemmy.sdf.org/post/1352760
Was digging through a project at work today where some guy in 2014 made 100+ commits in a single day and the only one that had a comment said “upgrading to v4.0”.
cross-posted from: https://lemmy.sdf.org/post/1352760
Was digging through a project at work today where some guy in 2014 made 100+ commits in a single day and the only one that had a comment said “upgrading to v4.0”.
The way I commit on my private branch is different than how I merge those commits to the main branch. When working on the private branch, things can get messy and if they do, I just try to keep certain things separate from each other (refactorings and bug fixes should not go into the same commit). Once the work is done, I do a interactive rebase to tidy things up and then merge them afterwards. Sometimes the changes are not that much and it becomes a squash commit. I would definitely refrain from creating 100 (insignificant and possibly back-and-forth) commits on the main branch.
I wish I had time for that.
Maybe my explanation was complicated, but what I describe is not time consuming. It takes at most a few minutes to do all of the things I mentioned. The difficult part is discipline of keeping refactoring separate. Once that’s done, the rest is trivial. And not all work include refactoring. That’s even easier then.
Discipline is definitely tough. I have tried looking at rebasing tutorials and it always looked pretty tedious to do, hence my comment about time constraints. I should really give it another try though.
Interactive rebase is used to organize (squash, drop, reorder) commits and with some experience is totally painless. Would definitely recommend watching a few videos about it.
I used to find rebasing annoying until I started using lazygit. It makes it really easy, now before opening a PR I just interactive rebase on top of latest main and I can easily clean up my commits before opening the PR.
Sounds interesting, I’ll check it out! Thanks for the link
deleted by creator