Git Fundamentals: How Git Actually Works

1 Step 1: Know What Git Is (and Isn't)

Git is a version control system: it records snapshots of a project over time, so you can see what changed, who changed it, why, and go back to any earlier state. It runs entirely on your computer. Every clone holds the project's complete history, so you can commit, browse history, and create branches with no network connection.

GitHub is a website that hosts Git repositories and adds collaboration on top: pull requests, code review, issues, and CI. Git is the tool; GitHub is where the team's shared copy lives. You can use Git without GitHub, but not the other way round.

2 Step 2: Learn the Three Places Your Changes Live

Every change you make moves through three areas. Almost every Git command moves changes from one area to another, so this is the single most useful idea in Git.

  Working tree            Staging area              Repository
  (your files on disk)    (the "next commit")       (.git folder: history)

   edit files  ──── git add ────▶  staged  ──── git commit ────▶  committed
       ◀──── git restore ────      ◀──── git restore --staged ────

• Working tree: the actual files in the project folder, the ones your editor and Unity see. Changes here are not saved in Git yet.
• Staging area (also called the index): a draft of your next commit. Staging lets you commit some changes and leave others for later.
• Repository: the permanent history, stored in the hidden .git folder at the project root. Never edit or delete that folder by hand.

git status shows exactly what is in each area: "Changes not staged" is the working tree, "Changes to be committed" is the staging area.

3 Step 3: Understand Commits

A commit is a snapshot of the whole project at one moment, plus a little metadata: the author, the date, the message, and a link to the commit before it (its parent). Those parent links chain commits into a history.

Each commit is identified by a hash: a 40-character ID such as 3f2a9c1e…, usually shortened to the first 7 characters. The hash is computed from the commit's contents, so a commit can never be changed. Commands that seem to "edit" commits (amend, rebase) actually create new commits with new hashes and leave the old ones behind.

git log --oneline           # one line per commit: short hash and message
git show 3f2a9c1            # what one commit changed, and its details

4 Step 4: Understand Branches and HEAD

A branch is not a copy of your files. It is just a label that points at one commit. When you commit on a branch, the label moves forward to the new commit. That's why creating a branch is instant and free.

HEAD means "where you are right now". Normally it points at a branch, which points at a commit. git switch moves HEAD to another branch and updates your working tree to match.

                         ┌── feature/issue-42   ◀── HEAD (you are here)
                         ▼
          A ── B ── C ── F ── G
                    ▲
                    └── Dev

Here Dev points at commit C. You branched from C and made commits F and G, so feature/issue-42 points at G. Dev hasn't moved; your work stays separate until it is merged.

5 Step 5: Understand Remotes: Your Copy and GitHub's

A remote is another copy of the repository, normally the one on GitHub. When you clone, Git names it origin. Your clone keeps remote-tracking branches such as origin/Dev: your machine's last-known snapshot of GitHub's branches. They don't update by themselves.

git remote -v               # where origin points
git branch -a               # local branches plus remote-tracking branches

6 Step 6: Understand Merging and Rebasing

Sooner or later your branch and Dev both have new commits. There are two ways to combine them.

          A ── B ── C ── D ── E         Dev
                    └── F ── G         feature/issue-42

          A ── B ── C ── D ── E ── M    Dev
                    └── F ── G ──┘

          A ── B ── C ── D ── E         Dev
                              └── F′ ── G′   feature/issue-42

Merging keeps history exactly as it happened. Rebasing produces a straight line that's easier to read and review, but it rewrites your commits. That's why the rule is: rebase only your own, unshared branches. At the studio you rebase your feature branch onto Dev, and GitHub merges pull requests for you. When a branch is simply behind with no commits of its own, Git just moves the label forward, which is called a fast-forward.

7 Step 7: Practice in a Throwaway Repository

The fastest way to understand Git is to watch it. Run these commands one at a time in a scratch folder, and run git status and git log --oneline --graph --all after each one to see what changed.

mkdir git-practice && cd git-practice
git init
echo "hello" > notes.txt
git status                          # notes.txt is untracked
git add notes.txt
git status                          # now staged
git commit -m "docs: add notes"
git switch -c feature/practice
echo "more" >> notes.txt
git commit -am "docs: add more notes"
git switch main                     # "master" if you skipped init.defaultBranch
cat notes.txt                       # "more" is gone; it lives on the other branch
git merge feature/practice          # fast-forward
git log --oneline --graph --all

Delete the folder when you're done. Nothing here touches GitHub. Try breaking things on purpose, then use Undoing Things Safely to recover.

8 Step 8: Keep the Glossary Handy