Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Define commit type, and enhance the `CHANGELOG` format #61
Hello fellow @hoaproject/hoackers and users!
Actual commit messages in Hoa are really great. They are detailed, meaningful, reviewed, and comprehensive. The commit title is always:
Import the concept of “commit type” from the Angular commit message guideline.
To quote it:
Not everything is useful. We are mostly concerned about the “commit type”.
Differences with the current format
The “commit type” is the only main difference, and this is what I would like to “import” in our format. The goal is to generate a
I would like to introduce the following commit types:
In the Angular commit message guideline, they propose this syntax:
The best way is to have it on our side to be sure we can't commit something with wrong message. We can use for that grumphp or we can inspire from it to be sure we have something equal for each library. Another thing is to provide a template (if necessary) to pre-fill the commit message.
Regarding the syntax it may be difficult to define the scope so only the prefix as
As this verification could be bypassed we must add it also on our side. But if we restrict it to be consistent about some format or anything else we should provide an help to use it.
@Pierozi we can add in travis build some verification to be sure it's ok.
Be careful, generally speaking, preventing someone to commit (even if this is to increase code quality) is considered a bad practice: git concept is commit as often and as quickly as you need.
I am agree with @CircleCode but this not means we should not provide a kind of tools (helper). We should provide a way to be able to do it on our side. In my case, I prefer to have an error when I try to commit and which explain what I have missed than waiting few weeks for a review and tell me the commit message have a wrong format.
Using Grumphp will force contributors to respect our guideline it's maybe too restrictif, so we should not force people to use it but recommend it. And we should provide an easy way to implement it.