A commit message is a short description of the changes you've made to a file added before committing the changes.
Good commit messages are important not only for others who you may be collaborating on the project but also for you, to keep track of all your commits and knowing exactly what changes where maybe during that particular commit.
Even if you're working on a personal project, I'd recommend that you start getting in the habit of writing good commit messages.
This is the format that I use most of the time (this may change depending on your preference or organization your working for):
type: subject
body (optional)
footer (optional)
1. Type
- feat - a new feature
- fix - a bug fix
- docs - changes in documentation
- style - everything related to styling
- refactor - code changes that neither fixes a bug or adds a feature
- test - everything related to testing
- chore - updating build tasks, package manager configs, etc
2. Subject
This contains a short description of the changes made. It shouldn't be greater than 50 characters, should begin with a capital letter and written in the imperative eg. Add instead of Added or Adds.
3. Body
The body is used to explain what changes you made and why you made them. Not all commits are complex enough that they need a body, especially if you are working on a personal project alone, and as such writing a body is optional.
A blank line between the body and the subject is required and each line should have no more than 72 characters.
4. Footer
The footer is also optional and mainly used when you are using an issue tracker to reference the issue ID.
Example of a good commit message used by Udacity student Udacity Git Commit Message Style Guide
feat: Summarize changes in around 50 characters or less
More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of the commit and the rest of the text as the body. The
blank line separating the summary from the body is critical (unless
you omit the body entirely); various tools likelog,shortlog
andrebasecan get confused if you run the two together.Explain the problem that this commit is solving. Focus on why you
are making this change as opposed to how (the code explains that).
Are there side effects or other unintuitive consequences of this
change? Here's the place to explain to them.Further paragraphs come after blank lines.
Bullet points are okay, too
Typically a hyphen or asterisk is used for the bullet, preceded
by a single space, with blank lines in between, but conventions
vary hereIf you use an issue tracker, put references to them at the bottom,
like this:Resolves: #123
See also: #456, #789
A more practical example:
docs: Fix typo in README.md
Latest comments (71)
You can make your repository commitizen-friendly by using the following tool. github.com/commitizen/cz-cli
You can also read more about commitizen here. conventionalcommits.org/en/v1.0.0/
Great article @chrissie
Hahaha. Thanks Chrissie
How to see emojis on terminal on windows???
Not sure why it didnt work out-of-the-box for me :(
Nice article, and also I would like to add my opinion:
Example
MYPROJ-420 Updated vendor libraries (lodash, robot, d3) for xyz page.Our branches include the ticket nr. A githook then adds the ticket nr to every commit.
Here's the super-concise commit message template that I've been using for years now (I've lost track of which blog post or comment I first picked it up from). I find it to be a helpful reminder, without inundating me with a wall of text every time I go to commit:
Great! I always wanted to improve my commit messages but didn't know what I should do but now you gave me a pattern/standard to follow.
Thank you
It's nice to add that this is just one convention of committing; check gnu.org/prep/standards/html_node/S... for an alternate widely used(especially in GNU projects) commit style. I normally default to that. Here's an example from some guix patch:
And if this not work you can use the random commit message generator.
Enjoy.
paulospx.github.io/some_if_stateme...
We're always using a reference to our bug tracker system:
#{ticket no.} - {ticket title}And we added a plugin to our bugtracker to "suggest" the correct commit message, which you can copy&paste into terminal or whatever git GUI in use ;)
Small, deliverable changes. I'll commit single, completed and tested methods as part of a feature build. As long as it works and can be delivered.
You can share your git commit conventions in the team via e.g.:
add this into your "~/.gitconfig"-file
example: github.com/voku/dotfiles/blob/mast...
We store a file in the root of each project: .gitmessage
Then in the project's Contributing section in the Readme, we have:
Before contributing to this project, configure the commit template while in the project root:
git config commit.template .gitmessage
The contents of the gitmessage is:
jira/issue-####: Title of issue
Description of changes.
We then squash all commits on merge and enforce rebasing.
This makes for a very clean commit log like:
jira/issue-2: Do that
These are more changes.
jira/issue-1: Do this
These are the changes.
How do you enforce rebasing?
It's a setting in GitLab per project.
Settings > General > Merge Requests.
Under Merge method, select "Fast-forward merge".
Description is: "No merge commits are created. Fast-forward merges only. When conflicts arise the user is given the option to rebase."
Honestly, commit messages are something I have by and large ignored in my development workflow (as a mostly solo Salesforce developer), but I can absolutely see the value in this. Hopefully shifting into a role at a consultancy soon, and I really think this will be a big assist.
In my current company we use this method:
JiraTaskID - JiraTitle - Some description
It will result in something like:
1123 - Update dependencies for the users screen - Update package.json & yarn.lock.
Then we do a squash/rebase and it gives a really good looking tree :D