Golden rule of rebasing (never rebase public) in Git - Mini Project: Build & Apply

Golden Rule of Rebasing (Never Rebase Public)

📖 Scenario: You are working on a shared project with your team using Git. You want to understand why rebasing commits that have already been shared with others (public commits) can cause problems.This project will guide you through creating a simple Git commit history, marking commits as public or private, and practicing safe rebasing only on private commits.

🎯 Goal: Learn how to identify public and private commits in Git and practice rebasing only private commits to avoid disrupting your team's work.

📋 What You'll Learn

Create a list of commits with their public/private status

Add a variable to mark the current branch's public commit hash

Write a function to rebase only commits that are not public

Print the list of commits after safe rebasing

💡 Why This Matters

🌍 Real World

In real software projects, developers share commits with teammates. Rebasing commits that others already have can cause conflicts and confusion. This project shows how to avoid rebasing public commits.

💼 Career

Understanding safe rebasing is essential for collaborative software development roles like DevOps engineers, software developers, and release managers to maintain clean and stable project history.

1

Create a list of commits with public/private status

Create a list called commits with these exact dictionaries representing commits: {'hash': 'a1b2c3', 'message': 'Initial commit', 'public': true}, {'hash': 'd4e5f6', 'message': 'Add feature', 'public': false}, {'hash': 'g7h8i9', 'message': 'Fix bug', 'public': false}.

Git

# Create the commits list with exact entries
# Your code here

Hint

Use a list of dictionaries. Each dictionary must have keys: 'hash', 'message', and 'public' with exact values.

2

Mark the current branch's public commit hash

Create a variable called public_commit_hash and set it to the string 'a1b2c3' to mark the last public commit.

Git

commits = [
    {'hash': 'a1b2c3', 'message': 'Initial commit', 'public': True},
    {'hash': 'd4e5f6', 'message': 'Add feature', 'public': False},
    {'hash': 'g7h8i9', 'message': 'Fix bug', 'public': False}
]
# Set the public_commit_hash variable
# Your code here

Hint

Assign the exact string 'a1b2c3' to the variable public_commit_hash.

3

Write a function to rebase only private commits

Write a function called safe_rebase that takes the commits list and public_commit_hash string as parameters. It should return a new list with only commits after the public commit (where commit['public'] is false). Use a for loop with variable commit to iterate over commits.

Git

commits = [
    {'hash': 'a1b2c3', 'message': 'Initial commit', 'public': True},
    {'hash': 'd4e5f6', 'message': 'Add feature', 'public': False},
    {'hash': 'g7h8i9', 'message': 'Fix bug', 'public': False}
]

public_commit_hash = 'a1b2c3'

# Define safe_rebase function that returns only private commits
# Your code here

Hint

Use a flag found_public to start collecting commits only after the public commit hash is found.

4

Print the list of commits after safe rebasing

Call the safe_rebase function with commits and public_commit_hash. Store the result in rebased_commits. Then print rebased_commits.

Git

commits = [
    {'hash': 'a1b2c3', 'message': 'Initial commit', 'public': True},
    {'hash': 'd4e5f6', 'message': 'Add feature', 'public': False},
    {'hash': 'g7h8i9', 'message': 'Fix bug', 'public': False}
]

public_commit_hash = 'a1b2c3'

def safe_rebase(commits, public_commit_hash):
    rebased_commits = []
    found_public = False
    for commit in commits:
        if commit['hash'] == public_commit_hash:
            found_public = True
            continue
        if found_public and not commit['public']:
            rebased_commits.append(commit)
    return rebased_commits

# Call safe_rebase and print the rebased commits
# Your code here

Hint

Call safe_rebase(commits, public_commit_hash), assign to rebased_commits, then print it.

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