[reledi]

This seems like a knee jerk reaction because a co-worker's sloppy rebase caused you to waste a day.

This highlights a bigger issue, many people don't learn their tools well enough.

I've been teaching my fellow senior engineers how to use git the last six months because they've only been using git GUIs until then. They're terrified of merge conflicts and they often make mistakes fixing them.

I'd rather educate people and let them make their own decisions once they can understand and justify the tradeoffs.

[plicense]

My thoughts precisely. I mostly use rebase, except when I know multiple commits in my feature branch will cause merge conflict with master - in that case, I save myself the trouble, do a merge and be done with resolving all conflicts in one go.

My ideology is - prefer rebase first, resort to merge if it will let you do the gnarly merge fast. Of course this is because of the development environment I work in where we just don't use bisect and the workflow is different. I also keep in mind that if I work on a different repository with differing testing/development processes this ideology will change.

The first few days I work on any new project(due to a job/project transition), I figure out how I can iterate as fast as I can and see what my time saving points are. How to best use the git I know, on the current repo, is also a minor part of this poking process.

[icek]

Merge conflicts, history readability, and PR readability are just the things that rebase helps with. I understand, I have coworkers who said "keep things simple; you shouldn't have to be an expert in VCS" as if learning how to use your tools is a bad thing! It's not like Git even takes that long to master.