Over the life of a project, your git commit log is a great resource for seeing where a project is/was at any given point in time. A good commit log not only shows you the direct changes made to the code, but also provides the context of why those changes were made, how they were made, and who made them. The codebase tells you what a project does, the commit log tells you the story of the project development.
There are many different ways you can create a useful commit log, but the most important part is for your log to be cohesive and easy to follow for anyone that may need to utilize it. In a one person project, this is as easy as choosing and maintaining a consistent style, but on a group project, it’s important to establish a set of rules to follow with your commits.
This is where you spell out how you’d like your commits to look, so address things like punctuation, capitalization, syntax, and margins. Remove as much of the guesswork as you can so commits are consistent between contributors.
What do you think is important to include in your commits, and what is not important to include? Once you have this information, it’s easier to quickly summarize what’s been added in each commit message.
Outside of the code, what referential data is needed to be able to easily track what’s happening with a project? Are there user, feature, or error ticket ID’s needed? This data can give the reader insight into what is happening on a project outside of the code.