Sign In Create Account
Rebasing

Git Rebasing

Advanced Git techniques for maintaining clean, linear history and managing branches effectively.

When to Use Rebasing

Use rebasing to maintain clean, linear history and keep feature branches up to date.

✅ Use Rebase When:
  • • Cleaning up feature branch commits
  • • Updating feature branch with main branch
  • • Working on private/unshared branches
  • • Want linear, clean history
  • • Preparing branch for pull request
❌ Don't Rebase When:
  • • Branch is shared with other developers
  • • Working on main or develop branches
  • • You want to preserve exact history
  • • Unsure about Git history implications
  • • Collaborating on the same feature branch

⚠️ Rebase Safety Rules

  • Never rebase public branches: Only rebase feature branches
  • Use --force-with-lease: Safer than --force for pushing
  • Backup important branches: Create backup before major rebases
  • Communicate with team: Let others know about force pushes

Interactive Rebase for Cleanup

Use interactive rebase to clean up commits before creating pull requests.

Interactive Rebase Workflow

# Clean up commits before creating PR
git rebase -i HEAD~4

# Interactive options:
# pick = keep commit as-is
# reword = keep commit but edit message  
# edit = keep commit but allow editing
# squash = combine with previous commit
# fixup = like squash but discard commit message
# drop = remove commit entirely

# Example session:
pick f7f3f6d feat: add login form
reword 310154e fix: typo in form validation  
squash a5f4a0d fix: address code review feedback
drop c5f4a0d debug: temporary logging

# Git will process each command and prompt for input when needed

Interactive Rebase Use Cases

  • Squash WIP commits: Combine work-in-progress commits
  • Fix commit messages: Update messages to follow conventions
  • Remove unwanted commits: Drop debug or temporary commits
  • Reorder commits: Arrange commits in logical order

Keeping Feature Branch Updated

Regularly rebase your feature branch onto the latest develop branch to avoid conflicts.

Rebasing onto Latest Develop

# Update your feature branch with latest changes
git checkout feature/new-dashboard
git fetch origin
git rebase origin/develop

# If there are conflicts, resolve them:
# 1. Edit files to resolve conflicts
# 2. Stage the resolved files
git add .

# 3. Continue the rebase
git rebase --continue

# If you need to skip a commit (rare):
git rebase --skip

# If you need to abort and start over:
git rebase --abort

# Force push the rebased branch (only for feature branches!)
git push --force-with-lease origin feature/new-dashboard

Conflict Resolution Tips

  • • Use a merge tool like VS Code or GitKraken for complex conflicts
  • • Test your code after resolving conflicts
  • • Don't rush conflict resolution - take time to understand changes
  • • When in doubt, ask team members for guidance

Rebase vs Merge

Understanding when to use rebase versus merge is crucial for maintaining good Git history.

Rebase Results in Linear History

Linear History with Rebase

# Before rebase (with merge):
* a1b2c3d (main) Add payment feature
|\ 
| * d4e5f6g (feature) Fix validation bug
| * g7h8i9j Add user input form  
|/  
* j9k8l7m Update dependencies

# After rebase:
* d4e5f6g (feature) Fix validation bug
* g7h8i9j Add user input form
* a1b2c3d (main) Add payment feature  
* j9k8l7m Update dependencies

Merge Preserves Context

Merge Commit Shows Integration

# Merge commit preserves branch context:
* m1n2o3p (main) Merge branch 'feature/user-auth'
|\
| * p4q5r6s Add logout functionality
| * s7t8u9v Add login form
|/
* v1w2x3y Update base authentication

Rebase Benefits

  • • Clean, linear history
  • • Easier to follow progression
  • • Better for git bisect
  • • Reduces visual noise

Merge Benefits

  • • Preserves exact history
  • • Shows integration points
  • • Safer for shared branches
  • • Non-destructive operation

Advanced Rebase Techniques

Rebase onto Specific Commit

Use rebase --onto to move commits to a different base.

Rebase Onto Specific Commit

# Move commits from one branch to another
# Scenario: You branched off feature-a, but want to base on main instead

# Original state:
# main: A - B - C
# feature-a: A - B - C - D - E
# feature-b: A - B - C - D - E - F - G (branched from feature-a)

# Move feature-b commits (F, G) to be based on main (C):
git rebase --onto main feature-a feature-b

# Result:
# feature-b: A - B - C - F' - G' (F' and G' are rebased F and G)

Fixup Commits

Create fixup commits during development and squash them automatically.

Using Fixup Commits

# During development, create a fixup commit
git add .
git commit --fixup abc1234

# This creates a commit like: "fixup! original commit message"

# Later, auto-squash during rebase
git rebase -i --autosquash HEAD~5

# Git will automatically arrange fixup commits next to their targets
# and mark them for squashing

Preserving Merge Commits

Sometimes you need to rebase but preserve merge commits.

Rebase with Merge Commits

# Preserve merge commits during rebase
git rebase --rebase-merges origin/main

# This maintains the branch structure while rebasing

Rebase Safety and Recovery

🚨 Emergency Recovery

If rebase goes wrong, use the reflog to recover:

# Find the commit before rebase started
git reflog

# Reset to the commit before rebase (replace abc1234 with actual commit)
git reset --hard abc1234

# Alternative: use ORIG_HEAD (points to pre-rebase state)
git reset --hard ORIG_HEAD

✅ Rebase Safety Checklist

  • • ✓ Working on a feature branch (not main/develop)
  • • ✓ No one else is working on this branch
  • • ✓ Created backup branch: git branch backup-branch
  • • ✓ Clean working directory (no uncommitted changes)
  • • ✓ Using --force-with-lease instead of --force

Best Practices Summary

  • Start Small: Practice rebasing on throwaway branches first
  • Frequent Updates: Rebase feature branches regularly
  • Clean Before Share: Clean up commits before pushing to shared repository
  • Communicate: Warn team members about force pushes