├── .gitignore ├── README.md ├── commit-semantics-banner.jpg └── install.sh /.gitignore: -------------------------------------------------------------------------------- 1 | .idea 2 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 |

2 | 3 | commit-semantics 4 | 5 |

6 | 7 | # Commit-Semantics 8 | 9 | Inspired by Angular JS's committing style as on [github](https://github.com/angular/angular/commits/master), this project installs git aliases of various commit message type and helps in creating a standard of committing format. 10 | 11 | ## Introduction 12 | These are **custom git commands** that encourages the git user to write formatted git commit messages. These aliases will standardised git commits. 13 | 14 | e.g. ```git feat install.sh 'Added commit semantics aliases'``` -> ```git commit -m 'feat(install.sh): Added commit semantics aliases'``` 15 | 16 | More shorter way possible now: 17 | 18 | e.g. ```gf install.sh 'Added commit semantics aliases'``` -> ```git commit -m 'feat(install.sh): Added commit semantics aliases'``` 19 | ## Installation 20 | 21 | 1. Clone this repo, preferably in your $HOME directory. ```git clone https://github.com/akanshgulati/commit-semantics.git 22 | ~/.commit-semantics``` 23 | 24 | 25 | 2. Install it as git aliases: 26 | ```cd ~/.commit-semantics && chmod 755 install.sh && ./install.sh``` 27 | 28 | 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 29 | 30 | 3. Ready to use. 31 | 32 | ## Usage 33 | 34 | Once you install, you can use 10 git aliases in following ways: 35 | #### 1. __Only Committing__ 36 | **```git ```** -> **```git commit -m '(): '```** 37 | 38 | e.g. 39 | * _**git feat** install.sh "options in alias command"_ __->__ _git commit -m 'feat(install.sh): options in alias command'_ 40 | * _**git docs** LICENSE "update to apache 2.0 style"_ __->__ _git commit -m 'docs(LICENSE): update to apache 2.0 style'_ 41 | * _**git chore** package.json "task to uglify JS"_ __->__ _git commit -m 'chore(package.json): task to uglify JS'_ 42 | * _**git fix** app "maximum call stack issue"_ __->__ _git commit -m 'fix(app): maximum call stack issue'_ 43 | * _**git refactor** MainController "change callbacks to promises"_ __->__ _git commit -m 'refactor(MainController): change callbacks to promises'_ 44 | * _**git style** navbar "add sticky position"_ __->__ _git commit -m 'style(navbar): add sticky position'_ 45 | * _**git test** appSpec "fix test cases for init method"_ __->__ _git commit -m 'test(appSpec): fix test cases for init method'_ 46 | * _**git perf** accordion "add lazy load in thumbnails"_ __->__ _git commit -m 'perf(accordion): add lazy load in thumbnails'_ 47 | * _**git cleanup** dateFilter "remove unused dateChange method"_ __->__ _git commit -m 'cleanup(dateFilter): remove unused dateChange method'_ 48 | * _**git tracking** sidebar "add click event on links"_ __->__ _git commit -m 'tracking(sidebar): add click event on links'_ 49 | 50 | 2. __Committing with options__ 51 | * **```git [options]```** -> **```git commit [options] -m '(): '```** 52 | 53 | e.g. 54 | * _**git feat** install.sh "options in alias command" a_ __->__ _git commit -a -m 'feat(install.sh): options in alias command'_ 55 | * _**git fix** app "maximum call stack issue" p_ __->__ _git commit -p -m 'fix(app): maximum call stack issue'_ 56 | 57 | **Note:** Only those options can work that precedes `-m` option in git commit, such as `-p`, `-a`, `-s`, `-v`, `-c` . 58 | ## Guidelines 59 | ### Selecting `type` 60 | ____ 61 | 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. 62 | 63 | * **feat**: Commits related to a new feature developed 64 | * **fix**: Commits related a bug fix 65 | * **style**: Commits related to styling in .css, .scss, .etc files. 66 | * **cleanup**: Commits related to changes that do not affect the logic of the code (white-space, formatting, missing 67 | semi-colons, dead code removal, etc.) 68 | * **refactor**: Commits related to changes that neither fixes a bug nor adds a feature but is used for restructuring the code 69 | * **perf**: Commits related to changes that improves performance 70 | * **test**: Commits related to adding missing tests or fixing them 71 | * **chore**: Commits related to changes in build process, auxiliary tools and libraries such as documentation 72 | generation 73 | * **tracking**: Commits related to any kind of tracking which includes bug tracking, user tracking, analytics, etc. 74 | * **docs**: Commits related to documentation changes, such as Readme.md file 75 | 76 | ### Selecting `scope` 77 | ____ 78 | The scope in commit message could be anything specifying context of the commit change. A scope context can be a `module`, 79 | `fileName`, `serviceName`, `directiveName`, `functionName` , `impactArea`, etc. 80 | ### Selecting `commit-message` 81 | ____ 82 | There are certain rules that everyone should follow to commit like a pro. 83 | 1. [**Limit of 50 characters**](#heading-message-one) 84 | 2. [**Do not end the message with a period**](#heading-message-two) 85 | 3. [**Use imperative form**](#heading-message-three) 86 | 4. [**Use present tense**](#heading-message-four) 87 | 88 | #### 1. Limit of 50 characters 89 | 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. 90 | Even Github truncates any message line longer than 72 characters with an ellipsis. 91 | > 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. 92 | 93 | #### 2. Do not end the message with a period 94 | Punctuation marks at the end of message is not required as commit messages are considered as subject or titles. 95 | #### 3. Use imperative form 96 | 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. 97 | Few examples: 98 | * Pour me a glass of water. 99 | * Leave the package at the door. 100 | * Take me to the library. 101 | 102 | You can read more about imperative form [here](http://www.k12reader.com/learn-about-imperative-sentences-now/). 103 | #### 4. Use present tense 104 | 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. 105 | 106 | For example: 107 | 108 | `Renamed the variabled for better context` should be `Rename the variabled for better context` 109 | 110 | Even Git generated commit messages are in present tense. For example: 111 | 112 | `Merge pull request #1 from akanshgulati/better-desc ` 113 | ## Example 114 | 115 | ##### **Command**: 116 | git style header 'move header on top of elements' 117 | ##### **Output**: 118 | git commit -m "style(header): move header on top of elements" 119 | 120 | 121 | -------------------------------------------------------------------------------- /commit-semantics-banner.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/akanshgulati/commit-semantics/2ce4454c0b09bf49225026988fa16fef2f00e081/commit-semantics-banner.jpg -------------------------------------------------------------------------------- /install.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | # Register semantic commits git aliases 4 | # 5 | # $1 — git alias and semantic message prefix 6 | # [$2] — (optional) custom semantic message prefix 7 | function make_git_alias { 8 | if ! git config --global --get-all alias.$1 &>/dev/null; then 9 | git config --global alias.$1 '!f() { [[ -z "$GIT_PREFIX" ]] || cd "$GIT_PREFIX" && if [[ -z $1 ]] && [[-z $2]]; then git commit -m "'$1' " -e; else git commit -$3m "'$1'($1): $2"; fi }; f' 10 | echo 'Alias installed ' $1 11 | else 12 | echo $1 : 'alias already present, remove it from ~/.gitconfig file first' 13 | fi 14 | } 15 | # Register aliases 16 | echo 'Installing git aliases' 17 | 18 | semantic_aliases=( 'feat' 'fix' 'style' 'cleanup' 'refactor' 'perf' 'test' 'chore' 'tracking' 'docs' ) 19 | 20 | for semantic_alias in "${semantic_aliases[@]}"; do 21 | make_git_alias $semantic_alias 22 | done 23 | --------------------------------------------------------------------------------