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.

Practice

1. What is the main reason for the golden rule of rebasing: never rebase public?

easy

A. Rebasing public branches speeds up the repository cloning process.

B. Rebasing public branches can rewrite shared history and confuse collaborators.

C. Rebasing public branches automatically merges all conflicts.

D. Rebasing public branches deletes all previous commits permanently.

Solution

1. Step 1: Understand what rebasing does

   Rebasing rewrites commit history by moving commits to a new base.

2. Step 2: Consider the effect on public branches

   If you rebase a branch others use, their history conflicts with the rewritten one, causing confusion and errors.

3. Final Answer:

   Rebasing public branches can rewrite shared history and confuse collaborators. -> Option B

4. Quick Check:

   Rebasing public = rewrite shared history = confusion [OK]

Hint: Never rebase branches others already use to avoid conflicts [OK]

Common Mistakes:

• Thinking rebasing speeds cloning
• Believing rebasing auto-resolves conflicts
• Assuming rebasing deletes commits permanently

2. Which of the following is the correct git command to rebase your current branch onto main?

easy

A. git rebase main

B. git rebase -m main

C. git rebase --merge main

D. git rebase --onto main

Solution

1. Step 1: Recall basic rebase syntax

   The command to rebase the current branch onto another is git rebase <branch>.

2. Step 2: Check options given

   Only git rebase main matches the correct syntax to rebase onto main.

3. Final Answer:

   git rebase main -> Option A

4. Quick Check:

   Basic rebase syntax = git rebase branch [OK]

Hint: Use 'git rebase branchname' to rebase current branch [OK]

Common Mistakes:

• Adding unnecessary flags like -m or --merge
• Using --onto incorrectly without extra arguments
• Confusing rebase with merge commands

3. You have a local branch feature that you rebased onto main. What happens if you try to push it to a remote where feature was already shared without force?

medium

A. Push merges remote changes automatically.

B. Push succeeds and overwrites remote history automatically.

C. Push deletes the remote branch.

D. Push is rejected because history has diverged.

Solution

1. Step 1: Understand rebasing effect on commit history

   Rebasing rewrites commits, so local branch history differs from remote.

2. Step 2: Consider git push behavior

   Git refuses to push if histories diverge to prevent overwriting others' work unless forced.

3. Final Answer:

   Push is rejected because history has diverged. -> Option D

4. Quick Check:

   Rebase + push without force = rejected [OK]

Hint: Push after rebase needs --force or fails [OK]

Common Mistakes:

• Assuming push overwrites remote without force
• Thinking push merges automatically
• Believing push deletes remote branch

4. You accidentally rebased a public branch and now collaborators have conflicts. What is the best way to fix this?

medium

A. Delete the remote branch and recreate it from scratch.

B. Tell collaborators to reset their branches to the new history.

C. Force push the rebased branch and ask collaborators to rebase or reset.

D. Merge the rebased branch into main to fix conflicts.

Solution

1. Step 1: Understand the problem caused by rebasing public branch

   Rebasing rewrites history, so collaborators' copies conflict with the new history.

2. Step 2: Fix by force pushing and coordinating with collaborators

   Force push updates remote with new history; collaborators must rebase or reset to sync.

3. Final Answer:

   Force push the rebased branch and ask collaborators to rebase or reset. -> Option C

4. Quick Check:

   Fix rebase public = force push + collaborator reset [OK]

Hint: Force push and coordinate resets after rebasing public branch [OK]

Common Mistakes:

• Expecting collaborators to fix without reset
• Deleting remote branch unnecessarily
• Merging rebased branch to fix history

5. You want to keep your commit history clean by rebasing, but your branch feature is already pushed and shared. What is the safest workflow to update your branch without breaking the golden rule?

hard

A. Create a new local branch from main, cherry-pick your commits, then push as a new branch.

B. Rebase the shared feature branch directly and force push.

C. Merge main into feature instead of rebasing.

D. Delete the remote feature branch and push your rebased branch with the same name.

Solution

1. Step 1: Avoid rebasing a shared branch directly

   Rebasing shared branches breaks history for others, so avoid it.

2. Step 2: Use a new local branch and cherry-pick commits

   Create a fresh branch from main, apply your commits cleanly, then push as new branch to avoid rewriting shared history.

3. Final Answer:

   Create a new local branch from main, cherry-pick your commits, then push as a new branch. -> Option A

4. Quick Check:

   Keep history clean = new branch + cherry-pick + push new [OK]

Hint: Use new branch + cherry-pick to avoid rebasing shared branches [OK]

Common Mistakes:

• Force pushing rebased shared branch
• Merging instead of rebasing when clean history needed
• Deleting remote branch unnecessarily