Commit like your life depends on it!

Your git commit should espouse certain syntactical rules like your life depends on it. Paying attention to the little details in formatting and word-choice can make all the difference in what creates a good commit.

The best types of commits have these characteristics:

  • Subject line 50 characters or less
  • Body 72 characters or less
  • Body and Subject separated with blank line
  • Does not end in period
  • Subject line capitalized
  • Written in imperative case

“If applied, this commit will”… [insert actual commit text here]

This structure adheres to how git might actually make a default commit for you if using git merge or git revert.

If applied, this commit will '(doc) update readme to reflect added map feature'
  • If using a body, use the commit to describe the what and why, as opposed to the how

Each commit is prefixed with :

(feat)

— Add a new feature

(fix)

— Fix inconsistent tests

(refactor)

— Make improvements to nonfunctional attributes while sustaining existing behavior. [ex — refactor to ES6]

(cleanup)

— Tidy code , remove console.logs, etc—

(test)

— creating code to specifically test functionality that may not be kept

(doc)

— Add specificity to docs, readme, etc

Following these simple guidelines will afford the members of your team and whomever has the good fortune to peruse your repo in the future the ability to know exactly how you manipulated your code without seeing the code itself. If a team member desires to revert to a previous commit while working on a project, they need only spend a few minutes deciding which detailed commit to return to, instead of hours reading code line by line. Sometimes, in the case of a particularly nasty bug, you may be saving your team a solid day+ of work and/or backtracking if you used a *slightly* more detailed commit. Something to think about…

Like what you read? Give Tourné Torres a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.