I agree, I too think merges are kinda weird, but maybe it's just you and me having a different mental model. I like small, atomic commits that do just one thin

I agree, I too think merges are kinda weird, but maybe it's just you and me having a different mental model. I like small, atomic commits that do just one thing. I frequently rebase onto master whenever I'm working on a feature. When my branch is good to be taken into master, I do a fast-forward merge (basically a commit by commit patch application); no magical merge commit from nowhere. Of course, FF merges are possible only when you're rebased. Things people not used to this workflow might think will be a problem: >Conflicts when I rebase from master Solve them. They're going to happen anyway when you merge into master, so it's easier for everyone if you resolve your conflicts then and there. >Multiple people need to work on the same feature branch Sure, do your work locally. Before pushing, fetch the remote branch and rebase onto it as well. Resolve conflicts and your work history will be pristine. Ask everyone on the team to do the same and nobody will have to resolve somebody else's merge conflicts (because you're the best person to resolve your conflict).