All changes from both branches will appear in the history:
A-B------C----M--...
\-X-Y---Z-/
where X
, Y
and Z
are your commits and C
is the commit you're missing. The commit M
is a merge-commit that will contain all your changes in it (and potentially fixes any merge conflicts with C
). Your commits will remain untouched and afterwards M
will contain all changes from C
, X
, Y
and Z
.
Alternatively, the repo maintainer can rebase your branch and merge it afterwards:
A-B-C---------M--...
\-X-Y-Z-/
when everything goes right, the state of M will be exactly the same as when doing the regular merge. However X
, Y
and Z
will individually be made to look like they originated from C
(their SHA1 value will change, too).
Both methods are equally valid, rebasing is recommended if there is quite a number of commits that you're missing (i.e. after a few weeks of developing).
Be aware: The repo maintainer may ask you to do the merge or rebase if your branch does not merge cleanly and the conflict isn't easy to fix. It is your job to supply mergeable branches.
In this case, just fetch the latest version of the branch you're pull-requesting against and try the merge yourself:
git checkout your-branch
git pull upstream master
or
git checkout your-branch
git pull --rebase upstream master
Afterwards, the branch will merge cleanly into upstream. Just post a new pull-request for your newly merged branch.