Git & GitHub cheat sheet

A repository is just a directory with a hidden .git sub-folder inside it. That sub-folder is the time machine: every snapshot you've ever taken, every branch you've named, every author who touched the code, all kept locally so the project still works on a plane.

When you push the repo to GitHub, that history is mirrored on the internet so other humans (and AIs) can pull it down and contribute.

Cloning is the first move on a new project. git clone <url> asks the remote ("hi, send me everything") and Git stamps a full copy of the repo onto your disk: every branch, every commit, every author note. You now own a fully working version, network or no network.

Once cloned, your local repo and the remote are linked. origin is the nickname Git gives to where you cloned from.

A branch is a movable pointer to a commit. Make one, and you can experiment freely — wild refactors, half-broken features, dumb ideas — without touching main. If it pans out, you merge it back. If it doesn't, you delete the branch and pretend nothing happened.

Branches are cheap. Make them constantly. The best teams treat main as sacred and do everything else on branches.

A commit captures everything that's staged — the files you told Git to include with git add — and freezes them with an author, a timestamp, and a message. That message is half of why commits matter: it's how future-you, your teammates, and git blame will understand what changed and why.

Each commit gets a unique SHA hash like a3f9c1d. That's the permanent address of that snapshot.

Push sends commits you've made locally up to the remote (GitHub) so other people can see them. Pull does the inverse: it fetches commits from the remote and merges them into your current branch.

Think of it as two directions on the same elevator between your laptop and the cloud. Use the toggle below to see each in action.

A diff shows exactly what changed: which lines were added (green, prefixed +), which were removed (red, prefixed -), and which stayed the same (for context).

Reading the diff before you commit is the single highest-leverage habit in Git. It catches typos, debug logs, accidental deletes, and the wrong file getting included — every time.

Merging takes the work on a side branch and brings it into the target branch (usually main). When the two histories have diverged, Git creates a special merge commit — a diamond on the timeline — that has two parents, one from each branch.

Merge keeps the actual history of what happened: "these two timelines joined here." It's honest, but it can clutter the log.

Rebase rewrites your branch's history. Instead of merging, Git lifts each of your commits, fast-forwards main to its newest state, and then re-applies your commits one by one on top. The result is a clean, linear history that looks like you wrote your feature against the current main all along.

It's beautiful — but it rewrites history, so use it with care on shared branches.

A conflict happens when Git can't tell which version of a line to keep — because two branches changed the same lines in incompatible ways. Git pauses, marks up the offending file with <<<<<<< / ======= / >>>>>>>, and hands the keyboard back to you.

You pick what's right (one side, the other, both, or something new), delete the markers, save, git add, and continue.

A pull request is GitHub's wrapper around git merge. You open it from your branch into a target branch (usually main) and it becomes a conversation: reviewers leave comments, CI runs tests, someone approves, and finally it gets merged.

Good PRs are short, well-described, and easy to say yes to. The hardest part of a PR is rarely the code — it's the empathy with the reviewer.

An issue is a unit of "something we should do." It can describe a bug to fix, a feature to build, a question to answer, or just a chore. Each issue has a title, a body, labels, an assignee, and a status — and it lives next to the code it relates to, so context never gets lost.

Issues are how a team turns "we should…" into "we did."