I think the problem is with your workflow: usually once you merge a pull request (no matter which method you use) you are then done with that branch. If you want to do further changes, you better create a new feature branch out of current upstream/master and later you could open another pull request to merge it back.

In case you really want to stick to a single long-lived branch for all development (the one you call dev), there are a few caveats you have to keep in mind:

If you are not the only one working on that branch, you have to avoid any kind of history rewriting. No rebasing, no squashing, no resetting, not even amending commits. This basically rules out using squash merge.

If you are sure you are the only one working on that branch, and you use GitHub's squash option to merge pull requests as you did, then you must reset you local dev branch to latest upstream/master before resuming your work there. That also means that later you will need to force-push to upstream to create a new pull request.

The last point is error-prone and will affect previous code reviews so personally I would choose to just use short-lived feature branches.