Merge vs rebase

Merge and rebase are both useful Git tools, but they serve different situations. Merge is presented as the option for joining histories while keeping the record of how branches converged. Rebase is presented as the option for cleaning up and rewriting history, especially on branches that are still not known to the remote.

Reading notes

#

• Merge is described as joining two or more development histories and is used to update main with a feature branch or update a feature branch with the latest work from main.
• Merge commits preserve conflict resolution at the merge level, so once conflicts are resolved they are not revisited in that merge.
• A fast-forward merge can keep history linear, but it hides the fact that a merge happened because no merge commit is created.
• Rebase re-applies commits on top of another base tip and is used to update a topic branch by resetting it to main and replaying its history.
• Rebase rewrites history and can be used to move commits in history or fix, squash, or rename previous commits.
• Rebasing usually requires resolving conflicts at the commit level, and the same conflicts may appear again if the base branch changes.
• Rebase should not be used to rewrite commits that other people have already pushed, because it can discard or rewrite their work and may require a force-push.
• git pull --rebase helps avoid an unnecessary merge commit when pulling a more recent remote version onto a branch that was rebased or force-pushed.
• The choice between merge and rebase depends on the goal and on the team’s agreed workflow.
• Merge is best for joining histories with visible context, while rebase is best for cleanup and branch maintenance before a branch is shared.