pull vs rebase - How to Keep Branches Up to Date

While working on a branch, main may be updated and your branch can become outdated. That is when you use git pull and git rebase. Both bring in remote changes, but they handle history differently.

The Difference Between pull (merge) and rebase

Operation	Feature	Best For
git pull (merge)	Keeps history as is. Creates a merge commit	When you want to bring in shared branch updates as they are
git rebase	Makes history linear. Reapplies commits on top of the latest main	When you want to update your own local branch

History Shape for pull (merge)

main:    A──B──C──────M
                  ↗    ↘
feature:      D──E

A merge commit (M) is created, and the histories of both main and feature are preserved.

History Shape for rebase

main:    A──B──C
                 ↘
feature:          D'──E'

The feature commits (D, E) are moved after the latest main commit (C) and become D' and E', so history becomes a straight line.

Step-by-Step Workflow

1. Clone the repository (first time only)

git clone https://github.com/someone/repo.git
cd repo

2. Update local main

git checkout main
git pull origin main

3. Rebase your working branch

git checkout my-feature
git rebase main

The commits on my-feature are rearranged on top of the latest main.

4. Resolve conflicts

If conflicts occur during rebase, follow these steps:

1. Open the conflicted file in your editor and fix the part marked with <<<<<<<
2. Stage the fixed file

git add path/to/file

3. Continue the rebase

git rebase --continue

If you want to stop, return to the original state with:

git rebase --abort

5. Push

Push the rebased branch:

git push -u origin my-feature

⚠️ Rebase rewrites history. If you rebased a branch that you already pushed, a normal git push will be rejected. If the branch is yours alone, use --force-with-lease.

git push --force-with-lease origin my-feature

--force-with-lease is a safer force push because it fails if someone else has already pushed to the remote branch. It is safer than a plain -f.

Which Should You Use?

Branch used only by you -> rebase (clean history)
Shared branches or main  -> pull (merge) (do not rewrite history)

⚠️ Using rebase on shared branches such as main can break other people’s history. Avoid rebasing shared branches.

Command Reference for pull and rebase

Purpose	Command
Update main	git pull origin main
Align a working branch with main (merge)	git merge main
Align a working branch with main (rebase)	git rebase main
Continue after resolving conflicts during rebase	git rebase --continue
Stop the rebase	git rebase --abort
Safely force-push a rebased branch	git push --force-with-lease origin branch

Summary

• rebase: Use it when you want to update a branch you use by yourself. It makes history linear and easier to read.
• pull (merge): Use it when bringing in updates to shared branches or when you want to keep history unchanged.
• --force-with-lease: A safer option for force pushing after rewriting history. Avoid plain -f.

FAQ

Q. There is also git pull --rebase; how is that different from git rebase?

git pull --rebase does git fetch + git rebase in one step. It gets the latest remote commits and reapplies your local commits on top of them. The effect is almost the same, but it is convenient because you can write it in one line, such as git pull --rebase origin main.

Q. Did rebase delete my old commits?

No. The commit hash (ID) changes, but the content is preserved. If you check git log, you can see the same changes moved to a new place.

Q. Are there rules for using rebase in a team?

A common rule is “Do not rebase commits that have already been pushed.” If you rewrite history on shared branches such as main or develop, it can affect other members’ work. Rebase should be limited to local branches used only by you.