Git – Which commit should close a Github issue when multiple commits are responsible

No they shouldn't, if avoidable. It's a problem that in my experience happens far too often. However I believe it is more to do with ignorance of how to use git correctly than somebody wanting to steal credit.

• If they want to modify your change before applying it to their main branch, they can easily create a branch for your change. They can then add their own commit after yours and then merge the branch in.
• If your pull request is not based on the latest version of their main branch, then they can issue a git rebase master. If there are conflicts they can either choose to fix the conflicts themselves (without changing author), or give you the chance to fix it.

I think Github could and should look for this kind of accidental credit stealing and educate maintainers on best practices when appropriate.

git-merge mechanism:
Using git merge feature while on master merges the branch feature to master and produces a merge-commit (if the branch cannot be fast-forwarded) in the git history. To force a merge-commit being made, use the --no-ff option with merge.

Merge Pull Request mechanism:
When we start a Pull Request on GitHub, it creates a GitHub Issue where people can talk and discuss the commits in the PR before merging it. When a PR is merged on GitHub it does the exact same thing as git merge feature.

What should I do?
So, as far as history is concerned, there is no difference between the two.
And as far as contribution goes, your contributors will not have to do anything different for the two situations. They are the same (minus the nice little chat).

Best Practices:
And I was unable to find a best practices but logic says that PRs are not much helpful if there is only a single contributor to a repository.

@lxrec and @amon helped me reach this conclusion.