Update DEVELOPMENT.md: Git merge strategy

.github/DEVELOPMENT.md

@@ -26,22 +26,24 @@ A typical pull request should strive to contain a single logical change (but not
 necessarily a single commit). Unrelated changes should generally be extracted
 into their own PRs.
 
-If a pull request does consist of multiple commits, it is expected that every
-prefix of it is correct. That is, there might be preparatory commits at the 
-bottom of the stack that don't bring any value by themselves, but none of the
-commits should introduce an error that is fixed by some future commit. Every
-commit should build and pass all tests.
-
-Commit messages and history are also important, as they are used by other
-developers to keep track of the motivation behind changes. Keep logical diffs
-grouped together in separate commits, and order commits in a way that explains
-the progress of the changes. Rewriting and reordering commits may be a necessary
-part of the PR review process as the code changes. Mechanical changes (like
-refactoring and renaming)should be separated from logical and functional
-changes. E.g. deduplicating code or extracting helper methods should happen in a
-separate commit from the commit where new features or behavior is introduced.
-This makes reviewing the code much easier and reduces the chance of introducing
-unintended changes in behavior.
+If a pull request does consist of multiple commits, it is expected that
+every prefix of it is correct. That is, there might be preparatory
+commits at the bottom of the stack that don't bring any value by
+themselves, but none of the commits should introduce an error that is
+fixed by some future commit. Every commit should build and pass all
+tests.
+
+Commit messages and history are also important, as they are used by
+other developers to keep track of the motivation behind changes. Keep
+logical diffs grouped together in separate commits, and order commits
+in a way that explains the progress of the changes. Rewriting and
+reordering commits may be a necessary part of the PR review process as
+the code changes. Mechanical changes (like refactoring and
+renaming)should be separated from logical and functional changes. E.g.
+deduplicating code or extracting helper methods should happen in a
+separate commit from the commit where new features or behavior is
+introduced.  This makes reviewing the code much easier and reduces the
+chance of introducing unintended changes in behavior.
 
 ## Code Style