Frequently Asked Question

What's the difference between merge and rebase, and when should I use each?

Both commands integrate the changes from one branch into another, but they produce different shapes of history. git merge other creates a new merge commit on the current branch whose two parents are the previous tip and the tip of other. The original commits on both sides are preserved unchanged; the history is a graph, not a straight line. git rebase other instead takes the commits on your current branch that are not on other, replays them one by one on top of other's tip, and gives each replayed commit a new hash. The history afterwards is linear, as though you had developed your work on top of other from the start.

A common rule: rebase your local branches before pushing, to keep history tidy and avoid pointless merge commits, but never rebase a branch that other people have already pulled, you will rewrite hashes that they have a copy of, and their next pull will be a mess. Merge is the safe choice for any branch that is shared. Many teams adopt a hybrid: rebase feature branches against main while developing, then merge them in via a pull request.