Every team that uses Git ends up, sooner or later, in one of those slightly annoying debates about merge and rebase. Someone defends one, someone defends the other, and in the end most devs keep using both without really understanding why they picked one over the other in that specific moment. Let's try to make this less confusing, with examples you've probably already lived through. Start with what each command actually does under the hood, because that explains everything else. When you run a merge, Git takes the two ends of history, your branch and the target branch, and creates a new commit that has two parents. That merge commit is literally a junction point in the graph, you can see in it that two lines of work met right there. The old history stays untouched, nothing gets rewritten, you just add one new node tying everything together. Rebase does something quite different. It takes each commit you made on your branch, one at a time, and recreates it on top of the latest tip of the target branch. Recreates it for real, with a new hash, author and message preserved but the position in history is different. If you had three commits on your feature, after the rebase you still have three commits, except now they were "born" after the most recent commits on main, not before. That's why the end result looks like a straight line, without those junction nodes. Nice to look at, but it comes with a cost. That cost shows up when someone else already pulled that branch before the rebase. Since the commits change hashes, for anyone who already had the old version, pulling afterward will look like history diverged out of nowhere, and they usually end up with duplicated commits or a confusing conflict that shouldn't even exist. There was this one time a colleague rewrote the history of a shared branch without telling anyone, and we spent the whole afternoon trying to figure out why each of our repos was showing something different. It wasn't malicious, just not knowing this rule. And that rule even has a name, the "golden rule of rebasing": never rewrite history that's already been shared with other people. If the branch is only yours, local, hasn't been pushed to the remote yet or at least nobody else pulled it, feel free to rebase all you want. The moment someone else starts working on top of that history, rebase turns into a dangerous operation. In practice, the pattern that seems to work best is a mix of both. You work on your feature branch locally, making somewhat messy commits, "fix", "tweak", "not sure why this wasn't compiling before" — and before opening the pull request, you run an interactive rebase to clean all that up. `git rebase -i HEAD~5` opens a list of the last five commits and lets you squash, reorder or even edit messages. That leaves the history readable for whoever reviews it later. Only after that process do you sync with main, usually with `git rebase main` to bring in the latest changes without creating a merge commit along the way. When it's time to bring that feature back into main, that's usually where merge comes in, often with the `--no-ff` flag to force a junction commit even when a fast-forward would be possible. That keeps a record that this set of commits represents a specific feature, which helps a lot if you ever need to revert it entirely or just understand in the history where it started and ended. Conflicts also behave differently depending on the command. With merge, if there's a conflict, you resolve it once, in the merge commit, and that's it. With rebase, if your branch has several commits and more than one of them touches the same line that was changed on main, you might end up resolving basically the same conflict multiple times, once for each commit that passes over that section. It's tedious, but it also gives a more granular view of exactly where things diverged, which sometimes helps you understand the problem better than one giant single conflict would. If the rebase gets stuck halfway and turns into a mess you don't know how to fix anymore, `git rebase --abort` undoes everything and puts the repository back to how it was before you started. Worth remembering that in the panic moment, because a lot of people forget you can just cancel and try again more calmly. In the end, I think the choice between merge and rebase is less about which one is "correct" and more about what point in the workflow you're at. A local branch that's only yours, rebase keeps things cleaner. A branch that's already shared or already became a pull request with other people commenting on it, merge is the safer path. Teams using GitHub or GitLab with squash merge on the pull request kind of settle this debate on their own, since no matter how many messy commits you made, in the end it all becomes one single commit on main. But that's a different conversation.