What's happening here is that branch Y was created from commit X, and the maintainer did not rebase branch X onto branch Y before merging. It's not advised (more on that later), but nothing is stopping you from doing it either. > Y1 -- Y2 -- Y3 (branches before merging) > / > ... -- X -- X1 -- X2 This situation is pretty easy to never run into if you only have a single person working on a repository at a time. I'll use my own repository as an example: https://github.com/Manouchehri/smi2021/commits/staging You'll notice I don't even have a single merge in the history, and the other developers don't have write access either. Because everybody has the same HEAD, I can just rebase their branch onto mine (none of their commit hashes will change unless I start changing history, which I did by mistake on one large batch of commits; oops). In a large project, what I did above becomes unmanageable very quickly. Keeping a hundred developers all up to date with the exact same source gets difficult. (Rebasing is also probably a bad idea if I start changing their commit hashes.) The reason why keeping your branch HEADs up to date is /suggested/ is because you'll never have any conflicts during a merge (since they would already have to be solved). In general, it's more likely that the developer who created the conflict will have a better idea on how to solve it compared to the repository maintainer (assuming that role is a different person). If you're coming from Subversion, sync merge is basically the same as rebasing your master branch onto your feature branch to keep it up to date.