[0123456789ABCDE]

trying to parse your comment, and the story is only getting more convoluted, the more i reread it.

"rebasing 70+ commits from master on top of their branch" is not a real thing

like, i want to believe you. it just doesn't work the way you're describing it.

[Izkata]

I didn't catch the exact commands they were doing, but their branch was made that far back, that's how it was that many commits.

Support was putting that setting in ~/.gitconfig for all new laptops, and we didn't know it was there. I saw one of them going through this huge rebase and was suspicious about how a pull was causing a rebase at all since this wasn't the default (and this particular co-worker wasn't the kind to explore these settings), so we went looking for it. After removing the setting, the command they were running worked exactly as expected without any surprises. They'd also said they thought they were using git wrong somehow because that wasn't the first time it happened.

[0123456789ABCDE]

so, your colleagues merge features into `master` locally?

no pull-requests, no branch protections for `master`. i mean this works, but you probably need those rails in place.

[Izkata]

No, master is protected. I think they were trying to update their local master so they could resolve a merge conflict.