Ryan Foster, Former Developer
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
pull. Make yourself type out these commands and their flags, especially if you need to add
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.
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!