Git

3036 readers

1 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 2 years ago

MODERATORS

[email protected]

commit messages are optional (schpet.com)

submitted 7 months ago by [email protected] to c/[email protected]

18 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 4 points 7 months ago (15 children)

The post mentions that these are for commits in a merge request before squash. When they’re squashed a proper message is given.

[–] [email protected] 5 points 7 months ago (6 children)

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

[–] [email protected] 6 points 7 months ago* (last edited 7 months ago) (5 children)

I think squashing is great and I would never want to go back. It helps ensuring:

All commits in main have useful messages. No more “fix pipeline errors”, “fix MR comments”, etc.
Ensures pipeline has been successful with all commits in main. No need to guess which commits will build and won’t build.
Easy to revert commits.
Eliminates incompressible history because someone had a bad day with git.
Encourages frequent commits. No need to ensure all commits are perfect and good in their own right. Commit when you want to commit even if it’s incomplete work.

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.

[–] eclipse 3 points 7 months ago* (last edited 7 months ago)

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.

load more comments (4 replies)

load more comments (12 replies)