At step 18, I had to use the --force option when pushing. Otherwise I got non-fast-forward errors back not about master, but about my review branch and about an old obsolete branch.

Are you sure you checked out the master branched first? If you're pushing your review branch, you'll need the --force option. But if you're pushing master, you should never use the --force option. If you use --force when pushing master. It's also possible that someone pushed inbetween the fetch in step 15 and the push in step 18. In which case you'd need to repeat steps 15-18 again (e.g. fetch latest, rebase ontop of it, test, push).

If we're going to make this by the book, we should probably add a section on proper conflict resolution.

An important git practice: if you move a file (change package, or directory, or project...) you should commit without edits to that file.

This insures that git can find the file and determine that the file was moved from one place to another so that it can retain the history.

An additional detail is that one should not squash a commit with file moves into another commit, nor squash other commits into a commit with file moves.

Changes to other files than the one(s) moved can be co-resident with file moves. The point is just not to both move and edit a file in the same commit because of the potential for loss of change history (which can make rebase very hard.)

So roughly: commit, then move files around, then commit, then get back to edits/changes.