Commit reviewing best practices

In an ideal world I would like to always have a colleugue review the changes I make in a commit. However, in the change history you can only see which microflows have been changed, but it is not possible to see what has changed. Is there a way to easily see old and new values in the modeler just as I am used to seeing in Github. I was wondering how other people implement reviewing of each others commits. Please let me know in an answer. Currently we add a comment in sprintr in which we briefly explain what has changed and how to test it. Then we label the story as ready for testing. Before a story is put to done another person will have at least done the tests as specified in the comment.
1 answers

For the cloud portal we would always create a new branch, implement feature there and then ask a colleague to manually merge it back to the main line. This allows the reviewer to see exactly what the branch is changing.

It can be a tad tedious for large merges, though. I've found myself applying parts of the branch, reviewing, committing and then pulling in more changes just so that I could see what was happening.