DEV Community

How I write Commits like a pro

phukon on April 08, 2024

Crafting effective commit messages is a hallmark of experienced developers. Embracing the Conventional Commits specification stands as a beacon for...

Read full post

Abdelrahman Ashraf • Apr 8

Thanks for sharing

I use this tool: github.com/streamich/git-cz, which is a CLI-guided tool to create awesome commit messages as well.

Paul Isaris • Apr 11

Very cool! Thanks for sharing!

phukon • Apr 9

this is so cool!

Christian Baer • Apr 10

While the intent is good and for the most part this guideline is ok, I really do not like commit messages tell me what was done to the code. I can see that, when I look at the code. I want to know why this was changed. So please do not tell me, that you "changed the build process". I can see that. What I cannot see, by looking at the code is why we changed the build process. A message like "build process was taking 20 min, now takes 2" with some explanation in the body is way better. "Resolve issue with search feature" is also something, that I can see by git show --name-only pretty quickly. But what was the issue?
"Add a new rating component". Yes... I can see that you inserted a new file in folder 'rating-components' that pretty much gave it away already. What rating component? Is it replacing the old one? Is it country specific? Gender specific? (Don't flame me for this, that shit happens in real life)

Botton line: Having a what is better than nothing (aka 'Did stuff'), but having a why is even better.
Why > What > Nothing.

Shenouda Fawzy • Apr 10

Good day Christian Baer, what if the product is +100K line of code, don't you think that 'What' is the most important thing in the commit message than 'why', otherwise whoever reading/reviewing might get lost.
For the 'Why' it's even more important, cause without it then it's pointless to do write whatever code is, but in context of the message commit, I prefer 'what' over than 'why' which could be described on the issue/ticket itself. And leave the commit message to 'what' is actually changed to achieve the task (that has the why)

xtofl • Apr 17

Funny sidemark: we currently use a template that features both why and how:

feat(SF-123): Show SNP percentages

Why? because assay designers need to estimate how often
the base occurs in each designed primer

How? add 'frequencies' member to HTMLChar, and use it in
the dialog box.

Solar • Apr 11

In my opinion, I think one can use the what as description and then include the why in the body of the commit. that way, both are fulfilled.

Kyle Martin • Apr 10

Why would one pull request encompass 100k+ lines of code exactly?

Borzoo Moazami • Apr 8

Nice post, thanks for sharing.
Also I think it worth to think about what we've done when trying to write the description.

For example there are times when we fix a bug by changing something in x.ts file.

Appropriate commit message would describe what issue we have resolved not what we changed in x.ts.

BTW thats my idea and I had better experience during reviewing more meaningful commits and don't know if it is a rule or something.

Thank you again.

anes • Apr 9

Also important to mention: Commit messages tend to be in the present and imperative.
E.g: Implement search feature.

Faber Andrés Vergara • Apr 10

Excellent post! The online tool that we use in the company where I work and has helped us with the commits is: commitlint.io/

Wei Lee • Apr 11

Thanks for sharing! Would like to share this tool github.com/commitizen-tools/commit... which can help creating commit based on different rules (including convention commit)

Frank Connolly • Apr 19

I tend to use feature branches so the scope part of the commit message is usually obvious based on that. Other than that I would steer towards this format as much as possible

Eag • May 4

Thanks for sharing ! I'll be sure to make my commit messages more precise.

Jeremiah Smith • Apr 26

I've been tossing a gitmoji at the beginning of commit messages these days. It offers similar categorization and makes it simple to see the intention of a commit at a glance.
gitmoji.dev/

Tay • Apr 28

Thank you, this has been very helpful!

Md Kawsar Islam Yeasin • Apr 24

I would suggest to use commitlint if anyone want to preffer this kind of commit.

commitlint + husky is a perfect combinations.

Kevin Glez • Apr 20

Aws!!

Alayande-442 • Apr 11

Thank you boss🙏

Ahmad Adibzad • Apr 11

Nice post, thanks for sharing.

Hamza Zahidul Islam • Apr 10

Thanks brother 😀

Jitendra Choudhary • Apr 9

Nice article

Gad Iradufasha • Apr 9

Nice post, Most developers don't care about the message provided in their commit messages!

ppaanngggg • Apr 9

Good example, thanks

PatriciaIsaacs1997 • Apr 11

Thanks for the share!! I'm just getting started with Github and this will be something I start implementing from now on.

Madhu Saini • Apr 9

Thanks for sharing!!

lordhazan • Apr 28

Thank you

Aaron Potter • Apr 24

Thanks. Great share.

Hannah Alcott • Apr 12

Good post!

Daniel Hofman • Apr 12

Fantastic insights on professional commit practices! If someone is looking for a tool to further enhance this process, consider checking out CommandGit app. It's designed to streamline Git operations.

Pedro Masson • Apr 8

Nice article, thanks for sharing your insights

acudworth3 • Apr 9

Has anyone found a good tool/extension to do this in vscode source control? I believe in this convention but it doesn’t play nicely with the small commit message window in vscode gui IMO. plus I’d rather it mostly be selectable from a menu of possible.

Daniel González García • Apr 17

marketplace.visualstudio.com/items...

We use this one in my team. Works nicely with our flow

ayugup93 • Apr 9

Some of the example commit message that I use are(Just for reference) :-
git commit "Initial Commit"
git commit "API Feature Completed"
git commit "Resolved comments for PR"
git commit "Merge developer PR's"

uzeyir-yariz • Apr 27

İ learn more English

Mariusz Nowak • Apr 11

Following this for a while.

One thing that started to bother me is why "docs" and not "doc" (in other cases we use singular form, e.g. "test" not "tests", "style" not "styles" etc.)