If I cherry-pick a commit from a branch and then merge the whole branch later what happens to the git history?
The git merge operation does not look at the individual commits along the "merge path", as it were. Instead, it looks only at the start and end snapshots. Note, however, that there are two end snapshots (and one start):
...--o--B--o--...--o--L
\
o--...--o--R
Here, B is the merge base commit and L and R are the left (or local or --ours) and right (or other, remote, or --theirs) commits respectively. Meanwhile each round o represents some commit that Git does not even look at.1 Git simply does, in effect:
git diff --find-renames B L # figure out what we did
git diff --find-renames B R # figure out what they did
What this means for your git cherry-pick is that "what we did" and "what they did" are likely to include some of the same changes to the same files—but that's no problem, because the step that git merge does after obtaining these two en-masse diffs is to combine the changes, taking exactly one copy of any change that appears in both the left and right "sides" of the merge.
Suppose, however, that you cherry-pick a commit and then revert it again along one path, e.g.:
...--o--B--X'--!X'--L
\
X--o--R
(The reason X' has the tick mark is that it's a copy of commit X: when you cherry-pick a commit, the new copy gets a different hash ID.)
Here, you wrote commit X in for the branch (the lower line in the graph), cherry-picked it into the main line (the upper line), realized it was not ready or was broken, reverted it (adding !X'), and then made the final commit L in the main line. Now when you merge, the fact that a copy of X went in, then went out again, is invisible: Git compares B vs L and sees no sign at all of the X'--!X' sequence. It therefore still takes one copy of the changes introduced by commit X.
If commit X has become ready on the branch ending in R, this is the correct action.
If commit X is still broken, this is the wrong action—but the proper cure is probably to revert X on the branch before merging.
1Except for finding B, that is: Git must start at both L and R and work backwards through the graph to find the merge base. This means Git must traverse some of the otherwise-uninteresting commit nodes.