If you have it installed via git (not with the -b option when first installed), why 'hyperjump'? .... like 3.1 to 3.5 ....
One of the things you should do prior to beginning the 'march' is plugin compatibility with destination version ... and the 'marched steps'. A plugin not compat can and has stopped even a git pull/upgrade cold - until resolved.
Then there are the changes to the DB ... InnoDB, Barracuda, character set and collation changes from utf8 to utf8mb4.
During the march one might need to change config of MySQL (assuming MySQL) and restart the service.
When you do the first .... 3.1 -> 3.2 stop/check ... go to environment and update component, then use the pick list for the next or future versions. See anything that needs fixing? Fix!
During the march one might decide to upgrade the PHP ... but you can't do that too soon.
As far as versions no longer being supported ... you mentioned 3.2.x ... no biggy ... you are not going to be at that version very long to worry about it.
Might take a little longer but 3.1 -> 3.2 -> 3.3 -> 3.4 -> 3.5 march when using git and NOT having issues with themes nor plugins .... taking backups at each stop in the march .... really doesn't take very long .... and you get to test a representative course in your site at every stage of the march.
One thing about a march .... you are practicing and after 4 of those setps you should be better informed about your own server .... no way around that.
After the git stuff to acquire the new code, why not finish the install via command line? There is an upgrade.php script in moodlecode/admin/cli/ that does what a browser would do .... even better ... takes apache out of the loop ... just php and the DB server then.
Am sure others have different ideas ... preferences, really.
My 2 'sense' ...
'spirit of sharing', Ken