I wonder what my last commit at each job was. I'll bet it was boring. About 10% of my commit messages are genuinely interesting.
For some definition of interesting …. The quashed commit whose message is a Jira ticket number and title?
This is what I hate about squashing. I love the fact that my crazy journey to a finished feature is there in the log for everyone to see, including myself lol. But squashing makes me feel empty when I write commit messages. Where's the fun... Just a straight line of perfectionism. Maybe someone has a crazy but cool idea that would be worth picking. 🍒
Maybe. I do more DevOps these days, so tend to have many small changes that can’t even be tested without checking them in and running in CI. I’d have hundreds of “fix unit tests” commits alone
We squash. I'm not really interesting in your local journey to land the change. It's sometimes useful during review, but after that it's mostly the state of the main branch I care about. It's what I need to bisect anyway.
I don't like commits that are just references to issues. Copy the issue into the commit message so git blame tells you something useful. Unless it's just closing a simple big. Then the title and issue reference are plenty.
Depends on the project I imagine.
I've been thinking about that when talking to my DevOps colleagues, that there's gotta be a better way to test CI before committing. The whole change-commit-test dance would kill me if on a daily basis. So cumbersome.
I wonder what my last commit at each job was. I'll bet it was boring. About 10% of my commit messages are genuinely interesting.
For some definition of interesting …. The quashed commit whose message is a Jira ticket number and title?
This is what I hate about squashing. I love the fact that my crazy journey to a finished feature is there in the log for everyone to see, including myself lol. But squashing makes me feel empty when I write commit messages. Where's the fun... Just a straight line of perfectionism. Maybe someone has a crazy but cool idea that would be worth picking. 🍒
Maybe. I do more DevOps these days, so tend to have many small changes that can’t even be tested without checking them in and running in CI. I’d have hundreds of “fix unit tests” commits alone
We squash. I'm not really interesting in your local journey to land the change. It's sometimes useful during review, but after that it's mostly the state of the main branch I care about. It's what I need to bisect anyway.
I don't like commits that are just references to issues. Copy the issue into the commit message so
git blametells you something useful. Unless it's just closing a simple big. Then the title and issue reference are plenty.Depends on the project I imagine.
I've been thinking about that when talking to my DevOps colleagues, that there's gotta be a better way to test CI before committing. The whole change-commit-test dance would kill me if on a daily basis. So cumbersome.