Git Rebase vs Merge: Practical Workflow Scenarios Quiz

Enhance your understanding of Git rebase and merge commands through practical workflow scenarios. This quiz focuses on the differences, use cases, and effects of rebase versus merge in modern version control, helping you choose the right approach for clean project histories.

1. Integrating Feature Branches

   Given a scenario where you have completed a feature branch off the main branch, which command should you use if you want to maintain a linear project history without unnecessary merge commits?

   1. git rebase main
   2. git merge main
   3. git branch main
   4. git reset main

   Explanation: Using 'git rebase main' will move the feature branch to start from the latest commit of main, applying your feature changes on top to maintain a linear history. 'git merge main' would merge main into your feature with an additional merge commit, branching the history. 'git branch main' is used for creating a branch, not integrating changes. 'git reset main' would alter the current branch's commit pointer, potentially losing changes if misused.

2. Preserving Complete Project History

   When collaborating with a large team, which method should you use to ensure that the complete history of how changes were integrated, including context about branch structure, is preserved?

   1. Using git merge
   2. Using git rebase
   3. Using git squash
   4. Using git stash

   Explanation: Merging preserves the full history, including when and how branches were combined, as it creates a merge commit and keeps the branch structure visible. Rebasing rewrites history, potentially making it harder to see when features were developed together. Git squash combines commits, losing granular history, while git stash is unrelated to history management and is used for temporarily saving changes.

3. Handling Conflict Resolution

   If a conflict arises during rebase, what is the recommended workflow to resolve it and continue rebasing your feature branch onto the latest main branch?

   1. Fix the conflict, use git add to stage fixes, then run git rebase --continue
   2. Fix the conflict, then run git rebase --abort immediately
   3. Fix the conflict, use git commit directly, and skip continuing the rebase
   4. Delete your feature branch and start over with git init

   Explanation: The correct way to handle a conflict during rebase is to resolve the conflicts, stage the resolved files with git add, and then use git rebase --continue to proceed. Aborting the rebase would result in losing progress on the rebase. Committing directly without continuing the rebase breaks the intended flow. Deleting the branch and restarting is unnecessary and an extreme solution.

4. Altering Public History

   Why should rebasing be avoided for branches that have already been shared with others in a central repository?

   1. Because rebasing rewrites commit history, causing problems for collaborators
   2. Because merging will result in data loss
   3. Because rebasing increases the size of your repository
   4. Because rebasing deletes your branch permanently

   Explanation: Rebasing changes the commit history, which can cause synchronization issues if others are working on the same branch, leading to conflicts. Merging does not result in data loss, but adds a merge commit. Rebasing does not affect repository size in any significant way, nor does it delete your branch.

5. Choosing the Right Command for a Clean Pull Request

   Before opening a pull request, which method should you use if your goal is to present a clear and linear commit history for your feature branch without clutter from previous merges?

   1. Rebase your branch onto the main branch
   2. Merge your branch into main
   3. Cherry-pick all commits from main
   4. Clone the repository again

   Explanation: Rebasing your branch onto main results in a straight, linear history, which is desirable for clear pull requests. Merging the branch into main adds merge commits and can clutter the history. Cherry-picking all commits is inefficient and error-prone. Cloning the repository again is unrelated to history management or preparing for a pull request.