Golden rule of rebasing (never rebase public) in Git - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why should you never rebase public branches?

In Git, what is the main reason you should avoid rebasing branches that are already public (shared with others)?

A Rebasing public branches rewrites history, causing conflicts for others who have based work on the original commits.

B Rebasing public branches deletes all previous commits permanently from the repository.

C Rebasing public branches automatically merges all changes without conflicts.

D Rebasing public branches speeds up the repository but loses commit messages.

💡 Hint

Think about what happens when history changes after others have copied it.

Rebasing changes commit history. If others have copies of the original commits, their history will not match, causing confusion and conflicts when they try to update.

💻 Command Output

intermediate

Output of rebasing a public branch

What will happen if you run git rebase main on a branch that has already been pushed and shared with others?

Git

git checkout feature
# feature branch is public and shared
git rebase main

A Git refuses to rebase and shows an error about public branches.

B Git merges main into feature branch without changing commit hashes.

C Git rewrites the feature branch commits on top of main, changing commit hashes and requiring force push.

D Git deletes the feature branch automatically.

💡 Hint

Consider what rebasing does to commit history and what is needed to update the remote branch.

Rebasing rewrites commits, changing their hashes. To update the remote branch, a force push is needed, which can disrupt others using that branch.

🔀 Workflow

advanced

Safe workflow to update a public branch without rebasing

You want to update your public feature branch with the latest changes from main without rewriting history. Which workflow should you follow?

A Delete the feature branch and create a new one from main.

B Use <code>git merge main</code> on your feature branch to combine changes without rewriting history.

C Use <code>git rebase main</code> and then force push to update the public branch.

D Reset the feature branch to main using <code>git reset --hard main</code>.

💡 Hint

Think about how to keep history intact while incorporating new changes.

Merging adds a new commit combining histories without changing existing commits, so it is safe for public branches.

❓ Troubleshoot

advanced

Resolving conflicts after rebasing a public branch

After rebasing a public branch and force pushing, your teammate reports conflicts when pulling. What is the best way to resolve this?

A Your teammate should ignore the conflicts and continue working.

B Your teammate should delete their local branch and clone the entire repository again.

C Your teammate should run <code>git pull --rebase</code> repeatedly until conflicts disappear.

D Your teammate should reset their local branch to the remote branch using <code>git reset --hard origin/branch</code>.

💡 Hint

Consider how to align local history with the rewritten remote history.

Resetting the local branch to the remote branch discards conflicting local commits and matches the rewritten history, resolving conflicts.

✅ Best Practice

expert

Choosing the right strategy for updating shared branches

You manage a shared repository with many collaborators. Which strategy best follows the golden rule of rebasing to keep history clean and avoid disrupting others?

A Use rebasing only on local or private branches before pushing, and use merging for public branches.

B Always rebase all branches, including public ones, to keep history linear.

C Never rebase any branch; always merge everything to avoid any history rewriting.

D Rebase public branches but never merge to keep the repository clean.

💡 Hint

Think about when it is safe to rewrite history and when it is not.

Rebasing is safe on local/private branches before sharing. For public branches, merging preserves history and avoids disrupting collaborators.