02 Exercise: Git Pointers and Branches

Creating a new branch with git checkout -b creates a new pointer to the same commit you’re currently on. No new commit is created. Both main and feature/new-ui point to commit i7j8k9l, and HEAD moves to point to the new branch. Option B is wrong because no new commit was made. Option C is wrong because main still exists. Option D is wrong because the branch doesn’t copy commits - it’s just a new pointer to the same commit.

When you make a commit on a branch, Git creates a new commit and moves ONLY the current branch pointer forward. The main pointer stays at i7j8k9l because we’re not on the main branch. The new commit p9q8r7s becomes the new tip of feature/new-ui. Option A is wrong because HEAD should point to feature/new-ui. Option B is wrong because main moved (it shouldn’t). Option C is wrong because commits form a chain - the new commit has i7j8k9l as its parent.

Each commit moves the current branch pointer forward. After two more commits, feature/new-ui points to x4y5z6a (the latest commit), while main remains at i7j8k9l (where we branched from). The commits form a linear chain: i7j8k9l -> p9q8r7s -> t1u2v3w -> x4y5z6a. Option A is wrong because main shouldn’t move. Option C is wrong because it breaks the commit chain (p9q8r7s must have i7j8k9l as parent). Option D is wrong because it skips commit p9q8r7s in the chain.

git checkout (or git switch) ONLY moves the HEAD pointer. Branch pointers don’t change. HEAD moves from pointing to feature/new-ui to pointing to main. Both branches still exist and point to their respective commits. Your working directory changes to show the state at commit i7j8k9l. Option B is wrong because feature/new-ui still exists. Option C incorrectly shows the commits as separate chains. Option D is wrong because main is still at i7j8k9l, not x4y5z6a.

A fast-forward merge moves the target branch pointer (main) forward to match the source branch (feature/new-ui). No merge commit is created because main just “catches up” to feature/new-ui. Both pointers now point to the same commit x4y5z6a. Option A is wrong because fast-forward doesn’t create a merge commit. Option C is wrong because main didn’t move. Option D is wrong because it loses all the feature commits.

Tags are pointers to commits, just like branches. By default, git tag creates a tag pointing to the commit that HEAD currently references (which is x4y5z6a since HEAD -> main -> x4y5z6a). The tag, main, and feature/new-ui all point to the same commit now. Option A is wrong because the tag should point to the current HEAD commit. Option C is wrong because tags don’t create new commits. Option D incorrectly shows separated commit chains.

When on main and making a commit, only the main pointer moves forward. The new commit b7c8d9e has x4y5z6a as its parent. feature/new-ui and the tag v1.0 remain pointing at x4y5z6a. This creates a linear history where main moved ahead. Option B is wrong because commits must have parents (b7c8d9e should have x4y5z6a as parent). Option C is wrong because feature/new-ui shouldn’t move (it shouldn’t appear twice). Option D is wrong because it shows no new commit was created - main is still at x4y5z6a instead of at the new commit b7c8d9e.

The branches have diverged from their common ancestor x4y5z6a:

1. Checkout moves HEAD: git checkout feature/new-ui moves HEAD from main to feature/new-ui (now at x4y5z6a)
2. New commit on feature/new-ui: The commit creates f1g2h3i with parent x4y5z6a (where feature/new-ui was)
3. Result: Both b7c8d9e (on main) and f1g2h3i (on feature/new-ui) branch from x4y5z6a

This creates a fork in history. The key insight: feature/new-ui was still pointing to x4y5z6a (it didn’t move when main got commit b7c8d9e in Q7), so the new commit f1g2h3i branches from x4y5z6a, NOT from b7c8d9e.

Option A shows linear history (f1g2h3i after b7c8d9e), but feature/new-ui should branch from x4y5z6a. Option C disconnects commits from their parents. Option D shows f1g2h3i branching from b7c8d9e, but feature/new-ui was at x4y5z6a.

When you check out a specific commit (not a branch), HEAD points directly to that commit rather than to a branch pointer. This is called “detached HEAD” state. Git warns you because commits made in this state won’t belong to any branch.

Why D is correct:

• HEAD now points directly to commit x4y5z6a
• HEAD is marked as “(detached)” because it’s not pointing through a branch
• The graph structure doesn’t change - branches stay where they were

Why other options are wrong:

• Option A shows HEAD still attached to main (which stayed at b7c8d9e)
• Option B shows both “main <- HEAD” label AND main pointing to x4y5z6a, which is wrong - main didn’t move
• Option C is missing the divergent commits (b7c8d9e and f1g2h3i) - checking out an old commit doesn’t delete newer commits!

Renaming a branch only changes the branch pointer’s label. Git creates a new pointer with the new name pointing to the same commit, then deletes the old pointer. No commits are modified or created. Tags like v1.0 are unaffected because they point to commits, not to branch names. This is why renaming branches is safe and instant - you’re just changing a label, not touching the actual history. Option A is wrong because commit hashes are based on content, not branch names. Option B is wrong because no commits are created or deleted. Option D is wrong because tags point to commits and are independent of branch names.

Remote-tracking branches (like remotes/origin/main) are local copies that serve as bookmarks showing what exists on GitHub. They’re not the actual remote branches - they’re your local Git’s record of what was on GitHub last time you fetched. You can’t commit directly to them. Option A is wrong because remote-tracking branches are read-only bookmarks. Option B is wrong because they’re not remote branches - they’re local references to remote branches. Option D is wrong because you don’t commit to remote-tracking branches; they’re automatically updated by git fetch or git pull.

git fetch downloads new commits from GitHub and updates remote-tracking branches (remotes/origin/main), but it does NOT update your local branches. Your local main stays at i7j8k9l until you manually merge or use git pull (which is fetch + merge). This is the safe way to see what’s changed on GitHub without affecting your work. Option A is wrong because fetch doesn’t touch local branches. Option C is wrong because only the bookmark updates. Option D is wrong because fetch DOES update remote-tracking branches.

Your local Git still has the remotes/origin/feature/old-pr reference because Git doesn’t automatically remove remote-tracking branches. They’re stale (pointing to a branch that no longer exists on GitHub) until you run git fetch --prune or git remote prune origin. This is intentional - Git errs on the side of keeping information. Option A is wrong because the stale reference persists. Option C is wrong because local branches aren’t automatically deleted. Option D is wrong because Git doesn’t auto-detect deletions without fetching.

git fetch --prune does TWO things: (1) downloads new commits/branches from GitHub, and (2) removes remote-tracking branches that no longer exist on GitHub. It does NOT touch your local branches - you must delete those separately with git branch -d. Option A is wrong because local branches aren’t affected by prune. Option C is wrong because --prune is an addon to fetch, not a replacement. Option D is wrong because local branches are never automatically deleted.

git pull --prune combines three actions: (1) git fetch --prune (download + remove stale remote-tracking branches), (2) merge into current branch (main fast-forwards to x4y5z6a). Your LOCAL feature/old-pr branch is NOT deleted - you must do that separately with git branch -d feature/old-pr. Only the remote-tracking branch remotes/origin/feature/old-pr is removed by --prune. Option A is wrong because it doesn’t show the local feature branch. Option B is wrong because local branches aren’t auto-deleted. Option D is wrong because main DOES update (that’s what pull does).

The lecture compares remote-tracking branches to browser bookmarks: GitHub is like actual websites, and remote-tracking branches are your local bookmarks pointing to GitHub’s branches. Just like bookmarks can become outdated if a website changes, remote-tracking branches become stale if GitHub’s branches change without you fetching. Option A is wrong because they’re local copies, not the actual remote branches. Option C is wrong because they track remote state, not local backups. Option D is wrong because they persist until explicitly pruned.

Running git config --global fetch.prune true makes every git fetch and git pull automatically clean up stale remote-tracking branches. This is the recommended setup from the lecture because it’s “one less thing to remember.” Option B is not a valid Git config. Option C is not the correct config name. Option D sets upstream tracking for branches, which is unrelated to pruning.

git branch --merged main lists all local branches whose commits are reachable from main (meaning they’ve been merged). You can safely delete these with git branch -d. Option B shows branches NOT yet merged (opposite of what you want). Option C shows remote-tracking branches that would be pruned, not local branches. Option D is not a valid git log flag.

“Squash and merge” creates a NEW commit with all your changes combined, rather than using your original commits. Git sees your local commits as “not merged” because they don’t exist in main’s history (only the squashed version does). After confirming on GitHub that the PR was indeed merged, it’s safe to force delete with git branch -D feature/squashed. Option B is wrong - the PR IS merged, just in a different form. Option C is wrong - rebase won’t help here. Option D is wrong - you can and should delete merged branches.

The complete workflow is: (1) git checkout main to switch to main, (2) git pull --prune to update main AND remove stale remote-tracking branches, (3) git branch -d feature/xyz to delete your local branch. This cleans up all three: local branch, local main, and stale remote-tracking references. Since the PR was merged with “Create a merge commit” (not squash), Git recognizes the branch as merged and -d works safely. Option A is wrong because it doesn’t update main or prune. Option B is wrong because it doesn’t delete the local branch. Option D is wrong because it doesn’t update main, and uses force delete (-D) which is unnecessary when the branch was properly merged.