3 ms·

I've seen real problems with using commitizen. The first, and probably most insidious, is that if you've got a tool to enforce a format, people stop thinking ab

I've seen real problems with using commitizen. The first, and probably most insidious, is that if you've got a tool to enforce a format, people stop thinking about the content, but still believe they're getting good commit messages because the tool tells them so. This makes it harder to convince them that content quality needs addressing. Worse, it gives you no flexibility to use the limited space in the commit header if you, the human, have a better idea of what the commit message should be than the tool has. It breaks muscle memory. For me, `git commit` is something that happens frequently - on the order of several times an hour, and not necessarily only in a single project. If the steps to commit are different from project to project, that's a mental speedbump every time I make a change, which pulls me out of flow and distracts me from whatever it is I'm doing. This is made worse when the commit format rules are in flux, because I then get tripped up within a single project. Lastly, it's Yet Another Thing That Can Break(TM), and a specific example of that pernicious class of Technical Solutions To Human Problems.

woile 8y ago
Hey I'm sorry you had problems with it. I myself don't use it always. My main idea is to make it easier for teams to share the commit conventions with new developers (at work, for example, there was other convention which I find it hard, so I made a plugin also for it). Sometimes I'm not sure what type of change it is, so I can trigger `cz commit` and the prompt helps me remember what is what and to choose a proper prefix. My main objective was to avoid writing lazy commits 'fixed api', which I've seen around. You don't need to use commitizen to write the commit, if you want you can choose conventional commits and write directly git commit, or use nothing. But if you use conventional commits, later you can use `cz bump` and detect the type of increment, and there are already tools that help you create a changelog as well. I'm using this stuff with some friends in a project we are working on, and we use conventional commits (whoever wants uses commitizen) for our git messages, and then after a PR is merged into master we can execute `cz bump` in our CI and we have a new relese ready to deploy.

woile 8y ago

Hey I'm sorry you had problems with it. I myself don't use it always. My main idea is to make it easier for teams to share the commit conventions with new developers (at work, for example, there was other convention which I find it hard, so I made a plugin also for it). Sometimes I'm not sure what type of change it is, so I can trigger `cz commit` and the prompt helps me remember what is what and to choose a proper prefix. My main objective was to avoid writing lazy commits 'fixed api', which I've seen around. You don't need to use commitizen to write the commit, if you want you can choose conventional commits and write directly git commit, or use nothing. But if you use conventional commits, later you can use `cz bump` and detect the type of increment, and there are already tools that help you create a changelog as well. I'm using this stuff with some friends in a project we are working on, and we use conventional commits (whoever wants uses commitizen) for our git messages, and then after a PR is merged into master we can execute `cz bump` in our CI and we have a new relese ready to deploy.