How does git merge after cherry-pick work?

Short answer

Don't worry, Git will handle it.

Long answer

Unlike e.g. SVN1, Git does not store commits in delta format, but is snapshot-based2,3. While SVN would naively try to apply each merged commit as a patch (and fail, for the exact reason you described), Git is generally able to handle this scenario.

When merging, Git will try to combine the snapshots of both HEAD commits into a new snapshot. If a portion of code or a file is identical in both snapshots (i.e. because a commit was already cherry-picked), Git won't touch it.

Sources

¹ Skip-Deltas in Subversion
² Git Basics
³ The Git object model

After such merge you may have cherry-picked commits in history twice.

Solution to prevent this I quote from article which recommends for branches with duplicate(cherry-picked) commits use rebase before merge:

git merge after git cherry-pick: avoiding duplicate commits Imagine we have the master branch and a branch b: o---X <-- master \ b1---b2---b3---b4 <-- b Now we urgently need the commits b1 and b3 in master, but not the remaining commits in b. So what we do is checkout the master branch and cherry-pick commits b1 and b3: $ git checkout master $ git cherry-pick "b1's SHA" $ git cherry-pick "b3's SHA" The result would be: o---X---b1'---b3' <-- master \ b1---b2---b3---b4 <-- b Let’s say we do another commit on master and we get: o---X---b1'---b3'---Y <-- master \ b1---b2---b3---b4 <-- b If we would now merge branch b into master: $ git merge b We would get the following: o---X---b1'---b3'---Y--- M <-- master \ / b1----b2----b3----b4 <-- b That means the changes introduced by b1 and b3 would appear twice in the history. To avoid that we can rebase instead of merge: $ git rebase master b Which would yield: o---X---b1'---b3'---Y <-- master \ b2'---b4' <-- b Finally: $ git checkout master $ git merge b gives us: o---X---b1'---b3'---Y---b2'---b4' <-- master, b

EDIT Corrections supposed by David Lemon's comment