You are correct in the narrative of employing git rebase -i
. (And you were also likely to have run git rebase -i 2535dca^
, otherwise that commit would not have been in the rebase listing.)
One thing that you can do is to reorder and squash separately to simplify the flow – run two rebases, but fundamentally there isn’t much you can do except following the instructions and resolving all the merge failures every time rebase fails, whether running one or two rebases.
Apart from rebasing everything you may find the following flow slightly more explicit, and thus more intuitive for your specific case. (It is almost identical to what rebase is doing behind the scene.) You can work on a temporary branch where you will explicitly cherry pick the changes in the wanted order and squash as necessary:
$ git checkout -b tmp-topic 2535dca
$ git cherry-pick 738ae0a 21f05f9
... will most likely have to resolve conflicts for each cherry-picked change
$ git rebase -i 2535dca
… squash the two commits you just cherry-picked
$ git cherry-pick 288ffd2 0534049
... will most likely have to resolve conflicts for each cherry-picked change
Now you have your original branch topic and the new tmp-topic branch, where the order is just right, but topic is the one that should be pointing to the new graph of commits you’ve just finished working on:
$ git update-ref refs/heads/topic tmp-topic