Git Rebase — A Practical, Pro-Friendly Guide With Clear Examples

Git Rebase - If you build features on branches while your teammates keep updating main, your branch falls behind. Syncing with merge can clutter history; rebase keeps it clean. Here’s a practical, production-ready guide you can follow before opening a PR, with crisp Practical guide & examples and copy-pastable commands.

TOC (Git Rebase - Practical guide and examples)

1. What Rebase Does and Why It Helps

2. Rebase vs Merge

3. Team Policies to Consider

4. How to Rebase Before a PR

5. Conflict Handling and Safety

6. Pull Strategies

7. Interactive Rebase

What “rebase” actually means

• You have commits on a feature branch based on an older point of main.

• Rebase lifts your commits and replays them on top of the latest main.

• You end up with the same changes, but based on the newest base.

Visual model Before:

1main:    A --- B --- C --- D
2feature:           X --- Y
3

After git rebase origin/main:

1main:    A --- B --- C --- D
2feature:                 X' --- Y'
3

X' and Y' are your changes replayed on top of D.

Rebase vs merge (quick comparison)

• Merge

  • Pros: Preserves actual integration history; simple.

  • Cons: Adds merge commits; history can get noisy.

• Rebase

  • Pros: Linear, readable history; easier for reviews, git log, and git bisect.

  • Cons: Rewrites commits (new SHAs); coordinate before rebasing shared branches.

Safe rule of thumb: Rebase your own feature branches to sync with main. Your team can still integrate via PR using merge, squash, or “rebase and merge” depending on policy.

Team policies and when to prefer each

• Linear-history repos:

  • Require rebase or squash. You’ll likely need to rebase locally and push with lease.

• Merge-commit repos:

  • Prefer merging main into your branch; rebasing shared branches may be discouraged.

• PR strategies:

  • Squash merge keeps a clean main without requiring local rebase.

  • Rebase and merge rewrites your branch on the server for linear history.

• Protected branches:

  • If force-push is disabled, avoid rebasing after publishing; either coordinate, or open a new branch/PR.

• Fast-forward preference:

  • Some teams set pulls to fast-forward only:

    1git config --global pull.ff only

Step-by-step: Rebase before opening a PR Scenario:

• Branch: feature/login-form

• main has moved ahead

1. Save your work Option A — commit WIP:

1git add .
2git commit -m "WIP: current changes"
3

Option B — stash instead of WIP commit:

1git stash -u
2

1. Update local view of remote

1git fetch origin
2

1. Ensure your local main is current (optional but common)

1git checkout main
2git pull origin main
3

1. Switch back and rebase onto the remote main

1git checkout feature/login-form
2git rebase origin/main
3

What Git does:

• Temporarily lifts your commits

• Moves your branch to the latest remote main

• Replays your commits one by one

1. Resolve conflicts (if any)

1git status           # see conflicted files
2# fix files, then:
3git add <file>       # repeat per file
4git rebase --continue
5# bail out if needed:
6git rebase --abort
7

Tips for resolving conflicts

• Start with small/obvious files to build momentum.

• Use a merge tool:

1git mergetool
2

• Enable rerere to remember resolutions:

1git config --global rerere.enabled true
2

• Run tests after resolving:

1npm test    # or your test runner
2

If you stashed earlier, restore after rebase:

1git stash pop
2

1. Push safely after rebase

1git push --force-with-lease origin feature/login-form
2

Why lease: avoids overwriting new remote commits you don’t have. If branch protection forbids force-push, coordinate with the team or push a new branch and open a new PR.

git pull vs git pull --rebase

Default pull (fetch + merge):

1git pull
2

History may include a merge commit if there’s divergence:

1A --- B --- C --- M
2 \             /
3  D --- E ----
4

Note: If your branch has no local commits, git pull fast-forwards without a merge commit.

Pull with rebase (fetch + rebase):

1git pull --rebase
2

History stays linear:

1A --- B --- C --- D' --- E'
2

Which should you use?

• Use git pull if your team is fine with merge commits and wants to preserve the integration graph.

• Prefer git pull --rebase if your team wants a clean, linear history—great before opening PRs.

Make pulls smoother

• Prefer rebase on pull by default:

1git config --global pull.rebase true
2

• Auto-stash before a pull rebase:

1git config --global rebase.autoStash true
2

Interactive rebase to polish commits Use this to squash fix-ups, reorder, or reword messages before a PR.

1git fetch origin
2git checkout feature/login-form
3git rebase -i origin/main
4

In the editor:

1pick abcd123 feat(login): add form skeleton
2pick bcde234 fix: correct validation
3pick cdef345 chore: adjust tests
4

Tidy by squashing:

1pick abcd123 feat(login): add form skeleton
2fixup bcde234 fix: correct validation
3fixup cdef345 chore: adjust tests
4

Finalize, then force-push safely:

1git push --force-with-lease
2

Troubleshooting and recovery

• Abort mid-rebase:

1git rebase --abort
2

• Inspect recent tips and recover with reflog:

1git reflog
2git reset --hard <commit>      # restore to a known good point
3# or create a rescue branch:
4git checkout -b rescue/<topic> <commit>
5

• Note: Rebasing rewrites commit SHAs. Links to old SHAs (e.g., in code reviews) won’t match after a rebase.

Small, focused commits help Keep commits scoped and descriptive. Examples:

1feat(login): validate email format
2fix(login): trim whitespace before submit
3test(login): add invalid email cases
4

Daily workflow you can copy

 1# Update remote state and main
 2git fetch origin
 3git checkout main
 4git pull origin main
 5
 6# Rebase your branch onto remote main
 7git checkout feature/xyz
 8git rebase origin/main
 9
10# Resolve conflicts
11git status
12# edit files
13git add <file>
14git rebase --continue
15
16# Verify locally
17npm run lint
18npm test
19
20# Push safely
21git push --force-with-lease
22

Bottom line Git Rebase - Practical guide and examples keeps your feature branches fresh and history clean. Rebase your own branches before PRs, resolve conflicts carefully, and push with --force-with-lease. Match your approach to team policy: some repos enforce linear history and rebase/squash, others prefer merge commits and disallow force pushes. When in doubt, base onto origin/main, communicate early, and keep commits small..

References

• Git Book: Rebasing

  • https://git-scm.com/book/en/v2/Git-Branching-Rebasing

• Git Docs: git rebase

  • https://git-scm.com/docs/git-rebase

• Pro Git (free book): Branching, Merging, and Rebasing chapters

  • https://git-scm.com/book/en/v2

• GitLab Docs: Merge methods and fast-forward

  • https://docs.gitlab.com/ee/user/project/merge_requests/methods/