Do you have any advice for helping a team clean up git hygiene? This is an in-depth question, so for clarity, I'm currently thinking about the actual commits.
e.g.
git add .
git commit -m "Try a thing"
... write more code, fix things, etc...
git add .
git commit -m "fix bug cerated by trying a thing"
Two difficulties seem to be "git trutherism" (rebasing or squashing is lying!) and developers fear of git and learning new ways to use it.
I build things with my hands. The human behind Shift - https://laravelshift.com, master of Git - https://gettinggit.com, and author of "BaseCode" - https://basecodefieldguide.com
I suggest creating a Git Style Guide, similar to a Code Style Guide. I've helped teams create these. Often a quick meeting to get everyone on the same page and some sharing of resources like How to write a good commit message go a long way. Other rules (like don't squash commits) can be documented. As with any style guide though, it shouldn't be too restrictive.
I'd check out the article Writing Reviewable Code - commit messages are one of the things I see most underutilized. Having a body and explaining why changes were made is really helpful to both the author (they have to think about what they've changed) and to future readers who can see the code change but not the context for the change.
A useful rule of thumb for anyone scared of Git is that once you commit something, it's very hard to destroy that data. Rebase, reword, squash and fix-up as you want, and keep a clean history full of useful, searchable information for your project.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Do you have any advice for helping a team clean up git hygiene? This is an in-depth question, so for clarity, I'm currently thinking about the actual commits.
e.g.
Two difficulties seem to be "git trutherism" (rebasing or squashing is lying!) and developers fear of git and learning new ways to use it.
I suggest creating a Git Style Guide, similar to a Code Style Guide. I've helped teams create these. Often a quick meeting to get everyone on the same page and some sharing of resources like How to write a good commit message go a long way. Other rules (like don't squash commits) can be documented. As with any style guide though, it shouldn't be too restrictive.
I'd check out the article Writing Reviewable Code - commit messages are one of the things I see most underutilized. Having a body and explaining why changes were made is really helpful to both the author (they have to think about what they've changed) and to future readers who can see the code change but not the context for the change.
A useful rule of thumb for anyone scared of Git is that once you commit something, it's very hard to destroy that data. Rebase, reword, squash and fix-up as you want, and keep a clean history full of useful, searchable information for your project.