Skip to content
This repository has been archived by the owner on Apr 6, 2023. It is now read-only.

Commit

Permalink
Browse files Browse the repository at this point in the history
feat: Add commitlint to lint commit messages
Create a commit convention for our organization, install `commitlint`
and configure it as a hook to lint commit message. This helps will your
team and contribuitors to adhering to the said commit convention.

Add a `commitlint` script in Travis to catch anyone that tries to bypass
the local validation.

Update `CONTRIBUTING.md` to reflect the convention created by this
commit.

Closes #23
  • Loading branch information
pellizzetti committed May 16, 2019
1 parent 110e65a commit 1ac7f8a
Show file tree
Hide file tree
Showing 5 changed files with 604 additions and 36 deletions.
79 changes: 60 additions & 19 deletions .github/CONTRIBUTING.md
Expand Up @@ -14,6 +14,7 @@
- [Code](#code)
- [Dev environment](#dev-environment)
- [Commiting](#commiting)
- [Why all this rules?](#why-all-this-rules)
- [Submitting a pull request](#submitting-a-pull-request)

## Getting started
Expand Down Expand Up @@ -118,45 +119,83 @@ This project uses [Prettier](http://prettier.io/) for code formatting. Consider

## Commiting

- Never use the `-m <msg>` / `--message=<msg>` flag to `git commit`;
A commit message can consists of a **header**, **body** and **footer**. The header is the only mandatory part and consists of a type and a subject. The body is used to fully describe the change. The footer is the place to reference any issues or pull requests related to the commit. That said, we end with a template like this:

```
<type>: <subject>
[optional body]
[optional footer]
```

To ensure that a commit is valid, easy to read, and changelog-ready, we have a hook that lints the commit message before allowing a commit to pass. This linter verifies the following:

- The header (first line) is the only mandatory part of the commit message.
- The header should contains:
- A type:
- Must be lowercase;
- Must be one of:
- **chore**: A change that neither fix a bug or adds a feature;
- **ci**: A CI change;
- **docs**: A documentation change or fix;
- **feat**: A new feature;
- **fix**: A bug fix;
- **test**: A test-related change.
- A subject:
- Must be capitalized;
- Must be limited to 50 characters or less;
- Must omit any trailing punctuation;
- Header, body and footer must be separated by a blank line;
- The following lines should have 72 characters or less;
- Reference to issues and pull requests must be made in the last line.

You also should follow these general guidelines when committing:

- Use the present tense ("Add feature" not "Added feature");
- Use the imperative mood ("Move cursor to..." not "Moves cursor to...");
- The first line should:
- Be capitalized;
- Have 50 characters or less;
- Omit any trailing punctuation;
- Be followed by a blank line.
- The following lines should have 72 characters or less;
- Reference issues and pull requests liberally after the first line;
- When creating a commit try to answer the following questions:
- Try to answer the following questions:
- Why is this change necessary?
- How does it address the issue?
- What side effects (if any) does this change may have?

Example:
Example of a commit message:

```
Commit message style guide for Git
type: Commit message style guide for Git
The first line of a commit message serves as a summary. When displayed
on the web, it's often styled as a heading, and in emails, it's
typically used as the subject. As such, you should capitalize it and
typically used as the subject. As such, you should specify a "type" and
a "subject". The type must be lowercase and one of: chore, ci, docs,
feat, fix, test. For the subject you'll need capitalize it and
omit any trailing punctuation. Aim for about 50 characters, give or
take, otherwise it may be painfully truncated in some contexts. Write
it, along with the rest of your message, in the present tense and imperative mood: "Fix
bug" and not "Fixed bug" or "Fixes bug". Consistent wording makes it
easier to mentally process a list of commits.
it, along with the rest of your message, in the present tense and
imperative mood: "Fix bug" and not "Fixed bug" or "Fixes bug".
Consistent wording makes it easier to mentally process a list of
commits.
Oftentimes a subject by itself is sufficient. When it's not, add a
Oftentimes a subject by itself is sufficient. When it's not, add a
blank line (this is important) followed by one or more paragraphs hard
wrapped to 72 characters. Git is strongly opinionated that the author
wrapped to 72 characters. Git is strongly opinionated that the author
is responsible for line breaks; if you omit them, command line tooling
will show it as one extremely long unwrapped line. Fortunately, most
text editors are capable of automating this.
When relevant, issues and pull request can be referenced using theirs numbers: #3 #12
Issues and pull request can be referenced on the footer: #3 #12
```

### Why all this rules?

We try to enforce that rules for the following reasons:

- Automatically generating changelog;
- Communicating in a better way the nature of changes;
- Triggering build and publish processes;
- Automatically determining a semantic version bump (based on the types of commits);
- Making it easier for people to contribute, by allowing them to explore a more structured commit history.

## Submitting a pull request

Before submitting a pull request, please make sure the following is done:
Expand All @@ -165,4 +204,6 @@ Before submitting a pull request, please make sure the following is done:
- Example: `feature/my-awesome-feature` or `fix/annoying-bug`;
- Run `yarn` in the repository root;
- If you’ve fixed a bug or added code that should be tested, **add tests**;
- Ensure the test suite passes.
- Ensure the test suite passes;
- Ensure your commit is validated;
- If your pull request is about documentation or meta files, please add the tag **[skip ci]** in the title.
7 changes: 5 additions & 2 deletions .travis.yml
@@ -1,19 +1,22 @@
language: node_js

node_js:
- "10"
- '10'

cache:
yarn: true
directories:
- node_modules

before_install:
- commitlint-travis

install:
- yarn

script:
- yarn coveralls

before_deploy:
- yarn build

Expand Down
3 changes: 3 additions & 0 deletions commitlint.config.js
@@ -0,0 +1,3 @@
module.exports = {
extends: ["rocketseat"]
};
7 changes: 6 additions & 1 deletion package.json
Expand Up @@ -13,7 +13,8 @@
"license": "MIT",
"husky": {
"hooks": {
"pre-commit": "lint-staged"
"pre-commit": "lint-staged",
"commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
}
},
"lint-staged": {
Expand All @@ -34,6 +35,9 @@
},
"devDependencies": {
"@babel/core": "^7.4.3",
"@commitlint/cli": "^7.6.1",
"@commitlint/config-conventional": "^7.6.0",
"@commitlint/travis-cli": "^7.6.1",
"@types/dot-object": "^1.7.0",
"@types/jest": "^24.0.11",
"@types/react": "^16.8.13",
Expand All @@ -42,6 +46,7 @@
"@types/yup": "^0.26.12",
"@typescript-eslint/eslint-plugin": "^1.6.0",
"@typescript-eslint/parser": "^1.6.0",
"commitlint-config-rocketseat": "^0.0.1",
"coveralls": "^3.0.3",
"eslint": "^5.16.0",
"eslint-config-airbnb": "^17.1.0",
Expand Down

0 comments on commit 1ac7f8a

Please sign in to comment.