I'm a Systems Reliability and DevOps engineer for Netdata Inc. When not working, I enjoy studying linguistics and history, playing video games, and cooking all kinds of international cuisine.
On the first point, you're right, with the possible exception of your software needing to use one or the other of the variants (this approach is one way to do feature flags for big stuff, the problem is that it makes each feature managed this way mutually exclusive, which may or may not be a good thing depending on your software).
The correct way to mitigate merge conflicts is to regularly update the feature branch so that it's in-sync with the upstream branch it's based off of, either via rebasing (generally preferred if you're working on it solo, because it makes it easier in many cases to figure out how to fix what conflicts do arise as well as keeping the history cleaner) or back-merging the upstream branch into the feature branch. If your colleague can't manage to do this, the problem is him, not you.
On the second point, that's easily doable without the duplicates if you do your development right. Provided that each 'part' of the feature is a commit, you can easily merge in just some parts using git cherry-pick (that's exactly what cherry-picking is for actually. You should be developing this way anyway though, because it makes tracking down bugs a hell of a lot easier (git bisect is a wonderful tool, but it's useless if every feature is just one big commit (even more so in cases like this where you're keeping duplicate files)).
As far as convincing him of this, I would start by sending him through a proper course on how to use git. Most people who think this way were never actually properly taught to use version control correctly (or they were taught on classic monolithic VCS platforms instead of DVCS platforms). If you're lucky, that should be enough for him to figure out that you're right, and if not, it will at least make sure he's on the same page in terms of what git actually does.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
On the first point, you're right, with the possible exception of your software needing to use one or the other of the variants (this approach is one way to do feature flags for big stuff, the problem is that it makes each feature managed this way mutually exclusive, which may or may not be a good thing depending on your software).
The correct way to mitigate merge conflicts is to regularly update the feature branch so that it's in-sync with the upstream branch it's based off of, either via rebasing (generally preferred if you're working on it solo, because it makes it easier in many cases to figure out how to fix what conflicts do arise as well as keeping the history cleaner) or back-merging the upstream branch into the feature branch. If your colleague can't manage to do this, the problem is him, not you.
On the second point, that's easily doable without the duplicates if you do your development right. Provided that each 'part' of the feature is a commit, you can easily merge in just some parts using
git cherry-pick(that's exactly what cherry-picking is for actually. You should be developing this way anyway though, because it makes tracking down bugs a hell of a lot easier (git bisectis a wonderful tool, but it's useless if every feature is just one big commit (even more so in cases like this where you're keeping duplicate files)).As far as convincing him of this, I would start by sending him through a proper course on how to use git. Most people who think this way were never actually properly taught to use version control correctly (or they were taught on classic monolithic VCS platforms instead of DVCS platforms). If you're lucky, that should be enough for him to figure out that you're right, and if not, it will at least make sure he's on the same page in terms of what git actually does.