Branching Strategies and Pull Request Workflows Quiz Quiz

Test your knowledge of branching strategies, feature branches, pull request workflows, merge methods, and code review best practices in version control systems. This quiz covers key concepts to help you understand and apply effective source control collaboration techniques.

1. Feature Branch Usage

   What is the main purpose of using feature branches in a version control workflow?

   1. To back up the entire repository regularly
   2. To rename the main branch for each new feature
   3. To permanently keep the code separate from the main branch
   4. To isolate development work related to a single feature or bug fix

   Explanation: Isolating development work into feature branches helps keep changes organized and makes it easier to review or revert them if needed. Keeping code permanently separate would prevent integration and is not practical. Renaming the main branch for features is unnecessary and could cause confusion. Regular backups are important, but they aren't the purpose of feature branches.

2. Understanding Pull Requests

   Which statement best describes a pull request in collaborative workflows?

   1. It is a request to merge changes from one branch into another and often starts the code review process
   2. It clones a repository into a new directory
   3. It automatically deletes the old feature branch after merging
   4. It is a command to reset a branch to match the main branch

   Explanation: A pull request is typically used to propose changes and initiate code review before integrating work into another branch. Resetting branches, deleting branches automatically, or cloning repositories are distinct actions not related to the function of a pull request.

3. Merging vs Rebasing

   When integrating the latest changes from the main branch into your feature branch, what distinguishes 'rebasing' from 'merging'?

   1. Merging adds only the new commits, while rebasing skips them
   2. Rebasing rewrites your commit history, while merging keeps all branch history intact
   3. Merging removes conflicts automatically, while rebasing does not
   4. Rebasing deletes your previous commits, while merging saves them

   Explanation: Rebasing applies your commits on top of the latest main branch commits and rewrites history for a linear result. Merging combines histories, preserving all branch history. Rebasing does not delete your commits, and both merging and rebasing require conflict resolution when conflicts occur.

4. Squash Merging

   What effect does a squash merge have when merging a feature branch into the main branch?

   1. It combines all feature branch changes into a single new commit
   2. It reverts all changes except the last commit
   3. It merges feature branch history line by line into main
   4. It deletes the feature branch without merging any changes

   Explanation: A squash merge collects all changes from a branch and creates a single commit on the target branch, keeping the commit history cleaner. Merging history line by line is incorrect, and reverting all but the last commit is not what squash does. Deleting the branch without merging loses all code changes.

5. Code Reviews and Pull Requests

   Why are code reviews commonly performed through pull requests?

   1. They automatically merge the code without human intervention
   2. They prevent all future bugs in the codebase
   3. They allow others to review and discuss code changes before integrating them
   4. They are required only when deleting a branch

   Explanation: Pull requests enable team members to review, give feedback, and approve changes before merging. They don't automatically merge code without review, nor do they guarantee a bug-free codebase. They are useful beyond just branch deletion.

6. Fast-Forward Merges

   Under what condition does a fast-forward merge occur when merging a feature branch?

   1. When branches are protected from changes
   2. When the feature branch contains merge conflicts
   3. When you squash all commits before merging
   4. When the target branch has not changed since the feature branch was created

   Explanation: A fast-forward merge is possible if the main branch has not had any new commits since the feature branch was created, allowing a straight move forward. Merge conflicts prevent a fast-forward, squashing does not cause a fast-forward, and branch protection is unrelated.

7. Review Approvals

   What is a common requirement before merging a pull request into the main branch?

   1. Deleting unrelated branches first
   2. Renaming the main branch
   3. Obtaining review approvals from team members
   4. Automatically publishing the branch without checks

   Explanation: Most workflows require at least one or more review approvals to ensure quality and agreement. Automatically publishing or skipping checks is unsafe. Deleting other branches or renaming the main branch is unrelated to the approval process.

8. Branch Protection Rules

   What is the main purpose of branch protection rules in a repository?

   1. To hide branch names from collaborators
   2. To prevent all branches from being created
   3. To automatically create new branches for every user
   4. To enforce requirements such as code reviews or test passes before merging

   Explanation: Branch protection rules set conditions like mandatory reviews or successful tests to safeguard crucial branches. Preventing all branch creation or hiding branch names restricts collaboration. Automatically creating branches is unnecessary and not their function.

9. Resolving Merge Conflicts

   If a merge conflict occurs during a pull request, what should you typically do?

   1. Delete both branches immediately
   2. Submit the pull request again without changes
   3. Ignore the conflict and merge anyway
   4. Manually resolve the conflicting changes and update the pull request

   Explanation: Conflicts must be resolved by editing files to reconcile changes, then updating the pull request. Deleting branches forfeits progress. Resubmitting without changes or ignoring conflicts won’t fix the issue and may block the merge.

10. Deleting Feature Branches

    What is a common best practice after successfully merging a feature branch into the main branch?

    1. Leave the feature branch unaltered to avoid errors
    2. Delete the feature branch to keep the repository tidy
    3. Merge the main branch back into the feature branch
    4. Rename the feature branch for future use

    Explanation: Once merged, deleting the feature branch prevents clutter and confusion. Merging main back into a branch is unnecessary after merging. Renaming or keeping the branch may create disorder or lead to accidental edits.