Fetching, Rebasing, and Cherry-picking

Working on a team means constantly synchronizing with others. This lesson covers the commands for staying up-to-date without losing your work.

Git Fetch

Fetch downloads remote changes without modifying your working tree.

bash
1$ git fetch origin
2From github.com:team/project
3 * [new branch]      feature/api -> origin/feature/api
4   1a2b3c4..5d6e7f8  main        -> origin/main

Fetch vs Pull

Fetch is safer—it lets you inspect changes before integrating them:

bash
1$ git fetch origin
2$ git log main..origin/main --oneline   # See what's new
3$ git merge origin/main                  # Then merge

Fetch All Remotes

bash
1$ git fetch --all

Rebasing

Rebase replays your commits on top of another branch, creating a linear history.

Why Rebase?

Compare merge vs rebase:

Merge creates a merge commit:

1main:    A---B-------M
2              \     /
3feature:       C---D

Rebase creates linear history:

main:    A---B---C'---D'

Basic Rebase

bash
1$ git checkout feature-branch
2$ git rebase main
3First, rewinding head to replay your work on top of it...
4Applying: Add feature X
5Applying: Fix bug in feature X

Pull with Rebase

Instead of creating merge commits when pulling:

bash
1$ git pull --rebase origin main

This is equivalent to:

bash
1$ git fetch origin
2$ git rebase origin/main

Rebase Workflow

Keep your feature branch up-to-date:

bash
1# 1. Switch to feature branch
2$ git checkout feature/my-feature
3
4# 2. Fetch latest changes
5$ git fetch origin
6
7# 3. Rebase onto updated main
8$ git rebase origin/main
9
10# 4. Force-push if already pushed
11$ git push --force-with-lease origin feature/my-feature

When to Rebase vs Merge

Golden Rule of Rebasing

Never rebase commits that have been pushed to a shared branch.

Rebasing rewrites history. If others have based work on your commits, rebasing causes divergence and confusion.

Cherry-picking

Cherry-pick copies a specific commit from one branch to another.

Basic Cherry-pick

bash
1$ git cherry-pick 5d6e7f8
2[main 9a0b1c2] Fix critical bug
3 Date: Sun Nov 30 10:00:00 2025 +0000
4 1 file changed, 2 insertions(+)

When to Cherry-pick

• Apply a hotfix from a feature branch to main
• Backport a fix to a release branch
• Pull specific work without merging entire branch

Cherry-pick Multiple Commits

bash
1# Specific commits
2$ git cherry-pick abc123 def456
3
4# Range of commits
5$ git cherry-pick abc123..def456

Cherry-pick Without Committing

Stage the changes but don't commit:

bash
1$ git cherry-pick -n 5d6e7f8

This lets you modify the changes before committing.

Handling Conflicts

Both rebase and cherry-pick can cause conflicts.

During Rebase

bash
1$ git rebase origin/main
2Auto-merging app.js
3CONFLICT (content): Merge conflict in app.js
4error: could not apply abc123... Feature X

Resolution:

bash
1# 1. Fix the conflict in app.js
2$ vim app.js
3
4# 2. Stage the resolution
5$ git add app.js
6
7# 3. Continue rebase
8$ git rebase --continue

Or abort:

bash
1$ git rebase --abort

During Cherry-pick

bash
1$ git cherry-pick 5d6e7f8
2error: could not apply 5d6e7f8... Fix bug

Resolution:

bash
1$ vim conflicted-file.js
2$ git add conflicted-file.js
3$ git cherry-pick --continue

Force Push Safely

After rebasing a pushed branch, you need to force push:

bash
1# Safe: Checks that remote hasn't changed
2$ git push --force-with-lease origin feature-branch
3
4# Unsafe: Overwrites unconditionally
5$ git push --force origin feature-branch

Always use --force-with-lease to avoid overwriting teammates' work.

Key Commands Summary

Key Takeaway

Use fetch to see what's new, rebase to keep feature branches linear, and cherry-pick for targeted commit copies. Never rebase shared branches, and use --force-with-lease when force pushing.