Home

02 Quiz: Feature Branch Development

October 2025 (2769 Words, 16 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
Try to answer without referring to the lecture materials
Focus on understanding concepts, not memorizing details

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) The staging area is a legacy feature from older version control systems and isn’t really necessary anymore
B) It allows you to selectively choose which changes to include in each commit, enabling logical, focused commits
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: B

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

What is the PRIMARY purpose of creating a feature branch instead of working directly on the main branch?

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) GitHub requires feature branches for all projects over 100 commits
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

You’re on a feature branch and have made several commits. What happens when you run git push for the first time on this branch?

A) Git automatically creates a Pull Request on GitHub for you
B) The branch and its commits are uploaded to GitHub, but main remains unchanged
C) Your commits merge directly into main on GitHub
D) Git blocks the push and requires you to create a Pull Request first

Show Answer

Correct Answer: B

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) Make separate focused commits for each type of fix (imports, spacing, naming) with descriptive messages
C) Don’t commit until all violations are fixed to avoid cluttering the git history
D) Commit after every single line change to have maximum granularity

Show Answer

Correct Answer: B

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

Show Answer

Correct Answer: C

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

You’ve just had your Pull Request approved and merged into main. What should you do with your feature branch?

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 - it’s served its purpose
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) You staged some changes, then made additional edits to the same file afterwards
C) The file has conflicts that need to be resolved before committing
D) This is impossible - a file can’t be in both states simultaneously

Show Answer

Correct Answer: B

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) GitHub is temporarily down and you should try again later
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) Break it into multiple smaller PRs, each focusing on a logical subset of the feature
C) Wait until you’ve added tests and documentation before creating any PR
D) Create the large PR but mark it as “Draft” so reviewers know it’s big

Show Answer

Correct Answer: B

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. What’s the correct first step?

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

Show Answer

Correct Answer: C

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, commit, and push to update the PR
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. Your teammate requests changes. After you push new commits to your feature branch, what happens to the PR?

A) You need to close the old PR and open a new one with the updated commits
B) The PR automatically updates to include your new 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: B

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) Keep main stable and deployable at all times by isolating development work
C) Avoid merging to reduce the chance of merge conflicts
D) Make commits as large as possible to minimize the number of merges needed

Show Answer

Correct Answer: B

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.

Scoring Guide

13-15 correct: Excellent! You have a strong grasp of Git workflows and collaborative development
10-12 correct: Good understanding! Review the areas you missed to solidify your knowledge
7-9 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.