Look: I’m a saver. I like to save things. Ask anyone who has seen my plastic takeout container collection. Ask my friends who text me reminders to eat the fancy cheese I bought myself, because I think of it as a nice thing and therefore save it indefinitely until it goes bad.
A granular, decentralized version management system for code appeals to me on principle.
Proficiency with my version management tool also gives me the confidence to check out a branch and get ambitious without worrying about breaking the code base. I do a lot of mentoring and I have to confess, it makes my teeth itch to watch people leave commented-out code all over a file because they’re afraid they’ll need it later. Check out a branch! Rip that shit out!
I can scarcely blame them for their anxiety, though. Git’s power far outstrips its discoverability, which makes it a devastatingly useful tool, but also a terrifying one. Even seasoned programmers can accidentally do something with git before they understand what they did; just this week, I managed to accidentally amend a commit with changes that were meant for a new commit. I was pairing with another very experienced colleague, and it took us both a few minutes to figure out what had happened.
Here’s the thing: if your comfort with git ends at ‘push’ and ‘pull,’ that scenario sounds like a nightmare. But because we’re comfortable in git, it was no big deal: we reset the commit, stashed the files we had changed, re-amended the last commit, then popped the stash and made our new commit. It took about four commands to fix it. We laughed about it once we realized what had happened (the culprit: me, going way too fast, go figure).
If you’d like the git-tastrophe to go from “my worst fear” to “something to laugh about,” hopefully these videos can do that for you. Their combined runtime is about an hour, with two goals:
- Lay out the basics to help you understand your changes
- Tell you about the big guardrails that, if you always commit your changes and never cross those guardrails, you won’t lose your work. (This is why my colleague and I weren’t worried. We knew we had committed, so we knew the work wasn’t lost, and we knew not to do any of the things that could lose the work.)
The basics: what’s going on and how can it help me?
In this first video, we address questions like:
- What, actually, is a SHA?
- What, actually, is a commit?
- What, actually, is a branch?
- How do SHAs, commits, and branches help us do our programming work with more confidence?
- Why would I want to look at my commit history?
- What commands can I use to make looking at my git history more useful?
- What commands can I use to have more control over what I commit?
- What do those commands mean that I copy and paste onto my command line from GitHub every time I make a new repo?
I assure you, you’ve never seen git taught like this. If you had, I wouldn’t have needed to make this 😉. As is the case with most of my talks, this one is designed to be accessible to relative beginners, but EVEN YOU GRIZZLED OLD HANDS AREN’T SAFE from learning a new command or two!
Now that you’ve got a lay of the land and some slick commands you can use to make your life easier. …
The second video covers preserving your work.
Believe it or not, there are only three ways to lose committed work in git. It’s a lot easier to lose uncommitted work. So we’ll talk about:
- How to lose committed work in git (basically so you know that, if you didn’t do one of these three things, your work IS still there somewhere)
- How to use the stash and the reflog to find work that you KNOW is still there, but can’t seem to locate
- Tactics for committing more regularly so you can be confident that your work is not lost without creating a train of “WIP” commits
In short, the first video gives you some tools to make you look and feel like you know what you’re doing, and the second video gives you the safety ropes so that you’ll know, even if you end up in a spot where you don’t know what you’re doing, your work is saved for you to recover once you figure out your bearings again.
That kind of guarantee can be invaluable for freeing you up to experiment with your codebase, or even with git commands themselves, without worrying about messing things up :). Enjoy!
If you liked this piece, you might also like:
How to Jump-Start a New Programming Language, or maybe, even, gain a more concrete mental model of the one you already use!
Lessons from Space: Edge-Free Programming, which also explores an Android app’s design and the engineering choices behind it (plus, cool pictures of rockets!)
How does git detect renames?—This piece is about how git detects renames, but it’s also about how to approach questions and novel problems in programming in general.