this post was submitted on 19 Jul 2024
40 points (95.5% liked)
Git
2868 readers
7 users here now
Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.
Resources
Rules
- Follow programming.dev rules
- Be excellent to each other, no hostility towards users for any reason
- No spam of tools/companies/advertisements. It’s OK to post your own stuff part of the time, but the primary use of the community should not be self-promotion.
Git Logo by Jason Long is licensed under the Creative Commons Attribution 3.0 Unported License.
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
Also, squashing is a pretty bad practice as it is. I can understand that it may make sense sometimes, but most of the time if you don't commit every other character you input, you're better off leaving some history of how your code evolved and what changes were coming together
I think squashing is great and I would never want to go back. It helps ensuring:
And IMO, if your work warrants multiple commits, then it probably also warrants multiple merge requests. Merge requests should be rather small to make it easier to review.
Edit: another good thing is that when we decide to release, we can easily look through the commit history for a change log. No more sifting through minor fixes commits.
I agree with most of these but there's another missing benefit. A lot of the time my colleagues will be iterating on a PR so commits of "fuck, that didn't work, maybe this" are common.
I like meaningful commit messages. IMO "fixed the thing" is never good enough. I want to know your intent when I'm doing a blame in 18 months time. However, I don't expect anyone's in progress work to be good before it hits main. You don't want those comments in the final merge, but a squash or rebase is an easy way to rectify that.
git rebase
trumps all of the things you mentioned...Anti Commercial-AI license
Git rebase can be hard to understand for many. Not everyone has the blessing of being in a team of Git gurus.
It's more about the tooling. IDEs make it really simple.
Also people get scared when they hear it because of utterances like yours. I'm dumb af. Git rebase for your use cases can be renamed to "git edit-history $fromCommit". Nothing special about it.
Anti Commercial-AI license
With this I wholeheartedly agree
With this not so much, but if you keep your merge requests so small, squashing them is no big deal, that's a good counterexample for my previous point.
That still requires you to write meaningful messages, just a bit rarer. We do have trouble with change logs, but we had exact same problems when people squashed left and right. Maybe squashing helps self-discipline, though, I haven't thought about it that way