Should dive into more details about the negative consequences of merge commits. That’s what I use, as it is the standard on my team, but it rarely causes issues. I’m not opposed to rebase, I actually like it, but it seems that if you’re taking the “skill issue” approach, it goes both ways. If you can mess them both up, why should I actually consider switching?
@@GabrielSouza-sz5ju No, you don't loose your commit history with merge. Only if you squash commits before merging. Anyway, rebase is the way to go if you want to maintain a nice readable git history.
Merge commits create a branching tree structure in the Git history, which is inherently much harder to understand and reason about than a linear history. While it is *possible* to break stuff with rebase, if you take the (not very long) to learn how to do it, the mistakes are totally avoidable. The reward for switching to rebase is that your projects history is much easier to work with and understand.
Sure, it's a skill issue that I always get weird stuff happening when rebasing with conflicts (missing changes, duplicated commits). Merge conflicts are much easier to understand because both versions are the "latest" in their respective branches, so the resolved version becomes the new "latest" version of the file. But I get the impression that if a conflict occurs while rebasing, there are more future commits waiting to be applied to the "resolved" file.
