What is a
commit command is used to save changes to our local repository after staging in Git. Before saving to our local repository, we need to tell Git which changes you need to save, as you have done lots of changes. A better way to do this, by adding commit messages to tell what changes you have done.
Why do we need to write good commit messages?
If the project history is seen only by you, you can write whatever you want. But, when multiple people are involving in that project, you have to write good commit messages. So that they could able to understand better. Roughly said, the commit is the comment of each change, what and why you have made the change.
Commit messages frequently communicate why such a change was made, so it helps to understand better. Thus better understanding and collaboration make work more efficient.
There are three important points:
- To speed up the review process
- To help the developer team to write good release notes.
- To help the future maintainers(Why such feature was added).
How to write good commit messages?
There are no strict definitions for good commit messages, but generic rules have emerged. A commit message should have only one logical change.
There are several conventions used by different developer teams and companies. If you work in a particular company, you have to follow their conventions.
Good commit messages are not only good for others with who you may be collaborating but also for you, when you look back on your history you can able to understand much better.
The general format is :
Short (72 chars or less) summary of changes
More details explanatory text. wrap it to 72 characters. The blank
line separating the summary from the body is critical(unless you
omit the body entirely).
Write you commit message in the imperative: "Fix bug " and not "Fixed bug" or "Fixes bug".This convention matches up with commit messages generated by commands like git merge and git revert.
Further paragraphs come after blank lines.
- Bullet points are okay, too.
- Typically a hyphen or asterisk is used for the bullet, followed >by a single space. Use a hanging indent.
Rules for a great git commit message style
- Separate subject from body with a blank line
- Do not end the subject line with a period
- Capitalize the subject line and each paragraph
- Use the imperative mood in the subject line
- Wrap lines at 72 characters
- Use the body to explain what and why you have done something. In most cases, you can leave out details about how a change has been made.
You can make yours good too, this is the format I used to :
type : subject body (optional)
- feat: The new feature you're adding to a particular application
- fix: A bug fix
- style: Feature and updates related to styling
- refactor: Refactoring a specific section of the codebase
- test: Everything related to testing
- docs: Everything related to documentation
- chore: Regular code maintenance.[ You can also use emojis to represent commit types]
This is a short description of the changes you have made. It should start with a Capital letter and should not exceed more than 50 characters. Eg: Add x filter instead of Added x filter or Adds x filter.
It is used to explain what changes you have made and why you have made the changes. Not all commit messages need a body, it's optional.
Tips: If you have several logics and you if you feel difficult to commit message split up and do it.
How not to do it:
- Don't do the end-of-day commits, it looks messy when you go through the history it looks messy, and others cannot able to understand.
- Don't do lazy commits, it's really hard for others to understand what is going in the project.
Top comments (0)