3 ms·
Very similar to Conventional Commits[1], with this structure: <type>[optional scope]: <description> [optional body] [optional footer(s)] It's supported by p
by l0b0 6y ago
Very similar to Conventional Commits[1], with this structure:
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
It's supported by pre-commit[2], which is an excellent way to set up commit rules and linting.
[1] https://www.conventionalcommits.org/en/v1.0.0/ https://www.conventionalcommits.org/en/v1.0.0/
[2] https://pre-commit.com/ https://pre-commit.com/
- auslegung 6y agoAt first, conventional commits sounds neat because they say you can > Automatically generating CHANGELOGs. > Automatically determining a semantic version bump (based on the types of commits landed). And I would really like those features. However it seems like this assumes 1 commit per feature, which I think is not the conventional wisdom. Am I missing something? For example, the feature is to add a new page to the site where the user can view all their posts. That should break down into several commits: add new route, add parser on frontend, add html structure, etc. But each of those commits would have to start with `feat: add route to fetch user's posts` and so on. Wouldn't that result in a unhelpfully verbose changelog, when the changelog should really feature one line: "Allow users to view all of their posts in one place"