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.
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.
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.