What does it mean to commit responsibly?

I'm working on a list of what it means to "commit responsibly." What would you change/add to this?

Committing responsibly

  1. Using meaningful variables
  2. Not committing bugs or broken builds
  3. Not leaving in dead code or print statements
  4. Formatting code to style specifications
  5. Using descriptive commit messages
  6. Only committing code related to the change described in the message (one change per commit)
  7. Providing documentation where necessary
  8. Providing tests where necessary
Did you find this post useful? Show some love!
DISCUSSION (6)
  1. It will compile/run!
    The most obvious rule of a commit is so often broken it crazy

  2. Has and passes unit test or at least says why it doesn't

  3. It follows the style guidelines we've agreed too

  4. Log message describes your code possibly referencing a story/job #

  5. DO NOT slip in un documented changes
    Seriously, as many anti-code commenting blog posts I've read. I've been considering authoring a rant entitled "Revision control logs considered useless". The number of pointless and otherwise incomplete log messages I've seen has me checking diffs before I look at messages

My list is shorter than you but for me your formatting, variables, and dead code items are covered by my follow the dang style guild

I think your working title for the rant is hilarious XD And you're right, I noticed this with PRs. I tend to go look at the diffs first, to get an idea of what's going on, and more often than not find random small changes.

Haha this made me laugh I recognize the frustration all too well.

A lot of these (the ones about the quality) I don't think are important in each commit, just so long as they're in place by the time you want to merge it into trunk/master.

For me, committing responsibly means you do git status to see what things have changed, you predict what you're going to see in the first file, you do git diff firstfile to make sure the change you see in that file is the change you expected to see. If you see something you need to change, you make the change and start again. If not, you git add firstfile to add it, and then you start over at git status, until you have the staging area built up to be the commit you want. This will make sure you know what you're committing (eg I've seen people accidentally commit random files, once it was even our private keys). This review will also help you write a good commit message.

Also, commit messages should be in present tense. It keeps them shorter and easier to understand.

Another great practice is to include the ticket number within commit message.

Especially in legacy projects, sometimes is difficult to know why a change was made.

This depends on the dev culture of a place, but I do like committing daily. If someone gets hit by a bus or wins the lottery, it's far easier for someone else to pick up where you left of if you have your stuff on origin.

I'd rather see someone committing jibberish often than waiting 2 weeks to push up a perfect commit with the entire feature in one go.

Classic DEV Post from Apr 6

Suggestions for using `...arguments` while working with functions in javascript.

In many situations, using arguments to pass the function args would lead to bug...

Vicky Lai
I'm a full stack developer with experience in startups and UI and UX design. I write about code, process, and becoming a better human.
  1. Read Post 🤓
  2. Follow Author 👋
  3. Profit??? 🤔