⚠

Privacy Notice: When you sign in with GitHub, your quiz attempts are stored in Google Firebase so you can track your progress. This data is only accessible to the course instructor, is not otherwise shared, and will be deleted at the end of the semester. For earlier deletion, contact the instructor. Prefer to stay anonymous? Use guest mode or a GitHub account without your real name.

● Progress is being saved

02 Quiz: Feature Branch Development

Score: 0 / 16

Question Overview

Pending Correct Incorrect

Instructions

Some questions include Git graphs in the style of the VS Code Git Graph visualizer — study them carefully before answering.
Each question has 4 options with exactly one correct answer.
You can retry incorrect answers; immediate feedback explains the reasoning.

Graph legend:

Question1 Git 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

Question2 Git States

Your teammate asks why Git has a staging area instead of just committing changes directly from the working directory. What is 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

Question3 Branches

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

Question4 Push & Remote

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 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

Question5 Commit Practices

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

A) Make one large commit with the 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

Question6 Pull Requests

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

Question7 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

Question8 Git States

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

Question9 Branch Protection

Your team has enabled branch protection on main. You try to push directly to main and get an error. What is 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

Question10 Pull Requests

You’ve been working on a large feature that touches 15 files and changes over 2000 lines. What is 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

Question11 Commit Practices

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

Question12 Branch Workflow

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

Question13 Code Review

During code review of your Pull Request, a teammate suggests adding type hints to your functions. What is 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

Question14 Pull Requests

You’ve opened a Pull Request (commit “PR open”). Your teammate requests changes. You respond with two more 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

Question15 Workflow Philosophy

What is 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

Question16 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

02 Quiz: Feature Branch Development

Instructions

Quiz Complete!