Why rebasing creates linear history in Git - Challenge Your Understanding

Challenge - 5 Problems

🧠 Conceptual

intermediate

What does rebasing do to commit history?

Imagine you have a feature branch diverged from main. What does rebasing your feature branch onto main do to the commit history?

A It creates a new linear sequence of commits by moving feature commits on top of main's latest commit.

B It merges main into feature, creating a merge commit and preserving all branches.

C It deletes the feature branch and replaces it with main branch commits.

D It duplicates all commits from main into feature branch without changing order.

💡 Hint

Think about how rebasing changes the base of your feature branch commits.

Rebasing takes your feature branch commits and replays them on top of the latest commit of main, creating a straight, linear history without merge commits.

💻 Command Output

intermediate

Output after rebasing a feature branch

You have a main branch with commits A-B-C and a feature branch with commits D-E diverged from B. You run git rebase main on feature. What does git log --oneline --graph show for feature branch?

A * E<br>* D<br>* B<br>* C<br>* A

B * E' (rebased)<br>* D' (rebased)<br>* C<br>* B<br>* A

C * C<br>* B<br>* A<br>* D<br>* E

D * E<br>* D<br>* C<br>* B<br>* A

💡 Hint

Rebased commits get new commit IDs and appear on top of main's latest commit.

After rebasing, commits D and E are replayed on top of commit C, creating new commits D' and E' that form a linear history.

❓ Troubleshoot

advanced

Why does rebasing cause conflicts?

When rebasing a feature branch onto main, you encounter conflicts. Why does this happen?

A Because rebasing resets the repository to an earlier commit, losing recent changes.

B Because rebasing deletes all commits from main, causing missing files.

C Because rebasing re-applies commits on top of main, conflicting changes in the same files cause conflicts.

D Because rebasing merges main and feature branches automatically without checking differences.

💡 Hint

Think about what happens when commits are replayed on a different base.

Rebasing re-applies each commit on top of main. If both branches changed the same lines, conflicts occur that must be resolved manually.

🔀 Workflow

advanced

Choosing between merge and rebase for a clean history

You want to keep your project history linear and easy to read. Which workflow should you use?

A Use <code>git rebase</code> to move feature branch commits on top of main before merging.

B Use <code>git merge --no-ff</code> to always create merge commits.

C Use <code>git cherry-pick</code> to copy commits from main to feature branch.

D Use <code>git reset --hard</code> to discard feature branch commits.

💡 Hint

Think about which command rewrites history to be linear.

Rebasing rewrites commits to create a straight line of history, avoiding merge commits and making the log easier to follow.

✅ Best Practice

expert

When should you avoid rebasing a branch?

Which situation is a best practice reason to avoid rebasing a branch?

A When you want to update your branch with the latest commits from main.

B When you want to squash multiple commits into one for clarity.

C When you want to create a linear history before merging your feature branch.

D When the branch is shared with others and rebasing would rewrite public history.

💡 Hint

Consider the impact of rewriting history on collaboration.

Rebasing rewrites commit history. If others use the branch, rewriting history can cause confusion and conflicts. Avoid rebasing public/shared branches.