5 ms·

I prefer conventional commits, I have created a tool that prompts some info to make it easier to remember, I can also bump automatically the version using the

by woile 8y ago

I prefer conventional commits, I have created a tool that prompts some info to make it easier to remember, I can also bump automatically the version using the commits. I've been using it with friends with no issues. I really like how the commit log looks https://github.com/Woile/commitizen https://github.com/Woile/commitizen

jeena 8y ago
Your commit messages don't explain why stuff is happening. That might be ok for a private git repo, but once you have different teams working on it over several years it's not good enough.
- c3534l 8y ago
  What do you mean? Feat, fix, etc. Those are all short, instantly understandable explanations of why a change was made. If you're looking for an explanation for why the code itself was coded a certain way, that's not what git messages are for. That's what comments are for. You're explaining why you made the commit, not why you wrote the code the way you did.
  - intertextuality 8y ago
    "refactor: changed stdout statements" is a useless commit message. I should not have to manually open the commit to find out what was actually changed. The message should specify changed X to a. If it's too long, that's what the git commit description is for. The keywords are also redundant. I don't need to see doc) if the rest of the commit message reads "update README". That's obviously documentation. "style: black to files" ??? all that was changed was styling here with newlines and quotes. [0] --- To be frank, it's not that hard to write a good commit message. It just requires you to use your brain for more than .2 seconds to write a good, concise summary. Forcing yourself to do this also in turn makes you write better (concise, focused) commits instead of just shutting off your brain and following some tool. [0]: https://github.com/Woile/commitizen/commit/9cecb9224aa7fa68d4afeac37eba2a25770ef251 https://github.com/Woile/commitizen/commit/9cecb9224aa7fa68d...
    - woile 8y ago
      Oh wow, it's good to have some feedback, I do my best to write something explaining what changed, and what would make sense for someone reading that is not me, I guess I have to try harder. I do not agree that the tool makes you lazy, I think it actually forces you to write something, I've seen many other popular repos (like requests) that don't follow any conventions and they have commits like "fixed stuff", "more changes", etc. The prefix on the commit has the benefit that you can parse it and use it for something else, like to generate the semver, this doesn't mean you have to use conventional commits, but any convention. With commitizen you can make your own rules, and make it easy to share with new colleagues, it's better than pointing to a useless confluence lost in space and time, that was my idea at least.
  - jeena 8y ago
    I looked specifically at: "refactor: changed stdout statements" and had no idea why this has been done, what was the problem with it before it changed, how does the patch make it so the problem now gone?
regularfry 8y ago
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.
b212 8y ago
I’ve been using git for almost a decade now and I don’t understand how conventional commits work. The docs make no sense to me: https://www.conventionalcommits.org/en/v1.0.0-beta.3/#specification https://www.conventionalcommits.org/en/v1.0.0-beta.3/#specif... , full specification states there are only two types of them - fix and feat. Then they point you in the direction of https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING... and at this point I wasn’t even sure if there’s a golden standard or can I go with “anything: foo”? I really tried to use this methodology but as a front end had to push a lot of CSS changes and I didn’t know where they belong to, is it refactor if I change border color? Or maybe “style”? But according to the guideline style is for code styles like white space or missing semicolon but isn’t that refactor? I’m dumb maybe but I feel like it’s incredibly complex for such a small thing. If I move one Sass rule few lines up and the whole layout changes due to specificity changes - is it a refactor, new feature or style and what if it fixes a bug? :( Could you explain it to me? I’d love to stick to the naming once I get it, the profit seems to be quite big especially if in 10 years I want to let’s say parse and analyze my code. Thanks! TL;DR what commit type to use for css and what if one commit seems to fit for multiple types?
- woile 8y ago
  Hey great thing you are interested! Full story short, think about your public, and ask yourself: - Am I introducing a new feature to my users? -> feat - Am I fixing something, with no new functionality? -> fix - Is my change breaking the API for my consumers? -> add BREAKING CHANGE to the body of your message, no matter what prefix you are using. This 3 map closely to semantic versioning and are used in conventional-changelog. MAJOR -> BREAKING CHANGE MINOR -> feat PATCH -> fix Now, sometimes, this 2 prefixes might not be enough to describe what you have done. Maybe you introduced a new ci, that's no code, doesn't need to use one of the aforementioned prefix, so you use one of the optionaly proposed Angular prefixes (I think conventional commits is based on angular originally). Sometimes fix might not be good enough to describe what you changed, in that case you can use `perf:` or `improvement`, but remember that this changes should not introduce anything to your consumers, let's say you converted a sass code that was too repetitive into a for loop. TL;DR: use feat and fix, they map to semver and you can generate the changelog automatically. Examples and more info: - https://github.com/angular/angular/blob/22b96b96902e1a42ee8c5e807720424abad3082a/CHANGELOG.md https://github.com/angular/angular/blob/22b96b96902e1a42ee8c... - https://github.com/conventional-changelog/standard-version https://github.com/conventional-changelog/standard-version - https://www.conventionalcommits.org/en/v1.0.0-beta.4/#about https://www.conventionalcommits.org/en/v1.0.0-beta.4/#about Hope I was helpful, Regards!
deleted 8y ago
[deleted]

by woile 8y ago

jeena 8y ago

Your commit messages don't explain why stuff is happening. That might be ok for a private git repo, but once you have different teams working on it over several years it's not good enough.

c3534l 8y ago
What do you mean? Feat, fix, etc. Those are all short, instantly understandable explanations of why a change was made. If you're looking for an explanation for why the code itself was coded a certain way, that's not what git messages are for. That's what comments are for. You're explaining why you made the commit, not why you wrote the code the way you did.
- intertextuality 8y ago
  "refactor: changed stdout statements" is a useless commit message. I should not have to manually open the commit to find out what was actually changed. The message should specify changed X to a. If it's too long, that's what the git commit description is for. The keywords are also redundant. I don't need to see doc) if the rest of the commit message reads "update README". That's obviously documentation. "style: black to files" ??? all that was changed was styling here with newlines and quotes. [0] --- To be frank, it's not that hard to write a good commit message. It just requires you to use your brain for more than .2 seconds to write a good, concise summary. Forcing yourself to do this also in turn makes you write better (concise, focused) commits instead of just shutting off your brain and following some tool. [0]: https://github.com/Woile/commitizen/commit/9cecb9224aa7fa68d4afeac37eba2a25770ef251 https://github.com/Woile/commitizen/commit/9cecb9224aa7fa68d...
  - woile 8y ago
    Oh wow, it's good to have some feedback, I do my best to write something explaining what changed, and what would make sense for someone reading that is not me, I guess I have to try harder. I do not agree that the tool makes you lazy, I think it actually forces you to write something, I've seen many other popular repos (like requests) that don't follow any conventions and they have commits like "fixed stuff", "more changes", etc. The prefix on the commit has the benefit that you can parse it and use it for something else, like to generate the semver, this doesn't mean you have to use conventional commits, but any convention. With commitizen you can make your own rules, and make it easy to share with new colleagues, it's better than pointing to a useless confluence lost in space and time, that was my idea at least.
- jeena 8y ago
  I looked specifically at: "refactor: changed stdout statements" and had no idea why this has been done, what was the problem with it before it changed, how does the patch make it so the problem now gone?

regularfry 8y ago

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.

b212 8y ago

I’ve been using git for almost a decade now and I don’t understand how conventional commits work. The docs make no sense to me: https://www.conventionalcommits.org/en/v1.0.0-beta.3/#specification https://www.conventionalcommits.org/en/v1.0.0-beta.3/#specif... , full specification states there are only two types of them - fix and feat. Then they point you in the direction of https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING... and at this point I wasn’t even sure if there’s a golden standard or can I go with “anything: foo”? I really tried to use this methodology but as a front end had to push a lot of CSS changes and I didn’t know where they belong to, is it refactor if I change border color? Or maybe “style”? But according to the guideline style is for code styles like white space or missing semicolon but isn’t that refactor? I’m dumb maybe but I feel like it’s incredibly complex for such a small thing. If I move one Sass rule few lines up and the whole layout changes due to specificity changes - is it a refactor, new feature or style and what if it fixes a bug? :( Could you explain it to me? I’d love to stick to the naming once I get it, the profit seems to be quite big especially if in 10 years I want to let’s say parse and analyze my code. Thanks! TL;DR what commit type to use for css and what if one commit seems to fit for multiple types?

woile 8y ago
Hey great thing you are interested! Full story short, think about your public, and ask yourself: - Am I introducing a new feature to my users? -> feat - Am I fixing something, with no new functionality? -> fix - Is my change breaking the API for my consumers? -> add BREAKING CHANGE to the body of your message, no matter what prefix you are using. This 3 map closely to semantic versioning and are used in conventional-changelog. MAJOR -> BREAKING CHANGE MINOR -> feat PATCH -> fix Now, sometimes, this 2 prefixes might not be enough to describe what you have done. Maybe you introduced a new ci, that's no code, doesn't need to use one of the aforementioned prefix, so you use one of the optionaly proposed Angular prefixes (I think conventional commits is based on angular originally). Sometimes fix might not be good enough to describe what you changed, in that case you can use `perf:` or `improvement`, but remember that this changes should not introduce anything to your consumers, let's say you converted a sass code that was too repetitive into a for loop. TL;DR: use feat and fix, they map to semver and you can generate the changelog automatically. Examples and more info: - https://github.com/angular/angular/blob/22b96b96902e1a42ee8c5e807720424abad3082a/CHANGELOG.md https://github.com/angular/angular/blob/22b96b96902e1a42ee8c... - https://github.com/conventional-changelog/standard-version https://github.com/conventional-changelog/standard-version - https://www.conventionalcommits.org/en/v1.0.0-beta.4/#about https://www.conventionalcommits.org/en/v1.0.0-beta.4/#about Hope I was helpful, Regards!

deleted 8y ago

[deleted]