Clean Git

I think you will commit as deliberately as you code. If you believe in the careful following of clean code principles, your git patterns will reflect that.

Here are 3 suggestions that I have to improve your git game:

Use a GUI tool

There are 2 big reasons why you should start using a GUI tool (like sourcetreeapp.com).

Know what you’re committing

My parents are great, and generally wise, but they recently bought a mini home without looking at it. They learned a valuable lesson, and the bottom line was: don’t buy something expensive without looking at it first.

Please don’t commit a code change set without previewing your changes first.

Using a GUI shows me what I’m about to promote to my staging area, then what I’m about to commit. I can review hunk by hunk. I’m scanning for any accidental console.log(), commented out code, and aesthetically clean and simple code.

Make best practices easy to do, or you’ll never do it

Most of us know the very limited, basic commands in the terminal for git. When we need to do something more complicated, we look it up on StackOverflow and copy it.

For example, let’s say that you notice that you accidentally committed a console.log() 3 commits prior. How many people would know, off the top of their head, how to rebase interactively so that you could remove it from the commit where it was introduced? More importantly, how many would go to the effort to do so, instead of just doing the easier, lazier sin — adding a new commit with the message: “removing accidental console.log() 🤦‍♂”?

I rewrite history all the time, because my GUI makes it easy for me to do that. When we make good practices easy, we will do it more often.

GUIs often have other functionality that promote best practices, such as reminding us to pull in master frequently and spell checking.

I use a combination of terminal + GUI, depending on what I’m doing. Don’t think it’s cool to do things the hard way all the time — unless you also wash your clothes by hand, heat your food by fire, and lookup definitions in paperback dictionaries instead of Google.

Commit intentionally

We can borrow many of the same principles of clean code. For example:

+=========================+========================================+
|       Clean code        |               Clean git                |
+=========================+========================================+
| Keep functions small    | Keep commits small and doing one thing |
| and doing one thing     |                                        |
+-------------------------+----------------------------------------+
| Loose coupling          | Keep commits reversible                |
+-------------------------+----------------------------------------+
| Test driven development | Commit passing tests alongside code    |
+-------------------------+----------------------------------------+
| Modular and composable  | Commits should be organized and atomic |
+-------------------------+----------------------------------------+

I think you will commit as deliberately as you code. If you believe in the careful following of clean code principles, your git patterns will reflect that.

Refactor commits before pull requests

With the best of intentions, before you submit a pull request, your git commit history may look like this:

993b02fc - responding to PR feedback
e2b06220 - changing e -> event
8df2ac92 - Merge branch 'master' into my-branch
e6ff3f50 - removing console.log() - oops
0b66ba88 - test: update failing test
cdefb756 - refactor: making page container handle loading case
c0daac11 - fix: loader wasn't working on details page
6338a8b6 - feat: adding spinning loader

This isn’t extreme at all — and this may seem familiar to many people! But this is sloppy, plain and simple, for the following reasons:

• Tests should generally be committed alongside code, not on it’s own (that keeps commits reversible)
• Sloppy-mistake-fixing commits shouldn’t be their own commit — edit a previous commit
• Don’t use git merge master. Use

git pull origin master --rebase

• (optional) Refactor first to make features easier to code

You can clean this up, using a GUI tool, rebase interactive, and lots of other little tricks.

80b8babb - feat: adding spinning loader
e84dcfa5 - refactor: making page container handle loading case

Bottom line: you don’t always get it right the first time. Add to previous commits, squash commits, move stuff around, edit messages, etc. People will be going through this history for many years to come — make it look like you care.

Summary

You don’t want this to be you:

Source: unknown

So be a little more conscious of your work in git. Use a GUI tool, commit intentionally, and refactor your commits.