1. Click the fetch icon. New work to review shows up.
2. Right click to compare the branches, take a look through the diffs.
3. If I see something I want to check, click "Checkout" in the branch selector and start making the changes, commit, push.
4. Otherwise when done, use git merge and delete the origin branch (I have some shell functions for this).
One thing I've found hard to settle on is what message to use in the merge commits. I don't insist all changes have tickets because it'd just be redundant work for the case of small cleanups, fixing bugs you spotted whilst doing other stuff. But then the default merge commit message isn't terribly helpful, and writing one that is can end up redundant.
Another problem is that the railway lines can get quite hairy if people aren't disciplined about constantly rebasing. You can of course rebase for them, but then you lose the ability to view only the merge commits to master.
We use a kernel model in which there is no shared repository, so it's impossible for branches to be merged without being reviewed because it's the reviewer who merges them when they're satisfied.
I guess you can do a similar thing with issues just by having a folder of markdown files for each issue and appending comments to them.
If some conventions could be agreed you could have GUI support.