> Especially because on of the major advantages of merge is that you can squash your local commit history when you submit it to your main branch. Squashing is

> Especially because on of the major advantages of merge is that you can squash your local commit history when you submit it to your main branch. Squashing is in no-way limited to merging and is actually done by doing an interactive rebase. Nothing is stopping you from squashing without creating a merge commit. It's entirely separate. If you're squashing everything anyway, what does merging even give you? Is your main branch just: * merge B * squashed commit B * merge A * squashed commit A If you didn't merge, you'd have: * squashed commit B * squashed commit A > What we do is that we tie every pull request to a relatively small feature task, and because we do this, we genuinely don’t care about the individual commits developers do. Except eventually there is a large feature task and then you end up with a giant commit that is annoying when git-bisecting. But at the end of the day, these things only matter if you are spelunking through git history and/or using things like git bisect. If your git history is "write-only & rollback", then none of this stuff matters.