> Leave the rebasing to the git wizards who actually know what they're doing, in no circumstances should this be part of your day-to-day work.
This sounds like the refrain of someone who doesn't want to actually learn how one of the most fundamental tools of their profession works. I realize that git wasn't the optimal choice for the industry to settle on, but it's what we picked, and simply avoiding a feature that a majority (65%) of your peers use to at least some degree [0] will hamper your professional development.
Learn git. It's not pretty, but it's what we've got, and it's not going anywhere anytime soon.
That poll shows exactly the problem with rebase workflows. 41% say they mostly rebase but 48% do not know that merge/rebase conflicts have swapped order of local/incoming changes. Granted, the percentages are exactly right that those 41% might not at all overlap with the 48% but how likely is that?
The reality is that most people work on their private branches, alone. In that case it makes almost no difference if you rebase or merge. In almost any other scenario, merging still works as expected, while rebasing without understanding git will almost definitely lead to losing work and spending an absurd amount of time resolving conflicts. Why would you want to inflict that on yourself? Just use the approach that always works instead.
Learning Git really isn't high on the priority list for most developers, as they know what they need to use to get stuff done. The complexity gets really high really fast, so it's quite understandable why most people treat Git like DNS or other infrastructure - it's there, I know the basics to get stuff done and if anything goes wrong I ask an expert to take a look. And guess what? There is NOTHING wrong with that.
> 48% do not know that merge/rebase conflicts have swapped order of local/incoming changes
I'm well aware about the differing meaning of HEAD in merge and rebase, and if I had to think about it, would probably realize that it makes sense to always display HEAD first. And that as a consequence, the order would be swapped.
But I would definitely have answered "no" to the question as written.
This sounds like the refrain of someone who doesn't want to actually learn how one of the most fundamental tools of their profession works. I realize that git wasn't the optimal choice for the industry to settle on, but it's what we picked, and simply avoiding a feature that a majority (65%) of your peers use to at least some degree [0] will hamper your professional development.
Learn git. It's not pretty, but it's what we've got, and it's not going anywhere anytime soon.
[0] https://jvns.ca/blog/2024/03/28/git-poll-results/