Clarify guidance around "Squash and Merge" (dotnet#20937)

* Clarify guidance around "Squash and Merge"

Fixes Issue https://github.com/dotnet/corefx/issues/20841

* PR feedback.

* PR feedback.

Author: atsushikan

Documentation/project-docs/contributing.md

@@ -26,6 +26,19 @@ Pull Requests
 * **DO** refer to any relevant issues, and include [keywords](https://help.github.com/articles/closing-issues-via-commit-messages/) that automatically close issues when the PR is merged.
 * **DO** tag any users that should know about and/or review the change.
 * **DO** ensure each commit successfully builds.  The entire PR must pass all tests in the Continuous Integration (CI) system before it'll be merged.
-* **DO** address PR feedback in an additional commit(s) rather than ammending the existing commits, and only rebase/squash them when necessary.  This makes it easier for reviewers to track changes. If necessary, squashing should be handled by the merger using the ["squash and merge"](https://github.com/blog/2141-squash-your-commits) feature, and should only be done by the contributor upon request.
+* **DO** address PR feedback in an additional commit(s) rather than amending the existing commits, and only rebase/squash them when necessary.  This makes it easier for reviewers to track changes.
+* **DO** assume that ["Squash and Merge"](https://github.com/blog/2141-squash-your-commits) will be used to merge your commit unless you request otherwise in the PR.
 * **DO NOT** fix merge conflicts using a merge commit. Prefer `git rebase`.
 * **DO NOT** mix independent, unrelated changes in one PR. Separate real product/test code changes from larger code formatting/dead code removal changes. Separate unrelated fixes into separate PRs, especially if they are in different assemblies.
+
+Merging Pull Requests (for contributors with write access)
+----------------------------------------------------------
+
+* **DO** use ["Squash and Merge"](https://github.com/blog/2141-squash-your-commits) by default for individual contributions unless requested by the PR author.
+  Do so, even if the PR contains only one commit. It creates a simpler history than "Create a Merge Commit".
+  Reasons that PR authors may request "Merge and Commit" may include (but are not limited to):
+
+  - The change is easier to understand as a series of focused commits. Each commit in the series must be buildable so as not to break `git bisect`.
+  - Contributor is using an e-mail address other than the primary GitHub address and wants that preserved in the history. Contributor must be willing to squash
+    the commits manually before acceptance.
+