DEV Community

Discussion on: Do You Cuss In Your Commit Messages?

Collapse
 
danazar96 profile image
Aidan Walters-Williams • Edited

Considering your git commits are a digital journal of what work was performed in an atomic unit, I don't see why you would ever cuss in a commit message? What use would that provide your future self?

Collapse
 
rachelsoderberg profile image
Rachel Soderberg • Edited

I am curious about this too. My commit messages revolve around the work that was done, and none my completed work involved something related to a curse word.

Collapse
 
jackharner profile image
Jack Harner πŸš€

I think it's safe to say my commit messages in general are not very helpful. Luckily so far it's only me working on things and most of my git usage has been for moving work from one computer to another/glorified backup.

I definitely need to get better with it though. How often do you actually commit? Every time whatever you're working on is "working"?

Collapse
 
danazar96 profile image
Aidan Walters-Williams

It's difficult to say how often you should commit - that is often down to the nature of the work you are carrying out. I guess an overarching rule would be "commit when you reach a natural stopping point in your work" but that is subjective and a lot of it depends on the environment you're working in (how big is your team, do you feature branch or commit straight to master, etc...) Moreover, that natural stopping point can be wildly different from ticket to ticket.

My general rule for naming a commit is "Describe what you achieved in the commit". So if I come across a piece of code 5-6 months later and I'm like "WTF is this for?!", I can git blame, check out the commit message and hopefully that will explain why it is there.

For example, my latest commit on one of the projects I'm working on at the moment is: "Add background job to build monthly categories after a MonthlyBudget is created"

Collapse
 
arturace profile image
Artur Madjidov

I find their use similar to docs that explain what a function, method, property, etc. does. It's not immediately useful, as you know what it does, but in the long run or if you work in a team, it provides the ability for the programmer to never need to see the code. You explained what something does with a standard human language and by doing so, saved time.