docs: improve Branches and Commits Methodology (#7706)

Co-authored-by: Rhys Arkins <rhys@arkins.net>

docs/development/branches-commits.md

@@ -2,16 +2,20 @@
 
 ## Multiple files per branch
 
-Renovate can/should update multiple files in the same branch/PR.
-e.g. it might be `package.json` and `yarn.lock`, or it might be multiple `package.json` files in a monorepo.
+Renovate can, and should, update multiple files in the same branch/PR.
+
+e.g. Renovate can update the `package.json` and the corresponding `yarn.lock` file in the same commit.
+The bot can also update multiple package files at once in a monorepo, including from different package managers.
 
 ## One commit per branch
 
-To keep things neat from a user perspective, and simplify things from Renovate's perspective, we aim to always use just one commit per branch, even when multiple files need updating.
+To keep things neat: Renovate always makes one commit per branch, even when multiple files need updating.
+This way we can use the following logic:
 
-A positive side effect of this is that it allows us to have a shortcut rule of, "If there's only one commit in the branch then it's clean, otherwise it must have been edited by users and we should stop updating it".
+- If the last commit in a branch was using Renovate's identity, we assume it to be clean.
+- If the last commit in a branch is by an identity other than Renovate's, the branch is assumed to have been edited by users and Renovate will not push to it any longer.
 
 ## Updating branches
 
-If files in an already-existing branch need updating (e.g. an even newer version has been released), then we still aim to have just one commit.
-We achieve this by force pushing with `git` to the existing branch.
+If files in an already-existing branch need updating (e.g. an even newer version has been released), then we still want to have only one commit.
+Renovate achieves this by force pushing the necessary changes to the existing branch with `git`.