> 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.
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.