Signing Commits in Git, Explained

https://blog.gitbutler.com/signing-commits-in-git-explained/

15 points · 6 comments · view on lemmy.world

6 Comments

bloopernova@programming.dev · 7 pts · 2y

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.

Sigmatics@lemmy.ca · 2 pts · 2y (4 replies)

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

lyda@programming.dev · 6 pts · 2y

This is yet another reason not to squash commits.

onlinepersona@programming.dev · 4 pts · 2y (2 replies)

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

Sigmatics@lemmy.ca · 1 pts · 2y (1 reply)

Not very convincing without reasoning

lyda@programming.dev · 2 pts · 2y

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.