For some reason, If the upstream merges my PR, I keep being ahead of the upstream by several commits. (For sync. If the local branch is behind, I'd just fetch but there seems to be issues due to diverging histories.)

May this be happening because they compress my X commits into 1 or a few?

In this case the codebase will be the same, but the history of commits completely different, so when they do a change in the branch, I cant merge (and end up rebasing).

Is it the upstream squashing commits giving troubles? Can provide a better insight as to what is happening?

CodePudding user response：

As a general principle, after performing a squash merge, delete the source branch. If you don't, as you've pointed out, you will have branches with the same code, but not the same history, and git will be unable to manage future merges between them.

In many workflows, deleting a branch as soon as it's been merged is expected anyway - each feature is a new branch from a shared and protected "master", "main", or "develop", which nobody will commit to directly.

If you need to base a new feature on a previous one which hasn't yet been merged, you can do so, but as soon as the first PR is merged you should rebase your second branch on top of the shared branch.