THE Mental Model that Made Git Click

Learn how Git thinks (it's easy) to make Git work for you, once and for all.

Around 2012-ish, this thing called Git was gaining steam and captured attention across the tech scene. Like many others, I created my GitHub account and gave it a try. I fell flat on my face. I just could not figure it out.

I read, and I read, and I read. Nothing clicked. I felt stupid. Git felt impossible for me to learn.

Finally, I switched to Mercurial and tried to erase the pain of Git from my mind.

A few more years went by and I was forced to reckon with the ghosts of Git from my past.

With more maturity and experience on my side plus a chance encounter with a training team from GitHub, I gained traction and learned enough to keep learning.

Now, I’ve crafted a mental model for Git that facilitates my overall understanding. Some might say, I taught myself to think like a Git. Git isn’t just cryptic commands, but a set of operations that alter the underlying data objects of Git.

I won’t bore you with a lengthy post. Git is tricky and I struggle to teach it through writing alone. Instead, I’m much better off to teach you about Git in-person. Check this video on my YouTube specifically made to share my mental model for understanding Git. I promise - you haven’t seen anything like this.

These are the high level notes to refer back. Otherwise, enjoy the video and send me a message if you have any questions.

YouTube: Mental Models I Rely On To Beat Git

1. Mutable chain of immutable commits.

   1. Append-only data structure.

   2. Processed from latest-to-oldest

   3. Chain of commits where each commit points to the previous.

   4. Commits are atomic. Commits are NOT changed, they are recreated.

   5. Chains can be updated.

2. Commits have an embedded reference to the previous commit.

   1. A commit embeds the author, message, time, changes AND the previous commit.

   2. Any commit that is recreated also recreates every commit AFTER IT.

3. Git DOES NOT merge commits.

   1. Merging is what occurs before a commit is created.

4. Creating and altering commits is for the client (YOU). The server will accept or deny your push. Accept and Reject are the only options.

   1. Pushes are rejected because your push would break the “append only” principle.

5. There are a minimum of three copies of your branch.

   1. The server has a copy of main.

   2. In your repo, the remote tracking branch copy of main.

   3. In your repo, the workspace copy of main. This is the copy that YOU modify.

   4. Here’s the kicker: they can be in completely different states.

6. Security controls are provided by the server (GitHub, GitLab, Azure DevOps, etc.). Git alone provides no security nor access controls.