-
Notifications
You must be signed in to change notification settings - Fork 6
Commits
Yusuf Kalaycı edited this page Feb 24, 2018
·
15 revisions
Similar to how events build history in time, commits builds our software in time. As historians tries to understand specifics of a single event with great effort, we have all the opportunity to escape those efforts and help ourselves read our history a lot easier.
<type>(<scope>): <subject>
<body>
<footer>
fix(middleware): ensure Range headers adhere more closely to RFC 2616
Add one new dependency, use `range-parser` (Express dependency) to compute
range. It is more well-tested in the wild.
Fixes #2310
- feat (new feature for the user, not a new feature for build script)
- fix (bug fix for the user, not a fix to a build script)
- docs (changes to the documentation)
- style (formatting, missing semi colons, etc; no production code change)
- refactor (refactoring production code, eg. renaming a variable)
- test (adding missing tests, refactoring tests; no production code change)
- chore (updating grunt tasks etc; no production code change)
- The first line cannot be longer than 70 characters. (including type and scope)
- The type and scope should always be lowercase as shown below.
- The scope can be empty (e.g. if the change is a global or difficult to assign to a single component).
- Use the imperative, present tense: change not changed nor changes.
- Do not capitalize subject line (if it's not a special name).
- Do not end subject line with a dot.
- Refer files with fullname such as
README.md - You can refer to issues at the end such as
docs(templates): enumerate items of MEETING.md (#27)
- The second line is always blank.
- All other lines should be wrapped at 80 characters.
- Include motivation for the change and contrasts with previous behavior.
- Reference issues if needed as
Closes #234,Fixes #212. - Breaking changes should be noted.
- First of all remember that syntax style of commits devised to help you in semantics as well.
- Try to be modular. For example, if you can't decide what the
typeof the commit is then you should divide it into seperate parts. - Make sure that every change in the commit is towards a single goal. Do not jumble two separate task related changes into one commit.