6 ms·

I built a full pipeline around this. Basically allowed for a paved road for devs to automatically semantically version and deploy application and module artifac

by _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.

by _virtu 4y ago

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.