… notice how the breaking change is indented & the code changes are easily readable. Here’s a good example of a commit that does that: If there are breaking changes, we make sure they are spelled out here including how to change your code. This can include code (n markdown format) or anything else that conveys what the commit is all about. for the full header line length.Īfter an empty line, we then include a verbose message that explains the commit. We shoot for nothing greater than 75 characters. This first header line should be concise, not verbose, so it will not wrap or get truncated in any tool. Finally the header then contains a brief message, the subject of the change. This might be blank, or it might reference a specific component in the project ( or an Angular directive in our case). After that there is an optional reference to the scope of the commit that refers to what it addresses. The type could be things like feat for a new feature, fix for a bug fix or chore which is used for project management stuff like build updates. We use a convention of type(scope): subject. Using just this single line you someone should be able to find exactly what they are looking for by issuing a git log -oneline or browsing the This starts with a brief header line that explains what the kind of change is, what it affected, and a short message to what it is about. You can see our commit message guidelines, inspired from the Angular Material project, here: Rather, a commit message should be more like a journal entry that can be used in creating great docs and convey to other developers what happened. The idea is for the message to include be more than just a quick message the developer has to enter before saying their job is done. The first step to a clean commit log is good commit messages. Yuk! There are a ton of merge commits and you can’t tell what each one does! You have to follow the swim lane to find what it did and that takes concentration. Notice my name is all over that ugliness… I did it! Example of a bad commit log messages I picked a project that I didn’t put any guidelines in place… you might recognize it, but that’s not the point… and this isn’t throwing stones in glass houses. Now, look at a log that, IMHO, gives you no insight into the project (taken from SmartGit). Notice how after the one-liner description shows up first, then you see the verbose description and what issues the commit references? Easy to read and consume. Notice a nice clean linear list of commits, each description is brief and to the point? You know exactly what is in each commit, you know what it does by the prefix and what it addresses.Ĭheck out the expanded view if you run git log: Git log Take a look at this log from our project (taken from SmartGit): Commit log How do we do this? Let’s look at what we aim for and compare it to what we do not want. In this post I will share how we keep a very clean commit log, one that is self-documenting, one that is very easy to read and quickly identify when and where stuff happened. The other posts in this series can be found here: ngOfficeUIFabric - How we did it. This post is part of a series of articles on my ngOfficeUIFabric - How we did it.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |