Commit semantics is a git aliases installation script to follow a fix format for commits
Inspired by Angular JS's committing style as on github, this project installs git aliases of various commit message type and helps in creating a standard of committing format.
These are custom git commands that encourages the git user to write formatted git commit messages. These aliases will standardised git commits.
e.g. git feat install.sh 'Added commit semantics aliases'
-> git commit -m 'feat(install.sh): Added commit semantics aliases'
More shorter way possible now:
e.g. gf install.sh 'Added commit semantics aliases'
-> git commit -m 'feat(install.sh): Added commit semantics aliases'
Clone this repo, preferably in your $HOME directory. git clone https://github.com/akanshgulati/commit-semantics.git ~/.commit-semantics
Install it as git aliases:
cd ~/.commit-semantics && chmod 755 install.sh && ./install.sh
Tip: You can check if aliases are created in ~/.gitconfig
file respectively. Aliases will be created only if no respective alias is present in ~/.gitconfig
file
Once you install, you can use 10 git aliases in following ways:
git <type> <scope> <commit-message>
-> git commit -m '<type>(<scope>): <commit-message>'
e.g.
git <type> <scope> <commit-message> [options]
-> git commit [options] -m '<type>(<scope>): <commit-message>'
e.g.
Note: Only those options can work that precedes -m
option in git commit, such as -p
, -a
, -s
, -v
, -c
.
type
Different types of type
are there according to make sure one can get idea about the core reason of commit message. Current script supports following types of commits.
scope
The scope in commit message could be anything specifying context of the commit change. A scope context can be a module
,
fileName
, serviceName
, directiveName
, functionName
, impactArea
, etc.
commit-message
There are certain rules that everyone should follow to commit like a pro.
50 characters is not a hard limit, just a rule of thumb. Keeping message at this length ensures that they are readable, and forces the author to think for a moment about the most concise way to explain what’s going on. Even Github truncates any message line longer than 72 characters with an ellipsis.
If your message length increases 50 characters even after summarizing, try to adopt atomic commits pattern. You can use
git add -p
to get better insight of changes.
Punctuation marks at the end of message is not required as commit messages are considered as subject or titles.
Imperative form ensures to convey the correct instruction of the commit in short and crisp form. With the current commit semantics, keeping imperative form is much easier. Few examples:
You can read more about imperative form here.
Usually, we believe commit message records what we have done. But, Git is a distributed version control system where there are potentially many places to get changes from. Rather than writing messages that say what you’ve done; consider these messages as the instructions for what applying the commit will do.
For example:
Renamed the variabled for better context
should be Rename the variabled for better context
Even Git generated commit messages are in present tense. For example:
Merge pull request #1 from akanshgulati/better-desc
git style header 'move header on top of elements'
git commit -m "style(header): move header on top of elements"