Git Tips

Git is flexible and lightly opinionated about how you use it.  It's adaptable to you, your team, and the way you want to work.  But with that power comes some responsibility.  Here are a few helpful tips I've learned working with Git over the years:

Beware Git alias commands

It stops being fun to type out git status about three days into learning Git, so it makes sense to create a handy alias like alias gs='git status', which I did.  I now type gs so often, and so reflexively, that it bypasses my conscious thought process (if I got a dollar every time I opened Ghostscript on a server, I'd have like 34 more dollars) — wherein lies the danger.

Tip #1 : Don't alias mutative Git commands.
 

You should carefully consider which commands you decide to alias.  Git is a sharp tool with few safeguards.

Be intentional about the commands like merge, push, and pull.  Make yourself type out these commands and their flags, especially if you need to add --force.

Initialed Branches

When I say initialed branches, I mean branches that start with the author's initials, e.g. rf-add-webscale.  They are the same as feature branches, e.g. publishing-workflow, except with a few conventions.

Tip #2 : Use initialed branches as convention.
 

An initialed branch is significant for a few reasons.  At a glance, you know the owner.  It makes it obvious who is in control of the branch and (side tip) who to bother when there are one million branches left hanging out on your remote repo.  It lets you know what features are being tackled and by whom.  It's a standing invite to collaborate with that person and a warning not to update or fork from that branch without that person's permission.  Finally, you can safely rewrite history (rebase) on your initialed branches — which is great for amending pull request feedback directly into relevant commits.

Commit Messages

This is easily overlooked, but it's worth considering, and I couldn't possibly say it better than this:

Tip #3 : Commit messages matter, listen to Tim Pope.
 

I'd add this thought — avoid low information commit subjects.  "Fixed", "PR feedback", "Bug fix" don't mean anything to the reader.  You can improve your subject by being mindful:

• What was the purpose of this change?
• Who is the audience?
• What has changed that isn't obvious in the code?
• How will this look in context with commits before and after?

Don't end up here.  You've just finished excellent changeset so give it an excellent commit message!

Do you have comments or tips you'd like to share?  Join the conversation below!