this post was submitted on 27 Jun 2024
422 points (95.3% liked)
Programmer Humor
19593 readers
870 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 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
NGL I 'm a bit like that. I often do "work" commits so that my working tree is a bit more clean/I can go from working state to working state easily.
But before a PR, I always squash it, and most times it's just a single commit
Same haha. But i use a combination of commits ( but not pushed ), ammending, fixups and usually clean it up before making a PR or pushing ( and rebase/merge main branch while at it). Its how git should be used..
I do push often as I'm often switching between two devices. And I do make draft PR so I got an easy git diff that I can live reference with
You are not alone. This is the work git was built for.
There is a bit of benefit if you have code reviewed so separate commits are easier to review instaed of one -900 +1278 commit.
How do you "squash" it?
Squashing
https://www.atlassian.com/git/tutorials/rewriting-history
You can also amend for a softer approach, which works better if you don't push to remote after every commit.
You can keep amending commits and creating more chunky and meaningful ones in an incremental way. Think of it as converting baby steps into an adult step.
My attempt to explain was squashed by this comment
Or if you want to --force commit 😈. Imo if it's my own working feature branch on a trunk-based roll-forward repo idgaf about rewriting history, and I will do it with wanton abandon.
Gitlab has a checkbox for squashing merge requests into a single commit. Not sure if GitHub has that too.