What does it mean to commit responsibly?

twitter logo github logo ・1 min read

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
twitter logo DISCUSS (6)
markdown guide
 
  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 Dec 11 '18

Do we really need classes in JavaScript after all?

Did classes deliver, what they promised? In this post, I share my thoughts about common classes pitfalls and possible solutions for creating better web development.

Victoria profile image
👩🏻‍💻 I help companies save ~65% of time spent on tech hiring with ApplyByAPI.com, and write articles about coding and becoming a better human at Victoria.dev

Sore eyes?

dev.to now has dark mode (in public beta).

Go to the "misc" section of your settings and select night theme ❤️