You must log in or register to comment.
It’s pretty easy to set up, and gives you an added way to verify that the code in your repository is supposed to be there.
It’s nice and all, but in a GitHub/GitLab PR workflow world, your commits are mostly squashed and rewritten by the remote, so it doesn’t even show up on main
So there’s really only a benefit if you don’t use squash and bother with maintaining proper commit messages in your PRs
This is yet another reason not to squash commits.
So there’s really only a benefit if you don’t use squash and bother with maintaining proper commit messages in your PRs
I’d argue that you should never squash and always maintain proper commit messages…
Not very convincing without reasoning
I have never heard proper reasoning for squashing commits. I don’t think sanitized history is useful in any context. Seeing the thought process that went into building something has been repeatedly useful in debugging things. It’s also useful to me as a software engineering manager to help folks on my team get better. I could care less how “pretty” git log looks, but I care a hell of a lot about what git diff and git blame tell me. They help me figure out where issues actually are and how they came to be.
