For example, I have a branch DEV and a branch STABLE.
In case I have cherry-picked several commit from DEV to STABLE.
Is there any way to let GIT aware of the cherry-picked commits, and avoid doubly-merging it if I later merge, rebase or cherry-pick an overlapped range, from DEV back to STABLE? (for which is a basic merge tracking feature in SVN)
git cherry-pick is a funny case of git rebase rather than git merge, so it actually rewrites the commit you cherry-picked so it will apply the same changes to the top of the branch you cherry-picked into. Since git's commit ids are based on the content of the commit, the new commit has a different id and is therefore considered an entirely different commit by git.
git merge, on the other hand, creates a merge commit; this is the means by which git implements merge tracking. A merge commit marks a point at which two (or more) divergent histories converged. It's acceptable to call git merge [commit-id] instead of git cherry-pick [commit-id] to explicitly create a merge commit, but this brings in not only the effects of the single cherry-picked commit but also the entire set of changes in that branch's divergent history.
With all that said, "double-merging" is not usually a problem in git. If you try to merge with a history that contains a changeset that's already present it'll just become a no-op when the histories are glued together; git really cares only about the state of the tree in each commit, not about the changes that got it into that state.