blog/conventional-commit-with-githooks

[utterances-bot]

How to customize Conventional Commits in a .NET application using GitHooks - Code4IT

Using Conventional Commits you can define a set of rules useful for writing meaningful commit messages. Using NPM. Yes, in a dotNET application!

https://www.code4it.dev/blog/conventional-commit-with-githooks?utm_source=csharpdigest&utm_medium=&utm_campaign=1519

[Tiberriver256]

Great writeup! You might be interested to know there is a .NET port of Husky. It's essentially the same except it ties into the nuget restore hook instead of the npm install hook.

https://alirezanet.github.io/Husky.Net/

[maroonedsia]

Thanks for the great article! There is one part of the "Conventional Commits" concept that confuses me. I usually create "branches" for tasks, e.g. Jira tickets, and then a task will be implemented by multiple commits. So as an example, my branch name would be "feat: add feature A to the checkout" and then the commits will be "Add business logic", "Fix typos in strings", "Update docs", "Format code files", "Bump up the version", etc... This is based on the principle to minimize each commit to a unit of change/update, instead of having one big all-in-one commit. Could you please explain if my approach is wrong, relative to your article? Thanks! 👍

[bellons91]

@Tiberriver256, wow, I totally missed that! Thanks, I'll try it out for sure (I already have in mind an article that might be perfect to toy with Husky.Net! )

[bellons91]

@maroonedsia, IMO your approach can work pretty well if you squash your commits before completing the PR. Otherwise, your GIT history will be something like

• Merge feat: add feature A to the checkout into master
• Add business logic
• Fix typos in strings
• Update docs and so on.

This means that, just by looking at the git history, you lose the information about the relation between a commit and its Jira task.

On the contrary, if you squash your commits when closing the PR, your GIT history will be smaller and with all the info about each task - but you'll lose the details of each commit.

So, I don't think there's a right approach: pick the one you prefer and that brings more value in the long run.

[bellons91]

@maroonedsia, if we're talking about the approach I explained in my article, consider that the GIT hook runs before each and every Commit, so you'll never end up with just Add business logic because the hook forces you to specify the type and the scope of the commit.

I'd totally follow the principle to minimize each commit to a unit of change/update - I think it's the best approach.

[maroonedsia]

@bellons91 Oh, I had no idea about the "squash" feature, thanks for mentioning that! 👌 BTW, I just found another nice tool for automatic versioning, using conventional commits: https://github.com/versionize/versionize Cheers! 😎