Pull requests are made between branches - you ask the target repo's owner to pull one of your branches to one of his.
If you want to make a pull request consisting in just a single commit, then you have to get a branch that only differs in that commit with the target one.
The best thing you can do now, I think, is
git fetch your upstream remote, and then create a branch starting from one of it's branches. You'd normally branch off
upstream/master (but it could be a different branch if you are not targeting
master in your pull request). The command
git checkout -b my-feature upstream/master would do the trick - provided those names match the ones you have.
If that worked, you're now on a brand new branch called
my-branch, that points to the very same commit your
master branch points to. At this moment, you can
git cherry-pick that single commit you wanted to appear in the PR (or you could manually edit the files and
git commit again, as you'd prefer - the key is you get your commit done over there). And now, as you have this new commit in the feature branch,
git push your branch to your own repo (say,
git push origin my-feature). That would create (if it didn't exist, which would be the best) the
my-feature branch in your
origin repository, and now you can go create the pull request from
my-feature to the
master branch in
From what you tell, the problem seems to be that you
git pulled your branch - creating that merge commit - instead of using
git rebase. That way, git would automatically tried to
cherry-pick your commit on top of the target branch (say,
upstream/master), and there wouldn't have appeared any merge commit.
Anyway, never forget that git rebase is dangerous, and you shouldn't use it if you don't fully understand it. You'd better learn more about it first, and then start guessing when and how it would be nice to use it.
If it has to be just one thing, don't ever forget the rule of thumb: never rebase public commits.