We just realised that commits in a pull requests are visualized in the chronological order of their creation, rather than their actual commit order in the branch that should be merged. See
I'm a bit surprised to find such a fundamently issue in this prominent feature - or is this a recent regression of the UI?
When merging a branch, the actual order in that branch defines the merging order. That may differ (like in this case) from the creation order of a commit if you used git rebase on that branch prior to publishing it. That's in fact a pretty common workflow when designing clean patch queues in a logical (rather than just chronological) order.
It also has been hapenning to me for at least a few days. Fixing up old commits makes the visual order in github wrong. Hope this problem resolves soon.
I've ran into this issue a number of times. It's quite frustrating to organize a large change into a sequence of small logical steps only to have those steps displayed in the wrong order on the PR. Any chance of this getting addressed by github?