6 ms·

I like the conventional commit style [0]. You may have seen these in open source repos or used them at work. They look like feat: support new line chart fix:

I like the conventional commit style [0]. You may have seen these in open source repos or used them at work. They look like feat: support new line chart fix: update props for new line chart chore: bump dependency version What's also cool is there are tools (semantic release) that will then handle automatically the versioning and publishing of your module based on these commits using the commit type (feat, fix, chore etc) to determine the next appropriate version [1]. [0]https://www.conventionalcommits.org/en/v1.0.0/ https://www.conventionalcommits.org/en/v1.0.0/ [1]https://github.com/semantic-release/semantic-release https://github.com/semantic-release/semantic-release

_virtu 4y ago
I built a full pipeline around this. Basically allowed for a paved road for devs to automatically semantically version and deploy application and module artifacts for npm with semantic release by spinning up a repo with some boilerplate generators I made available to the team. Since then I've been obsessed with the conventional commit format everywhere for my own projects. Even if the commits aren't parsed for versioning, it just gets you into the habit of thinking about the scope of the commits. The laughable part about building that full paved road pipeline is that the biggest friction point was always when devs didn't use semantic commits. At the time when I implemented it I didn't have checks for the commit format at the pr phase. I DID have a commitizen cli option as well but that was "Too much friction". Oh boy did I get bit. As someone who was working on DX I was constantly surprised by how many questions I got about something as seemingly simple as the conventional commit format from a crowd of enginerds.
- tardismechanic 4y ago
  +1 on conventional commits (big fan) also, +1 on fully paved road approach! You might want to check out this GitHub Action to enforce PR title matches the spec: https://github.com/amannn/action-semantic-pull-request https://github.com/amannn/action-semantic-pull-request
- irrational 4y ago
  > I was constantly surprised by how many questions I got about something as seemingly simple as the conventional commit format from a crowd of enginerds. I'm not. Writing code and writing git commit messages take entirely different types of thinking. With code you are having to think logically and problem solve to tell the computer what to do. Git messages are more analogous to writing a term paper (though shorter). You have to think about the what you are trying to communicate, how best to describe what this commit is all about, maybe trying to figure out if this counts as a fix or something else, etc. Writing code is fairly easy for me. Writing git commit messages is extremely difficult for me. I sometimes go days without commiting because I'm dreading having to write a commit message.
  - rorytbyrne 4y ago
    I also have this problem, so I made a tool that lets you write your commit messages in-advance. It helps me to focus on one problem at a time. https://github.com/synek/git-plan https://github.com/synek/git-plan One feature I wanted to add was for it to parse your source code for comments with a specific format (e.g. `# git-plan feat xyz` or `# git-plan fix xyz`) and then stitch all the hunks together into commits for you. So all you'd have to do is comment your code and then run `git plan commit` and it would generate commits for you to confirm with y/n. I built a prototype of that here: https://github.com/synek/codeline https://github.com/synek/codeline I haven't worked these for a while unfortunately :(
- _ZeD_ 4y ago
  Oh, gosh.. no The commit messages are meant to be read by humans
- bern4444 4y ago
  I did this at one company too using commitizen to use a cli wizard for helping ppl get started (exposed it through an npm script, npm commit i think) but also setting up a commit linter that would run as a post commit hook and reject the commit if it was incorrectly formatted. It helps get everyone using it familiar quickly despite being annoying as you get used to it.
emacs28 4y ago
I've been using github-changelog-generator [1] for (you guessed it) automatic changelog generation, which adds bug fixes/features to the changelog based on issues and PRs, but sematic-release looks like it might be even more useful. [1] https://github.com/github-changelog-generator/github-changelog-generator https://github.com/github-changelog-generator/github-changel...
- ilammy 4y ago
  These "changelog generators" look to me like barking at the wrong tree, automation for the sake of automation, and attempt to skip the "boring" work of communicating changes by replacing it with "interesting" work of massaging git history, inventing microformats, etc. Why bother with separate changelogs at all then when you can see changes in `git log`. Just write good commit messages! /s
  - emacs28 4y ago
    Well rather than manually enter the bug fixes/features introduced in each release on the GitHub releases, you can just paste a link to the automatically generated changelog. This is less error prone and isn't meant to replace writing good commit messages.
    - est31 4y ago
      Yes, but you might present some feature differently internally compared to your users. E.g. "Update libfoo" is a totally fine commit message, as you can just inspect the diff to see the version change, but in the changelog, I'd prefer "Update libfoo to 0.3" because dependency versions are something that's exposed to users of your component. Conversely, you might have a bunch of refactoring commits that each are important as their own unit but your changelog is maybe only interested in a summary. Personally I don't see much value in these half-automatted changelogs over just giving git history. It also raises the bar for contributions because contributors have to figure out a non standard commit message format.
      - 4y ago
scoot 4y ago
Conversely I hate these with abundance. If you feel that working on your project is a chore, why are you still working on it?
- gunfighthacksaw 4y ago
  I don’t particularly enjoy cleaning my house but I love the aftermath. Same with bumping versions on dependencies. If I didn’t have to do it I’d love to just get the new features in a non-breaking way. But I can’t, so I do, and it’s a chore.
  - scoot 4y ago
    Interesting viewpoint, thanks for sharing it. I disagree, but at some point it becomes a personal perspective, so ultimately a point of philosophy.
- tjr225 4y ago
  Are you being serious?
  - scoot 4y ago
    Yes. Are you?
    - tjr225 4y ago
      Yup, you should re-evaluate. There are a jillion reasons to do things that are chores. The word chore should not be implicitly perceived as a negative thing. Do I want to clean my house? Yes. Is it still a chore? Do some thinking for yourself. I honestly have no idea what the heck you are talking about; hence my comment. Do you seriously perceive any chores as not worth doing? That sounds unhealthy.
      - Mawr 4y ago
        > There are a jillion reasons to do things that are chores. > Do I want to clean my house? Yes. Is it still a chore? > Do you seriously perceive any chores as not worth doing? None of these are relevant as to whether 'chore' has negative connotations. It clearly does to me and I'm baffled at the opposition. Do I want to clean my house? No of course not, and you don't either. If your house cleaned itself automatically would you still wish to do it? No, you do it because you need to, not because you want to. Just about every dictionary definition mentions chores as at least possibly considered negative: > a hard or unpleasant task: Solving the problem was quite a chore. ([1]) > A chore is a task that you must do but that you find unpleasant or boring. > She sees exercise primarily as an unavoidable chore. > Making pasta by hand with a rolling pin can be a real chore. ([2]) An entire article that wouldn't exist if chores were fun activities: [3]. > “Chore” can have a negative connotation and feel like a burden to a child. [1]: https://www.dictionary.com/browse/chore https://www.dictionary.com/browse/chore [2]: https://www.collinsdictionary.com/dictionary/english/chore https://www.collinsdictionary.com/dictionary/english/chore [3]: https://www.nspt4kids.com/parenting/take-the-chore-out-of-doing-chores/ https://www.nspt4kids.com/parenting/take-the-chore-out-of-do...
darylteo 4y ago
I prefer issue/card numbers as it makes it easier to visually group and search for common commits of a single task in shortlog. feat/fix/chore have no functional use in shortlog (for me!) and the mixed length moves the start of the actual comment and makes shortlog messy. That information can just as easily be put into the commit message. 2c. This is probably more appropriate for private projects rather than public contributed projects perhaps where the benefit of conventional style is to be able to easily create changelogs of large number of commits.
- ulflander 4y ago
  Why not both?
  - darylteo 4y ago
    Your commit topic shrinks to only 40-45 characters if you try to do both (card numbers get quite large too if you're in a jira context, with their issue prefixes PROD-001 is 8 characters already) so you pick and choose. The other thing is that in an internal context, what does knowing whether it's a feature or a bugfix do for you? If it's such a big issue, then it'd be integrated into the issue prefix BUG-001 FEA-002 < less likely as each feature epic will probably have it's own code, so it'll be more XXXX-001 XXXX-002 Now you have a nice short log that aligns nicely, and you can figure out mostly where your merge points were anyway, so no need for merge commits, rebase works mostly fine. - BUG-001 fix for this thing - FEA-005 initial commit - FEA-005 unit tests - FEA-005 implement this thing - FEA-005 implement that thing - FEA-005 fixes for code review - BUG-002 fix for another thing - BUG-002 revert fix did not work - BUG-003 fix for that annoying thing Of course, just my 2c and my limited personal experience.
- stevula 4y ago
  Conventional commits support a scope which can be an issue ID: `feat(37): add foo` The variable length is still a thing though.
fn1 4y ago
Interesting, after years of software-development I arrived at almost the same pattern: * [feature] -> a new feature, can be incomplete, but should be a contained unit of work that's usable to the enduser in some way. * [code] -> everything that improves the code, could be refactoring, library-updates or preparations for a feature * [bugfix] -> minimal commit only for fixing a bug, should (almost) always include a test to reproduce the bug. Sometimes I also use: * [build] -> for build-improvements * [performance] -> for performance-improvements
- beanaroo 4y ago
  After working on a number of projects that tried to apply conventional commits properly, I found something like this to be more effective and sustainable. Specifically, I'm quite fond of https://gitmoji.dev https://gitmoji.dev - Commit messages are shorter, even with ticket IDs. - Commit log is easy to read - Less prone to typos (chroe vs chore) - Easy to enforce with push rules - Easy to generate changelogs/release notes - Easy to measure (metrics) - Helpful IDE integrations - It's a bit more fun than conventional commits See https://github.com/tiangolo/fastapi https://github.com/tiangolo/fastapi for an example

_virtu 4y ago

I built a full pipeline around this. Basically allowed for a paved road for devs to automatically semantically version and deploy application and module artifacts for npm with semantic release by spinning up a repo with some boilerplate generators I made available to the team. Since then I've been obsessed with the conventional commit format everywhere for my own projects. Even if the commits aren't parsed for versioning, it just gets you into the habit of thinking about the scope of the commits. The laughable part about building that full paved road pipeline is that the biggest friction point was always when devs didn't use semantic commits. At the time when I implemented it I didn't have checks for the commit format at the pr phase. I DID have a commitizen cli option as well but that was "Too much friction". Oh boy did I get bit. As someone who was working on DX I was constantly surprised by how many questions I got about something as seemingly simple as the conventional commit format from a crowd of enginerds.

tardismechanic 4y ago
+1 on conventional commits (big fan) also, +1 on fully paved road approach! You might want to check out this GitHub Action to enforce PR title matches the spec: https://github.com/amannn/action-semantic-pull-request https://github.com/amannn/action-semantic-pull-request
irrational 4y ago
> I was constantly surprised by how many questions I got about something as seemingly simple as the conventional commit format from a crowd of enginerds. I'm not. Writing code and writing git commit messages take entirely different types of thinking. With code you are having to think logically and problem solve to tell the computer what to do. Git messages are more analogous to writing a term paper (though shorter). You have to think about the what you are trying to communicate, how best to describe what this commit is all about, maybe trying to figure out if this counts as a fix or something else, etc. Writing code is fairly easy for me. Writing git commit messages is extremely difficult for me. I sometimes go days without commiting because I'm dreading having to write a commit message.
- rorytbyrne 4y ago
  I also have this problem, so I made a tool that lets you write your commit messages in-advance. It helps me to focus on one problem at a time. https://github.com/synek/git-plan https://github.com/synek/git-plan One feature I wanted to add was for it to parse your source code for comments with a specific format (e.g. `# git-plan feat xyz` or `# git-plan fix xyz`) and then stitch all the hunks together into commits for you. So all you'd have to do is comment your code and then run `git plan commit` and it would generate commits for you to confirm with y/n. I built a prototype of that here: https://github.com/synek/codeline https://github.com/synek/codeline I haven't worked these for a while unfortunately :(
_ZeD_ 4y ago
Oh, gosh.. no The commit messages are meant to be read by humans
bern4444 4y ago
I did this at one company too using commitizen to use a cli wizard for helping ppl get started (exposed it through an npm script, npm commit i think) but also setting up a commit linter that would run as a post commit hook and reject the commit if it was incorrectly formatted. It helps get everyone using it familiar quickly despite being annoying as you get used to it.

emacs28 4y ago

I've been using github-changelog-generator [1] for (you guessed it) automatic changelog generation, which adds bug fixes/features to the changelog based on issues and PRs, but sematic-release looks like it might be even more useful. [1] https://github.com/github-changelog-generator/github-changelog-generator https://github.com/github-changelog-generator/github-changel...

ilammy 4y ago
These "changelog generators" look to me like barking at the wrong tree, automation for the sake of automation, and attempt to skip the "boring" work of communicating changes by replacing it with "interesting" work of massaging git history, inventing microformats, etc. Why bother with separate changelogs at all then when you can see changes in `git log`. Just write good commit messages! /s
- emacs28 4y ago
  Well rather than manually enter the bug fixes/features introduced in each release on the GitHub releases, you can just paste a link to the automatically generated changelog. This is less error prone and isn't meant to replace writing good commit messages.
  - est31 4y ago
    Yes, but you might present some feature differently internally compared to your users. E.g. "Update libfoo" is a totally fine commit message, as you can just inspect the diff to see the version change, but in the changelog, I'd prefer "Update libfoo to 0.3" because dependency versions are something that's exposed to users of your component. Conversely, you might have a bunch of refactoring commits that each are important as their own unit but your changelog is maybe only interested in a summary. Personally I don't see much value in these half-automatted changelogs over just giving git history. It also raises the bar for contributions because contributors have to figure out a non standard commit message format.
    - 4y ago

scoot 4y ago

Conversely I hate these with abundance. If you feel that working on your project is a chore, why are you still working on it?

gunfighthacksaw 4y ago
I don’t particularly enjoy cleaning my house but I love the aftermath. Same with bumping versions on dependencies. If I didn’t have to do it I’d love to just get the new features in a non-breaking way. But I can’t, so I do, and it’s a chore.
- scoot 4y ago
  Interesting viewpoint, thanks for sharing it. I disagree, but at some point it becomes a personal perspective, so ultimately a point of philosophy.
tjr225 4y ago
Are you being serious?
- scoot 4y ago
  Yes. Are you?
  - tjr225 4y ago
    Yup, you should re-evaluate. There are a jillion reasons to do things that are chores. The word chore should not be implicitly perceived as a negative thing. Do I want to clean my house? Yes. Is it still a chore? Do some thinking for yourself. I honestly have no idea what the heck you are talking about; hence my comment. Do you seriously perceive any chores as not worth doing? That sounds unhealthy.
    - Mawr 4y ago
      > There are a jillion reasons to do things that are chores. > Do I want to clean my house? Yes. Is it still a chore? > Do you seriously perceive any chores as not worth doing? None of these are relevant as to whether 'chore' has negative connotations. It clearly does to me and I'm baffled at the opposition. Do I want to clean my house? No of course not, and you don't either. If your house cleaned itself automatically would you still wish to do it? No, you do it because you need to, not because you want to. Just about every dictionary definition mentions chores as at least possibly considered negative: > a hard or unpleasant task: Solving the problem was quite a chore. ([1]) > A chore is a task that you must do but that you find unpleasant or boring. > She sees exercise primarily as an unavoidable chore. > Making pasta by hand with a rolling pin can be a real chore. ([2]) An entire article that wouldn't exist if chores were fun activities: [3]. > “Chore” can have a negative connotation and feel like a burden to a child. [1]: https://www.dictionary.com/browse/chore https://www.dictionary.com/browse/chore [2]: https://www.collinsdictionary.com/dictionary/english/chore https://www.collinsdictionary.com/dictionary/english/chore [3]: https://www.nspt4kids.com/parenting/take-the-chore-out-of-doing-chores/ https://www.nspt4kids.com/parenting/take-the-chore-out-of-do...

darylteo 4y ago

I prefer issue/card numbers as it makes it easier to visually group and search for common commits of a single task in shortlog. feat/fix/chore have no functional use in shortlog (for me!) and the mixed length moves the start of the actual comment and makes shortlog messy. That information can just as easily be put into the commit message. 2c. This is probably more appropriate for private projects rather than public contributed projects perhaps where the benefit of conventional style is to be able to easily create changelogs of large number of commits.

ulflander 4y ago
Why not both?
- darylteo 4y ago
  Your commit topic shrinks to only 40-45 characters if you try to do both (card numbers get quite large too if you're in a jira context, with their issue prefixes PROD-001 is 8 characters already) so you pick and choose. The other thing is that in an internal context, what does knowing whether it's a feature or a bugfix do for you? If it's such a big issue, then it'd be integrated into the issue prefix BUG-001 FEA-002 < less likely as each feature epic will probably have it's own code, so it'll be more XXXX-001 XXXX-002 Now you have a nice short log that aligns nicely, and you can figure out mostly where your merge points were anyway, so no need for merge commits, rebase works mostly fine. - BUG-001 fix for this thing - FEA-005 initial commit - FEA-005 unit tests - FEA-005 implement this thing - FEA-005 implement that thing - FEA-005 fixes for code review - BUG-002 fix for another thing - BUG-002 revert fix did not work - BUG-003 fix for that annoying thing Of course, just my 2c and my limited personal experience.
stevula 4y ago
Conventional commits support a scope which can be an issue ID: `feat(37): add foo` The variable length is still a thing though.

fn1 4y ago

Interesting, after years of software-development I arrived at almost the same pattern: * [feature] -> a new feature, can be incomplete, but should be a contained unit of work that's usable to the enduser in some way. * [code] -> everything that improves the code, could be refactoring, library-updates or preparations for a feature * [bugfix] -> minimal commit only for fixing a bug, should (almost) always include a test to reproduce the bug. Sometimes I also use: * [build] -> for build-improvements * [performance] -> for performance-improvements

beanaroo 4y ago
After working on a number of projects that tried to apply conventional commits properly, I found something like this to be more effective and sustainable. Specifically, I'm quite fond of https://gitmoji.dev https://gitmoji.dev - Commit messages are shorter, even with ticket IDs. - Commit log is easy to read - Less prone to typos (chroe vs chore) - Easy to enforce with push rules - Easy to generate changelogs/release notes - Easy to measure (metrics) - Helpful IDE integrations - It's a bit more fun than conventional commits See https://github.com/tiangolo/fastapi https://github.com/tiangolo/fastapi for an example