Git commit messages

Hey, I think it might be beneficial to have some guidelines around commit messages. I've seen a few commits on this project that have commit messages akin to "added code" rather than explaining what the commit contains.

For example, when updating a prefab (e.g. forgetting to add before pushing code changes), something along the lines of "updated <prefabName> prefab to change <attributeName> attribute field" is more meaningful than "oops". Even without the autogenerated prefab/unity object code being nigh impossible to read in git, good commit messages give context about what to expect and help understand the changes made.

I found this blog post really useful in constructing meaninful commit messages:
https://chris.beams.io/posts/git-commit/

While I don't think it completely necessary to have full subject-body commit notes, at the very least having a meaningful commit subject line should be encouraged. What does everyone think?

 

It would be better to have proper commit messages yeah, that way you can track back what happened and why without having to search for the old PR for that. @cirocontinisio maybe this should be part of the style-guide in some way?

 

I agree with @Aspekt1024. I would also add the card code to the commit message. But I don't know if there is some code we can relate to a task card in Codecks, something like issues code from Github?

 

Kind of how JIRA will connect that you made a PR for a story?

That would be neat actually!

 

I have a colleague who refuses PR if the commit message does not respect some format or does not give some information.
Also I know with Git there is a possibility to enforce a certain format. It will refuse a commit if it does not follow this format (but it is tricky to put in place and I think it can be checked only a push time, not actually commit time).

Not going to these extemes, I think we should at least put the Codecks ticket number in the commit message.

 

Quick FYI to everyone who's not sure how to change commit messages after the fact, you can learn more about that here https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History