[TASK] Add rebasing guidelines to CONTRIBUTING.md

CONTRIBUTING.md

@@ -124,3 +124,73 @@ what a commit is about.
 
 When you create a pull request, please
 [make your PR editable](https://github.com/blog/2247-improving-collaboration-with-forks).
+
+## Rebasing
+
+If other PRs have been merged during the time between your initial PR creation
+and final approval, it may be required that you rebase your changes against the
+latest `main` branch.
+
+There are potential pitfalls here if you follow the suggestions from `git`,
+which could leave your branch in an unrecoverable mess,
+and you having to start over with a new branch and new PR.
+
+The procedure below is tried and tested, and will help you avoid frustration.
+
+To rebase a feature branch to the latest `main`:
+
+1. Make sure that your local copy of the repository has the most up-to-date
+   revisions of `main` (this is important, otherwise you may end up rebasing to
+   an older base point):
+   ```bash
+   git switch main
+   git pull
+   ```
+1. Switch to the (feature) branch to be rebased and make sure your copy is up to
+   date:
+   ```bash
+   git switch feature/something-cool
+   git pull
+   ```
+1. Consider taking a copy of the folder tree at this stage; this may help when
+   resolving conflicts in the next step.
+1. Begin the rebasing process
+   ```bash
+   git rebase main
+   ```
+1. Resolve the conflicts in the reported files.  (This will typically require
+   reversing the order of the new entries in `CHANGELOG.md`.)  You may use a
+   folder `diff` against the copy taken at step 3 to assist, but bear in mind
+   that at this stage `git` is partway through rebasing, so some files will have
+   been merged and include the latest changes from `main`, whilst others might
+   not. In any case, you should ignore changes to files not reported as having
+   conflicts.
+
+   If there were no conflicts, skip this and the next step.
+1. Mark the conflicting files as resolved and continue the rebase
+   ```bash
+   git add .
+   git rebase --continue
+   ```
+   (You can alternatively use more specific wildcards or specify individual
+   files with a full relative path.)
+
+   If there were no conflicts reported in the previous step, skip this step.
+
+   If there are more conflicts to resolve, repeat the previous step then this
+   step again.
+1. Force-push the rebased (feature) branch to the remote repository
+   ```bash
+   git push --force
+   ```
+   The `--force` option is important. Without it, you'll get an error with a
+   hint suggesting a `git pull` is required:
+   ```
+   hint: Updates were rejected because the tip of your current branch is behind
+   hint: its remote counterpart. Integrate the remote changes (e.g.
+   hint: 'git pull ...') before pushing again.
+   hint: See the 'Note about fast-forwards' in 'git push --help' for details.
+   ```
+   ***DO NOT*** follow the hint and execute `git pull`. This will result in the
+   set of all commits on the feature branch being duplicated, and the "patching
+   base" not being moved at all.