Merge vs rebase
Two ways to integrate changes from one branch into another. Merge preserves history as it happened (with a merge commit). Rebase rewrites your branch on top of another, producing a linear history.
You finished a feature branch. To bring its commits into main, you have two choices: merge or rebase. Different shapes, different trade-offs.
Merge (git merge feature while on main): Git creates a new 'merge commit' that has TWO parents — your main tip and your feature tip. History keeps the branching shape. You see clearly where work happened in parallel.
Rebase (git rebase main while on feature): Git replays your feature commits ONE BY ONE on top of main's tip. The branch shape disappears — history looks linear, as if you had worked on main all along.
Rule of thumb: merge for shared/public branches, rebase for private/local cleanup. If others have already pulled your feature, rebasing rewrites commits they have — they'll get conflicts on the next pull. Don't rebase shared history.
Many teams adopt: 'rebase your branch on main before opening a PR (clean history) → then merge the PR (keeps the merge commit as a marker)'. Best of both worlds.
Practice
You're on `feature`. Type the command to replay your commits on top of `main`.
Practice
You're in the middle of a rebase and you've resolved the conflicts. Type the command to continue.
Practice
Choose the right tool:
Cleaning up local commits before a PR: . Bringing a finished feature into a shared `main` while preserving the merge point: .
Grounded on https://git-scm.com/book/en/v2/Git-Branching-Rebasing
Next up
Resolving merge conflicts
Two branches changed the same lines? Git pauses, marks the conflict in the file, and waits for you to choose. Edit, stage, continue.