What is the difference between git merge and git rebase?

Merge joins two branches and, if they diverged, adds a merge commit with two parents. Existing history stays exactly as it happened. Rebase replays your commits one by one on top of another branch. The result is a straight line, but each replayed commit gets a new hash.

Use rebase to tidy or update your own local or unshared feature branch before integrating it. Use merge to bring work into shared branches like main or release branches, where others have already pulled the commits. A common pattern is to rebase privately and merge publicly.

Never rebase commits that other people have already pulled. Rebase creates new commits with new hashes. Anyone who built on the old ones will get duplicate commits and confusing conflicts when they sync. Rebase only history that is still private to you.

A commit hash covers its content, its parent hash, the author and committer data, and the message. Rebase gives each commit a new parent and a new committer timestamp. So Git writes new commit objects with new hashes, even when the code changes are identical.

Merge compares the two branch tips with their merge base, so you resolve all conflicts once, in a single step. Rebase applies commits one at a time, so the same area can conflict at several steps. You fix each one, run git add, then run git rebase --continue.

If the current branch has no commits of its own since the other branch split off, Git just moves the branch pointer forward. No merge commit is created and history stays linear. Rebasing a feature branch onto main first often makes a fast-forward merge possible.

git rebase -i opens a todo list of commits that you can edit. You can reorder commits, squash or fixup them together, reword messages, edit their contents, or drop them. It is the standard way to clean up a branch before opening or merging a pull request.

git pull fetches and then integrates the upstream changes, by merge or fast-forward unless configured otherwise. git pull --rebase fetches, then replays your local unpushed commits on top of the upstream branch. This avoids noisy commits like "Merge branch main of origin" in your history.

Run git rebase --abort to return the branch to where it was before the rebase started. Run git merge --abort to undo an in-progress merge that has conflicts. Both only work while the operation is still in progress, before it finishes.

Use git reflog to find the commit your branch pointed to before the rebase, then run git reset --hard to that entry. Right after a rebase, ORIG_HEAD usually points to the old tip too. The old commits stay reachable through the reflog until garbage collection removes them.