Cheat sheet & self-check

Pick an answer to see if you got it, and why.

1. Q1. What's the difference between git fetch and git pull?

   1. ANone
   2. Bfetch downloads remote commits without touching your branch; pull fetches and then merges or rebases them into your branch
   3. Cpull only works on main
   4. Dfetch uploads
   Show answer

   B. fetch is always safe; pull changes your working branch. Many engineers fetch first and look before integrating.

   From lesson 04 · Remotes and pull requests

2. Q2. Why protect the main branch?

   1. ATo make it faster
   2. BSo changes only arrive through reviewed pull requests with passing checks, and nobody can force-push or delete it
   3. CTo hide it
   4. DGit requires it
   Show answer

   B. Branch protection turns 'main is always releasable' from a hope into a rule the server enforces.

   From lesson 04 · Remotes and pull requests

3. Q3. What makes a pull request easy to review?

   1. AMany unrelated changes
   2. BA small, focused change with a clear description, the reason, how it was tested, and passing checks
   3. CNo description
   4. DOnly a title
   Show answer

   B. Reviewers can reason about a few hundred focused lines; they skim thousands. Size and context drive review quality.

   From lesson 04 · Remotes and pull requests

4. Q4. What's the core idea of trunk-based development?

   1. ANever use branches
   2. BEveryone integrates small changes into the main branch at least daily, keeping it releasable; unfinished features hide behind flags
   3. CRelease once a year
   4. DEach team has its own main
   Show answer

   B. Frequent small integrations avoid painful merges and let CI/CD deploy main continuously.

   From lesson 05 · Branching strategies and releases

5. Q5. In semantic versioning, what does a MAJOR bump (2.0.0) signal?

   1. AA bug fix
   2. BA backwards-incompatible change
   3. CA new compatible feature
   4. DA rebuild
   Show answer

   B. MAJOR = breaking change, MINOR = compatible feature, PATCH = compatible fix.

   From lesson 05 · Branching strategies and releases

6. Q6. A critical bug is fixed on main, but production runs release/1.4. What's the safe approach?

   1. ADeploy main to production
   2. BCherry-pick the fix (-x) onto release/1.4, release 1.4.1, and confirm the fix is on main too
   3. CRewrite the release branch
   4. DWait for the next release
   Show answer

   B. Cherry-picking moves just the fix. Fixing main first (or confirming it's there) prevents the bug returning in the next release.

   From lesson 05 · Branching strategies and releases

7. Q7. A bad commit is already on the shared main branch. How do you undo it?

   1. Agit reset --hard and force push
   2. Bgit revert <sha>, which adds a new commit undoing it without rewriting history
   3. CDelete the branch
   4. Dgit stash
   Show answer

   B. Revert is safe for shared history: nobody else has to reconcile rewritten commits.

   From lesson 06 · Undo and recovery

8. Q8. You ran git reset --hard and lost two commits you hadn't pushed. Can you get them back?

   1. ANo
   2. BYes: git reflog shows the previous HEAD positions; create a branch at the lost commit's SHA
   3. COnly from backups
   4. DOnly with admin rights
   Show answer

   B. Commits stay in the repository until garbage-collected (typically weeks). The reflog remembers where HEAD pointed.

   From lesson 06 · Undo and recovery

9. Q9. What does git bisect do?

   1. ASplits a repository
   2. BBinary-searches history: you mark commits good or bad and it finds the first bad one in a few steps
   3. CMerges two branches
   4. DDeletes commits
   Show answer

   B. Among 1,000 commits it needs about 10 steps. With a test script (git bisect run) it finds the culprit automatically.

   From lesson 06 · Undo and recovery