Just enough Git (to snapshot your code)

Git won the version control system race. GitHub has over 220 million repositories, and it's not the only public Git hosting provider in town. Even BitBucket stopped supporting the main competitor, Mercurial, back in 2020[1].

But it can also be extremely difficult to use (at least, when anything but the most basic workflow is used). At my day job, it's one of the hardest things to teach new coders, students, and researchers (who just want to know enough to create checkpoints in their code). It's one of the tools that trips up junior developers the most, and elicits the most "I think I've broken my code" questions.

It was designed for managing the source code of the Linux kernel, a huge project with 26m lines of code[2] and hundreds of active developers, so it needed to be efficient and flexible (supporting workflows like exchanging patches by email). In industry, individual teams often define their own workflows and choose the features they want to use (like Large File Store and rebase); contributing to a project for the first time usually means learning how they use git.

But none of this should scare you off using Git. Using a little bit of Git is better than using none at all, and for a solo developer or a small team, this can be as simple as using Git to create snapshots of your code that you can roll back to.

Snapshotting your project

If you're just getting started, and want to move on from doing things like cp -r myproject myproject.bak.20241123 before making changes, you can still get a lot of benefit out of Git by just using it to take point-in-time snapshots of your code.

I've been making software for a very long time, and 90% of my Git interactions on my own small projects are done with two really simple, lazy Bash/Zsh functions:

function lazypush() {
    git add .
    git commit -m "Snapshot"
    git push
}

function gca() {
    git add .
    git commit -m "Snapshot"
}

gca ("Git Commit All") commits all the changes in the current repo with the comment "Snapshot". And lazypush does the same, then pushes to the remote repository.

And that's it. It's probably the laziest way to use Git, but most of the time all I want to do is create a snapshot that I can roll back to. I don't even care about the comment[3]. My ideal UI would be a single button that says "Snapshot" and a slider that lets me scroll back to point in time.

Of course, if you're working with other people then you'll need to learn about merges (to incorporate the changes your collaborators have made), branches (to make experimental changes or use more complex workflows), diffs, and interrogating the log.

When you do need to skill up in Git, take a look at the Git book - it's free, really well paced and covers everything you need to know.


  1. And for what it's worth, I much preferred Mercurial. It was simpler, Python-based (so at the time, more easily hackable) and much more approachable for newbies. ↩︎

  2. Per sloccount against linux-6.12. ↩︎

  3. When I'm working alone. Good commit messages are really helpful if you're working with other people (or on more complex solo projects). ↩︎