Today, even with contribution guide, commits can have more than 50 characters in title and 72 columns in description.
We can add Commitlint with Husky to lint the commit message before commit reaches our Github.
We can also add it to Travis to double check any bypasses from developer.
diego3g
All 3 comments
@diego3g @jpdemagalhaes @aldroydzito
By default, commitlint comes with commit types. They are used to easily identify the kind of the commit. Example: chore: Run tests on travis ci. We can see that chore is the type of that commit and the goal of the change.
That being said, I would like to ask: Do you guys think we should use them?
If we choose to use them, I thought the following types would be nice to have:
- 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.
pellizzetti
on 15 May 2019
Seems fine to me, it allows for a more standard pattern over all the project. I think we should use them.
jpdemagalhaes
on 15 May 2019
It seems great to me!
diego3g
on 15 May 2019
Related issues
fmontone
路
4Comments
regisrc
路
5Comments
cleitonper
路
4Comments
PierreBosch
路
5Comments
cleitonper
路
5Comments
Most helpful comment
@diego3g @jpdemagalhaes @aldroydzito
By default,
commitlintcomes with commit types. They are used to easily identify the kind of the commit. Example:chore: Run tests on travis ci. We can see thatchoreis the type of that commit and the goal of the change.That being said, I would like to ask: Do you guys think we should use them?
If we choose to use them, I thought the following types would be nice to have: