Once you've [cleaned up and tided your commits][1], re-ordered them and squashed any commits together to combine them into logical changes, before you push them, you should also check if your commit messages still make sense.
Using short or generic commit messages is fine when spiking a solution in very short feedback loops, but when you push your changes, you want them to be as descriptive and meaningful as possible.
If someone ran `git log` weeks, months or years from now, would they get value from reading the commit messages?
Are you using the subject and body correctly and wrapping text when needed?
Does each message accurately reflect and describe the change?
Does it capture why the change is needed, any alternative approaches that we considered or tried, or any complications that were encountered?
If you're following a standard like [conventional commits][0], have you correctly included the required information, such as the type, scope and any references, such as the task reference?
Having a Git log with detailed history is valuable when you need to review the changes in the future, but it also makes it more likely your changes will be approved and merged, whether you're working on a paid project or volunteering on an open-source project.
