Update CONTRIBUTING.md

Adding to CONTRIBUTING.md guidance on how PRs should be handled by contributors and maintainers.

Author: dinkelk

CONTRIBUTING.md

@@ -8,11 +8,25 @@ While we encourage all contributions, remember that Adamant is used everyday to
 
 ## Creating a Submission
 
-Adamant follows the [GitHub flow](https://docs.github.com/en/get-started/quickstart/github-flow) development process. You should begin by [forking](https://docs.github.com/en/get-started/quickstart/fork-a-repo) this repository. When you have finished making changes on your fork, create a pull request back to this repository.
+Adamant follows the [GitHub flow](https://docs.github.com/en/get-started/quickstart/github-flow) development process. You should begin by [forking](https://docs.github.com/en/get-started/quickstart/fork-a-repo) this repository. When you have finished making changes on your fork, create a [pull request](https://github.com/lasp/adamant/pulls) back to this repository.
 
-Please try to keep submissions small and focused on single fixes, enhancements, or additions. This makes changes easier to review and faster to merge.
+### Pull Request
 
-Once a pull request has been submitted the following will occur:
+Please adhere to the following when submitting a pull request:
+
+- Pull requests should be made against `main`.
+- Keep submissions small and focused on single fixes, enhancements, or additions. This makes changes easier to review and faster to merge.
+- Include a summary of changes that gives reviewers an idea of what they should pay attention to.
+- Pull request branches should have as "clean" of a history as possible.
+    - Each commit should present one change or idea to a reviewer.
+    - Commits that merely "fix up" previous commits should be interactively rebased and squashed into their targets.
+- Prefer the use of `git rebase`.
+    1.  `git rebase` actually _rebases_ your branch from the current main branch's endpoint. This localizes conflicts to the commits at which they actually appear, though it can become complicated when there are more than a few conflicts.
+    2.  `git merge` pulls in all the updates that your branch does not have, and combines them with the updates you have made in a single merge commit. This allows you to deal with any and all conflicts at once, but information such as when conflicts originated is lost.
+
+    For more info on `git merge` vs `git rebase` see [here](https://www.atlassian.com/git/tutorials/merging-vs-rebasing).
+
+Once a pull request has been submitted, a maintainer will review your submission.
 
 ### Submission Review
 
@@ -28,6 +42,8 @@ Note that many of these checks are annoyingly pedantic, but this helps ensure un
 
 Once the pull request is passing all tests and checks and has been approved by a maintainer it will be merged into the Adamant repository!
 
+Pull requests should be merged by a maintainer using the "create a merge commit" strategy. In combination with the pull request recommendations above, this ensures that features are neatly bracketed by merge commits on either side, making a clear hierarchical separation between features added to main and the work that went into each feature.
+
 ## Contribution Ownership
 
 Contributions to Adamant will abide by the [GitHub Terms of Service](https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#6-contributions-under-repository-license) which states: