Home

02 Quiz: Feature Branch Development

April 2026 (4436 Words, 25 Minutes)

exercises quiz chapter-02 git feature-branches pull-requests workflow

Chapter 02 Quiz: Feature Branch Development

Instructions

This quiz tests your understanding of key concepts from Chapter 02 (Feature Branch Development)
Each question has 4 options with exactly one correct answer
Some questions include Git graphs in the style of the VS Code Git Graph visualizer — study them carefully before answering
Try to answer without referring to the lecture materials
Focus on understanding concepts, not memorizing details

Graph legend:

Question 1: Git’s Three States

You’ve just edited main.py to fix some PEP8 violations. What state is this file in before you run git add?

A) Repository (Committed) - the changes are permanently saved in Git’s history
B) Staging Area (Staged) - the changes are marked for the next commit
C) Working Directory (Modified) - the file is changed but Git hasn’t been told about it yet
D) Remote (Pushed) - the changes are on GitHub waiting to be pulled

Show Answer

Correct Answer: C

When you edit a file, it enters the “Working Directory” state (also called “Modified” state). Git knows the file has changed (you can see this with git status), but these changes haven’t been staged for commit yet. You need to run git add to move changes to the Staging Area, then git commit to save them permanently in the Repository. The three-state model is fundamental: Working Directory → Staging Area → Repository.

Question 2: The Purpose of the Staging Area

Your teammate asks why Git has a staging area instead of just committing changes directly from the working directory. What’s the BEST explanation?

A) It allows you to selectively choose which changes to include in each commit, enabling logical, focused commits
B) The staging area is a legacy feature from older version control systems and isn’t really necessary anymore
C) It’s only useful for large teams; individual developers don’t need to use the staging area
D) The staging area automatically runs tests before committing to prevent broken code

Show Answer

Correct Answer: A

The staging area gives you control over what goes into each commit. Even if you’ve made multiple changes to a file (like fixing imports, spacing, and naming), you can stage and commit them separately using git add -p. This creates a cleaner history with logical, focused commits rather than one giant “fixed everything” commit. This makes code review easier, allows selective reverts, and helps collaborators understand your changes. The staging area is a powerful feature that separates Git from simpler version control systems.

Question 3: Branch Fundamentals

In the graph below, main keeps moving forward with stable commits while experimental work happens on feature (including WIP commits).

What is the PRIMARY purpose of this separation into a feature branch instead of working directly on main?

A) Feature branches run faster because they have fewer commits to track
B) Isolation - your experimental work won’t affect the stable production code until it’s ready
C) Branches give each developer a private copy of the codebase that doesn’t sync with main unless explicitly merged
D) Feature branches automatically run quality checks that main branches skip

Show Answer

Correct Answer: B

The primary purpose of feature branches is isolation. When you create a branch from main, you create a parallel timeline where you can experiment, make mistakes, and iterate without affecting the stable main branch. If your feature breaks something, other team members can still work on the stable main branch. Once your feature is complete and tested, you merge it back. This is the foundation of professional software development - keeping production code stable while allowing innovation. Main should always be deployable.

Question 4: Git Workflow Understanding

Locally, your repository looks like this — feature has three commits that are not yet on GitHub:

You run git push -u origin feature for the first time. What is the resulting state?

A) A new pointer origin/feature now also points at the third feature commit; main and origin/main remain unchanged
B) Git automatically creates a Pull Request on GitHub and opens a review thread for the three commits
C) Your commits merge directly into main on GitHub (origin/main advances to include them)
D) Git blocks the push and forces you to create a Pull Request through GitHub’s web UI first

Show Answer

Correct Answer: A

When you git push a feature branch for the first time (using git push -u origin feature-name), you’re uploading your local branch and its commits to GitHub. This creates a remote copy of your branch, but it does not affect main at all. The branches remain separate. To merge your changes into main, you need to create a Pull Request (which is a separate, explicit action). This separation is intentional - it allows review and testing before changes reach production code.

Question 5: Commit Best Practices

You’ve fixed multiple PEP8 violations in a file: import problems, spacing issues, and naming conventions. What’s the BEST commit strategy?

A) Make one large commit with message “Fixed all PEP8 violations” to keep history simple
B) Don’t commit until all violations are fixed to avoid cluttering the git history
C) Make separate focused commits for each type of fix (imports, spacing, naming) with descriptive messages
D) Commit after every single line change to have maximum granularity

Show Answer

Correct Answer: C

Small, focused commits with clear messages are a professional best practice. By separating different types of fixes into different commits (“Fix PEP8: Separate imports”, “Fix PEP8: Add spacing around operators”, “Fix PEP8: Rename to snake_case”), you create a logical progression that’s easier to review, understand, and if necessary, revert. One giant commit makes it hard to understand what changed and why. Too many tiny commits create noise. The goal is logical units of work - each commit should have a clear, single purpose.

Question 6: Pull Request Fundamentals

What is the PRIMARY purpose of a Pull Request (PR)?

A) To request that your changes be reviewed and merged into the target branch
B) To pull the latest changes from main into your feature branch
C) To push your local commits to GitHub’s remote repository
D) To automatically merge your changes into main without manual intervention

Show Answer

Correct Answer: A

Despite the confusing name, a Pull Request is actually a merge request - you’re asking for your changes to be reviewed and merged into another branch (usually main). A PR creates a space for discussion, code review, automated checks, and collaboration before code reaches production. It’s not automatic (that would defeat the purpose), it’s not about pulling from main (that’s git pull), and it’s not about pushing commits (that’s git push). PRs are the cornerstone of collaborative development and quality gates.

Question 7: Feature Branch Lifecycle

Your Pull Request was just approved and merged into main. The graph now looks like this:

What should you do with the feature branch now?

A) Keep it forever as a backup in case something goes wrong with main
B) Continue using it for your next feature to avoid creating too many branches
C) Delete both the local and remote feature branch — its commits are now part of main
D) Archive it by renaming it to “completed/feature-name” for documentation

Show Answer

Correct Answer: C

Once a feature branch is merged, it should be deleted both locally and on GitHub. The work is now part of main, so the branch is redundant. Keeping old branches creates clutter and confusion (“is this still being worked on?”). Branches in Git are lightweight pointers, not containers of code - the commits still exist in main’s history even after deleting the branch. For your next feature, create a fresh branch from the updated main. This keeps your repository clean and your workflow clear.

Question 8: Git Status Interpretation

You run git status and see a file listed under both “Changes to be committed” and “Changes not staged for commit”. What does this mean?

A) Git is confused and you need to reset the repository
B) The file has conflicts that need to be resolved before committing
C) This is impossible - a file can’t be in both states simultaneously
D) You staged some changes, then made additional edits to the same file afterwards

Show Answer

Correct Answer: D

This is completely normal! It means you used git add to stage some changes to the file, then continued editing it. The staged version contains your earlier edits (ready for commit), while the unstaged changes are your new edits since the last git add. If you commit now, only the staged changes will be included. You’d need to git add again to include the newer changes. This demonstrates why the staging area is powerful - it lets you craft exactly what goes into each commit.

Question 9: Branch Protection Understanding

Your team has enabled branch protection on main. You try to push directly to main and get an error. What’s happening?

A) Your local branch is behind the remote — you need to pull first to fast-forward, then push
B) Branch protection rules prevent direct pushes to main - you must use a Pull Request
C) You don’t have write permissions to the repository
D) You need to force push with git push --force to override the protection

Show Answer

Correct Answer: B

Branch protection intentionally blocks direct pushes to protected branches like main. This enforces professional workflow: you must create a feature branch, push it, open a Pull Request, pass any required checks, and get approval before your code reaches main. This prevents accidents (“oops, pushed broken code”), enforces code review, and ensures quality gates are passed. Force pushing won’t work either - the protection applies to everyone (even admins, if configured properly). This is a feature, not a bug!

Question 10: Pull Request Size Best Practices

You’ve been working on a large feature that touches 15 files and changes over 2000 lines. What’s the BEST approach for your Pull Request?

A) Submit one large PR with all changes - it’s one feature, so it should be one PR
B) Wait until you’ve added tests and documentation before creating any PR
C) Create the large PR but mark it as “Draft” so reviewers know it’s big
D) Break it into multiple smaller PRs, each focusing on a logical subset of the feature

Show Answer

Correct Answer: D

Large PRs (2000+ lines) are overwhelming to review and often get “rubber-stamped” without careful examination, leading to bugs. Break large features into smaller, logical PRs - perhaps by component, layer, or incremental functionality. Each PR should be 50-300 lines ideally, with a clear purpose. Smaller PRs get better reviews, merge faster, are easier to test, and if something breaks, it’s easier to identify which PR caused it. Yes, this requires more planning, but that planning itself improves code quality.

Question 11: Commit Message Quality

Which commit message follows best practices for professional development?

A) “Fixed stuff”
B) “WIP”
C) “Fix PEP8: Separate multiple imports onto different lines”
D) “Updated main.py with the changes we discussed in yesterday’s meeting about code quality improvements”

Show Answer

Correct Answer: C

Good commit messages are specific and concise. Option C follows the pattern: “What: Brief description” and references the standard (PEP8). Option A is too vague (“what stuff?”), Option B is for temporary commits that shouldn’t be pushed, and Option D is too verbose and lacks specifics. A good commit message should let someone understand what changed and why, without reading the diff. Future you (or your teammates) will thank you when debugging or understanding the history six months later.

Question 12: Branch Workflow Strategy

You’re starting work on a new feature. Locally, you see the following state — your local main is outdated, the team has pushed two commits to origin/main in the meantime:

What is the correct first step before you start coding?

A) Start coding immediately on your current branch to save time
B) Create a feature branch directly from the outdated local main
C) Fork the repository and work in your fork instead of using branches
D) Run git pull origin main first, then create the feature branch from the updated main

Show Answer

Correct Answer: D

Always start from an updated main branch. First, git checkout main, then git pull origin main to get the latest changes from the team. Then create your feature branch with git checkout -b feature/your-feature. This ensures your feature builds on the latest production code, minimizing merge conflicts later. Starting from an outdated main or a different feature branch can lead to conflicts and broken code. Forks are for external contributors, not team members with write access.

Question 13: Code Review Purpose

During code review of your Pull Request, a teammate suggests adding type hints to your functions. What’s the BEST response?

A) Reject the suggestion - the code works fine without type hints
B) Accept the feedback, add type hints, and commit the changes to your branch
C) Close this PR and open a new one with type hints to keep PRs separate
D) Argue that type hints should be in a separate PR since they weren’t part of your original changes

Show Answer

Correct Answer: B

Code review is about collaboration and improvement. If feedback improves code quality (and type hints definitely do), embrace it! Make the changes, commit them to the same branch, and push - this automatically updates the PR. You don’t need a new PR for review-requested changes. While “separate concerns in separate PRs” is generally good advice, adding type hints to functions you’re already touching makes sense in the same PR. The goal is better code, not winning arguments about workflow purity.

Question 14: Understanding PR Updates

You’ve opened a Pull Request (commit “PR open”). Your teammate requests changes. You respond with two additional commits (“review fix” and “type hints”) and push them to the same feature branch:

What happens to the PR?

A) The PR automatically updates to include your new commits — it follows the branch tip
B) You need to close the old PR and open a new one with the updated commits
C) You need to manually add the new commits to the PR through GitHub’s interface
D) The PR is locked until a maintainer approves the new commits

Show Answer

Correct Answer: A

Pull Requests are linked to branches, not commits. When you push new commits to the same feature branch, the PR automatically updates to include them. This is why the PR workflow is so powerful - it supports iterative improvement. You can respond to feedback, add commits, and the conversation continues on the same PR. The commit history grows, reviewers can see your changes, and automated checks re-run. No need to create new PRs or manually update anything.

Question 15: Git Workflow Philosophy

What’s the fundamental principle behind the feature branch workflow?

A) Create as many branches as possible to maximize Git’s features
B) Avoid merging to reduce the chance of merge conflicts
C) Make commits as large as possible to minimize the number of merges needed
D) Keep main stable and deployable at all times by isolating development work

Show Answer

Correct Answer: D

The core principle is: main should always be stable and deployable. Feature branches provide isolation for experimental work, bug fixes, and new features. When work is complete and tested, it merges to main. This means anyone can clone the repository, checkout main, and have working code. If someone pushes broken code directly to main, everyone is blocked. Feature branches with Pull Requests ensure quality gates (tests, reviews, checks) before code reaches production. This is the foundation of modern collaborative software development.

Question 16: Reading Diverged Branches

While you were working on your feature, a teammate merged their PR — so main has moved forward. The graph now looks like this:

Which statement about this state is correct?

A) The branch is outdated, but a fast-forward merge still works because feature started from B
B) main and feature have diverged — fast-forward is no longer possible because both branches have new commits since the common ancestor B
C) Git will silently discard your feature commits on the next git push because main is ahead
D) You must delete feature and recreate it from M2 — the commits C1, C2, C3 are lost

Show Answer

Correct Answer: B

The graph shows classic divergence: both branches share the common ancestor B, but main then got M1 and M2 while feature got C1, C2, and C3. A fast-forward would only be possible if main pointed directly at a descendant of feature (or vice versa) — that’s not the case here.

To bring the three feature commits cleanly into main, you have two main options:

Merge commit: git merge feature on main creates a new merge commit that joins both histories (explicitly shows that work happened in parallel)
Rebase + fast-forward: git rebase main on feature replays C1, C2, C3 on top of M2 — afterwards a fast-forward is possible again (more linear history)

Nothing is lost — Git stores both histories. Option C is wrong (Git never silently discards commits on push) and Option D is wrong (the commits still exist as part of the reflog and branch history).

Scoring Guide

14-16 correct: Excellent! You have a strong grasp of Git workflows and collaborative development
11-13 correct: Good understanding! Review the areas you missed to solidify your knowledge
7-10 correct: Fair understanding. Revisit the lecture materials, especially sections on Git states and PR workflows
Below 7: Please review the lecture carefully and consider practicing with a sample repository

Key Takeaways to Remember

Git’s Three States - Working Directory (modified) → Staging Area (staged) → Repository (committed). Understanding this flow is fundamental.
Staging Area Purpose - Gives you control to create focused, logical commits rather than committing everything at once.
Feature Branch Isolation - Work on features in isolation so main stays stable and deployable. This is the foundation of professional workflows.
Branch Protection - Prevents direct pushes to main, enforcing the Pull Request workflow and ensuring code review.
Pull Request Workflow - Create branch → Make commits → Push → Open PR → Review → Merge → Delete branch. Each step has a purpose.
Commit Best Practices - Small, focused commits with clear messages. Each commit should represent one logical unit of work.
PR Size Matters - Keep Pull Requests small (50-300 lines) for better reviews. Break large features into multiple PRs.
Main Branch Sanctity - main should always be stable and deployable. Never push directly; always use feature branches and PRs.
Code Review is Collaboration - Feedback improves code quality. Embrace suggestions and iterate on your work.
PR Updates are Automatic - Push new commits to your feature branch and the PR updates automatically. No need to create new PRs.
Reading Git Graphs - Visualize branches as pointers to commits. Divergence (both branches have their own commits since the common ancestor) prevents fast-forward — then merge or rebase are your options.