Understanding Git Rebase vs Merge Quiz Quiz

Challenge your understanding of the differences between Git rebase and merge operations with practical scenarios designed to highlight their effects on commit history, collaboration, and resolving conflicts. This quiz aims to improve your confidence when choosing between rebase and merge in version control workflows.

1. Effect on Commit History

   When using git rebase instead of git merge to incorporate changes from the main branch into your feature branch, how does the commit history appear after completion?

   1. A linear sequence of commits as if the branch was created from the latest main branch commit
   2. A merge commit combining the feature and main branches
   3. A duplicate of all commits from both branches
   4. No change in the commit history

   Explanation: Rebasing rewrites the commit history, creating a linear progression as though you started your feature branch from the latest commit in the main branch. This differs from merging, which adds a merge commit to connect both branches, making history non-linear (option 2). Option 3 is incorrect; rebasing does not duplicate commits, and option 4 is incorrect because rebase specifically alters commit history.

2. Choosing the Appropriate Command

   Suppose you want your feature branch to maintain a clean, linear history with no merge commits before integrating it with the main branch. Which Git operation should you use?

   1. Revert
   2. Rebase
   3. Merge
   4. Branch

   Explanation: Rebase is used to restructure history into a straight line, removing unnecessary merge commits. Merge is incorrect here because it creates an extra merge commit. Branch is not an operation for bringing in changes; it just creates a new line of development. Revert undoes changes, which is unrelated to integrating branches.

3. Conflict Resolution Differences

   If both git rebase and git merge encounter the same conflicting file, what is a key difference in how the resolution is recorded in the repository's history?

   1. Rebase rewrites the original commits to include the resolutions, while merge records them in a merge commit
   2. Merge deletes conflicting files, while rebase renames them
   3. Neither operation requires manual conflict resolution
   4. Rebase ignores conflicts and proceeds, but merge stops entirely

   Explanation: When resolving conflicts during a rebase, the changes are applied directly to each affected commit, integrating the resolution into history. Merge, on the other hand, documents the resolution within a new merge commit. The second option is incorrect since both operations require resolving conflicts. The third option refers to behaviors not present in Git, and the fourth is clearly wrong as both require user intervention for conflicts.

4. Impact on Collaboration

   Why is it generally advised to avoid rebasing shared public branches that others may also be working on?

   1. Because rebasing alters commit hashes, which can disrupt collaborators' repositories
   2. Because rebasing always results in more merge commits
   3. Because rebasing increases repository size dramatically
   4. Because rebasing causes permanent data deletion

   Explanation: Rebase rewrites commit history and changes commit hashes, which can cause confusion and conflicts for others who have based work on the previous branch state. Option two is incorrect—rebase does not erase data unless forced and mishandled. Rebase reduces, not increases, merge commits (option 3). Repository size changes from rebasing are minimal, making option four incorrect.

5. Preserving Context in Project History

   In a large collaborative project where understanding when and why two branches combined is important for future debugging, which Git operation is preferable?

   1. Clone
   2. Merge
   3. Rebase
   4. Reset

   Explanation: Merge adds a merge commit, explicitly marking the point two lines of development were joined and preserving context for future reference. Reset is unrelated to combining branches; it moves the branch pointer. Rebase rewrites the history and removes the explicit merge event, making it less suitable for audit trails. Clone is used for copying a repository, not combining branches.