DEV Community

Cover image for Are You Writing Your Git Commit Messages Properly?

Are You Writing Your Git Commit Messages Properly?

Rabin Otieno on May 26, 2024

When it comes to version control, Git is a very effective tool. However, like any other tool you have to use it the right way to get the most out o...
Collapse
 
sillybreakfast profile image
breakfast

thank you for this info!! i won't write commit messages like shfkgkdjejene anymore

Collapse
 
jhulten profile image
Jeffrey Hulten

Also, this is what squashing commits was made for (provided you are still on an isolated branch you can force push). Commonly squashed commits for me are:

  • take 1
  • take 2
  • take 37
  • ffffffffuuuuuuuu
  • am I dyslexic?
  • I hate everything
  • I AM A GOD!
Collapse
 
documendous profile image
Documendous

Yep, well said.

Collapse
 
melroy89 profile image
Melroy van den Berg

Or updated Readme.md. I hate those commits.

Collapse
 
martinbaun profile image
Martin Baun

Hehehe

Collapse
 
allwelldotdev profile image
Allwell

😅

Collapse
 
linkbenjamin profile image
Ben Link

...wait, so

"...in which our hero bravely fixes an off-by-1 error because of arrays that begin with 0 instead of 1" isn't valid? 🤣

Collapse
 
jhulten profile image
Jeffrey Hulten

If you and your team are consistent in writing commit messages in the style of the Hero Journey, great!

Collapse
 
katafrakt profile image
Paweł Świątkowski

It is valid and better than conventional commits

Collapse
 
alxwnth profile image
Alex

I’m adopting this!

Collapse
 
akindejihill profile image
Akindejihill

The non-conformist in me is yelling "You can't tell me how to write my comment's FU! finger. While the part of me that wants to get a job is somewhat grateful, yet still put off. Future experienced me who knows what pipelines and automation are thinks the other two me's are stupid.

Collapse
 
graphei profile image
GRAPHEI

Fix(individualism)!: modify perspective

Modify perspective to magnifying the power of teamwork, inorder achieve gainful employment.

BREAKING CHANGE. Fix #fu-00100

Collapse
 
documendous profile image
Documendous

Understood. It's good to find balance as you get more experience to know when to conform and when not to. Great point. Thanks for the post!

Collapse
 
habutre profile image
Rogério Ramos • Edited

TBH I don’t like conventional commit messages because in my opinion commit messages should naturally speak about the change not needing a prefix to tell whats is the change itself. Try to automate something (CI/CD) via commit messages for me is a misuse, the message should say what the changeset is doing and not what to do with the changes
What your pipeline will gonna do with “fix: foo bar” change? Test or Deploy the code, does not matter the prefix. Breaking change? Ok the deployment process will stop by “reading” this prefix?
I do believe documentation, knowledge sharing, strong pipeline processes are more effective than conventional commit messages, and also I know this comment is fully of bias 🤣

Collapse
 
ademagic profile image
Miko

agreed, relying on commit messaging for some CI/CD function is a misuse, and too risky. They're super hard to enforce anyway, and with standard/conventional commit messages there's still a lot of flexibility.
IMO conventional commits make scanning git history by humans much more effective. Adding any structure to something that differs so much per developer goes a long way. Teams can share scopes, types imply severity (or at least demand different levels of attention), and all of it forces us to easily give context that we often forget about.

My team of 6 uses Commitizen Conventional Changelog in our projects. No complaints so far.

Collapse
 
mevrin profile image
Matthieu Evrin • Edited

I'd say it often depends of the developer team maturity and size, it could be helpful to enforce standardization.
But totally ok with the second part

Collapse
 
documendous profile image
Documendous

This is a great format but better for branch descriptions as a branch fix or feature can have many, many commits. One I worked on the other day to add a nice drag and drop feature for files had about 120 commits by the time I was done. Still, the spirit of the format works well for any of the commit messages. Thanks for the post!

Collapse
 
tbroyer profile image
Thomas Broyer

I'm afraid your first 2 examples aren't actually written properly, in that the description doesn't really convey what the commit does and one has to go read the body (which requires additional user actions when presented with a list of commits showing only the description, as is frequently the case)

Here are how I would have written them (still following conventional commits, that I dislike for… reasons):

chore(Art_func): consistently use "empty" variable name casing
Enter fullscreen mode Exit fullscreen mode
fix(database)!: accommodate only structured data

Dismiss all other types of data.
Enter fullscreen mode Exit fullscreen mode

(I'm sure they can be improved, this is only showing how what you put in the body would better fit in the description)

Collapse
 
documendous profile image
Documendous

Honestly, I like your opinion a little better than OP's. Thanks for the post.

Collapse
 
adriens profile image
adriens
Collapse
 
documendous profile image
Documendous

Very good point!

Collapse
 
allenz_1011 profile image
allen_z • Edited

Excellent article on the importance of well-crafted Git commit messages! As a developer, it's crucial to maintain an organized and informative commit history to ensure seamless collaboration and make the codebase more navigable.

To further improve your Git workflow, you may want to consider incorporating some tools to simplify the process of writing commit messages. For example, the Leiga IDE plugin can create code commit templates to easily bring issue information into Git commit messages, while also making it easy to update issue status, allowing developers to focus on work in the IDE: Leiga

Image description

Collapse
 
sabrine_drira_6c0faceb133 profile image
Sabrine Drira

@allenz_1011 It looks interesting! I just need to know if there is a confidentiality concern with Leiga, considering it will be used with VS Code (code exposure)?"

Collapse
 
drewpayment profile image
Drew Payment

Check out this CLI tool to help write your got commits for you!

github.com/di-sukharev/opencommit

Collapse
 
chandrashekhar profile image
Chandrashekhar Mehta

thanks for explaining this messages in detail, I didn't know it before.

Collapse
 
zakari714 profile image
Zakari Adamu

Awesome. This was really a game changer to committing properly now.

Collapse
 
emelie profile image
Chukwuemelie Obiora

Thanks for sharing

Collapse
 
ppaanngggg profile image
ppaanngggg

thanks for sharing, there are some tools can help writing commit messages

Collapse
 
jhulten profile image
Jeffrey Hulten

I use commitizen to both provide a pre-commit hook and automate the questions to build a message.

github.com/commitizen-tools/commit...

Collapse
 
barsie profile image
Sirineo Barila

Amazing! 😊 thanks! 🙏
This is extremely helpful!

Collapse
 
jmccabe profile image
John McCabe

Fascinating. I'll add this to my extensive list of articles on "how to write a good commit message"

Collapse
 
michlutkhebee profile image
Michael lutta

Asante bwana otieno. I've actually learned something new today🙏

Collapse
 
thexdev profile image
M. Akbar Nugroho

The terms of "proper" git message is subjective topic. It depends on what organisation you working at. Conventional Commits, like it's name: Conventional. It just list of conventions about how you write/structure your commit message.

The question is, does the company public like Open Source project over there? If yes, sure you are in the right path. But, what if it's not? Using conventional commits just add another space for complexity (based my experience).

So, any better way?

Ofc, here's how:

  • Track any changes with issues. Make it detail
  • Create new branch using issue number. Ex: issue-64, issue-90, etc.
  • Commit message should represent your changes no mather how you describe it. Ex: distribute incoming request using Node child process (fork) or bump React version from x to y. Clear, concise, simple.
  • Relase & tagging. The message? Summarize what issues are closed and PR related to it.
Collapse
 
albertguedes profile image
Albert R. C. Guedes

I only use:

  • add
  • change
  • doc

for all :-D

Collapse
 
blafasel3 profile image
Maximilian Lenhardt

Ticketnumber which spawned the branch you are merging from + short description is enough in my experience. It's either redundant or totally unnecessary to add more info into a commit imo. Chances are very high it's not correct anyways because it differs from the actual implementation (as comments tend to do as well) and most of the time, people will step right to the code anyways.
Documentation of what and why should be in the ticket or in actual design decisions if necessary. Commit message feel too cramped and overloaded this way imo.

Collapse
 
katafrakt profile image
Paweł Świątkowski

Chances are very high it's not correct anyways because it differs from the actual implementation (as comments tend to do as well)

Comments do that not because of inherent nature of the comments, but because usually the implementation changes later, but comments are not updated. Commit messages are strictly for the point in time, so they do not suffer from this.

most of the time, people will step right to the code anyways

Absolutely true. Because we are used to read (and write) shitty commit messages. When you work with someone who actually writes useful and descriptive messages, you just read them. No special adapting required.

Documentation of what and why should be in the ticket or in actual design decisions if necessary

The conventional answer here is: what if you don't have access to the ticketing system? It is usually shrugged off because - why wouldn't you have it? It's 21st century and we have internet access everywhere. I was the one to dismiss this argument too.

However now I work on the project which switched from JIRA to Linear in it's early days. The links to JIRA tickets simply don't work (the tickets were migrated, but the naming convention changed during the process). And I have been scratching my had few times, wondering why the author made that change, with no chance to get any answer.

Collapse
 
stellaacharoiro profile image
Stella Achar Oiro

Thank You Ray, now I know how to write git commit messages properly.

Collapse
 
documendous profile image
Documendous

Does this work with pre-commit?

Collapse
 
andytamata profile image
andytamata

So "WIP" isn't a good commit message?

Collapse
 
zxxngod profile image
Zan XX

No :((( i need a guideline

Collapse
 
jinishjohnson profile image
jinishjohnson

Some of the data's are not available on My git