In the previous post, we would like to share with you how to use basic GIT on Windows / Linux. In the post, we would like to talk about commit messages. Developers wouldn’t care how to write a good commit message.
Some developers think that I manage the project from A-Z, I understood them and there is no need to write good commit messages. Oh that is a case that you work alone but what happens when you work with a team or contribute to open source or others maintain your codes.
A good commit message is the best way to explain context about the change to other developers working on that project; and to your future self.
Try running git -log for one of your old projects to see weird commit message you have used since its inception. It is also hard to understand why you made some changes in the past.
Commit message can communicate why a change made and understanding that makes development and collaboration more efficient.
It is not easy to write good commit messages immediately. In order to create a habit of writing good commit messages, I would do it daily.
Keep in mind :
– the commit message should be clear and meaningful.
– don’t think your code is self-explanatory
– don’t assume that reviewer understands what the original problem was
– follow the commit convention defined by your team
This style guide acts as the official guide to follow in my projects.
A commit message structure includes:
– Type (scope) : subject
– Body (optional)
– Footer (optional)
Type:
– Feat: a new feature
– Fix: a bug fix
– Docs: change to document
– Style: formatting, missing semi colons, etc.; no change codes
– Refactor: refactoring production code
– Test: adding tests, refactoring test, no production code change
– Chore: updating building tasks, package manager configs, etc.; no production code change
Subject:
– up to 50 characters, should begin with capital letter and don’t end with a period
– use imperative tone to describe what a commit does, rather than what it did.
Body:
– if the commit is complex and requires a bit of explanation & context, use body to explain the what and why of a commit not how
– a body is up to 72 characters
– a blank line between title and body
Footer
– optional and is used to reference issue tracker IDs.
Reference:
– https://www.conventionalcommits.org/en/v1.0.0/
– https://github.com/angular/angular/blob/master/CONTRIBUTING.md#commit
– https://chris.beams.io/posts/git-commit/
Command line
git commit -m “title” -m “Description”
Example 1:
type(scope):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 like `log`, `shortlog`
and `rebase` can 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 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 here
If you use an issue tracker, put references to them at the bottom,
like this:
Resolves: #123
See also: #456, #789Example 2:
Feat: Parsing data in list mode
See also: #456, #789