A common workflow in Git is to use feature branches, where work is focused on one specific task. If you didn’t closely follow all commits in a particular feature branch, it is likely faster to review all changes to that branch in one go. It is also good practice to review a finished feature in its feature branch before merging it back to the main line. Or even check all changes of a release before publishing it, as David Smith recently described on his blog.
“Before I publish any build publicly (be that TestFlight or App Store) I always send the commit diff from the previous version to Kaleidoscope. Because I’m a one-man team, I don’t have anyone else reviewing my code as I go. What I have found, however, is that by taking the code changes outside of my normal working environment and into Kaleidoscope I can often find errors and issues before they get published. There is some switch that flips in my brain when I’m doing these reviews where I can pretend to be someone else being critical of the updates, which I find I can’t easily do when I’m in my main git client (Tower).”
David Smith in his blog article “Indispensable Tools“
This is where the Changeset functionality in Kaleidoscope comes in handy. It provides you with a list with all the file that have been changed. You can filter that list down, for example using a set of file extensions, to only source code to review while ignoring other assets. Keyboard shortcuts enable you to quickly jump between files and from change to change. And of course all Kaleidoscope for text files and images is available for each file, so you can toggle the view more or quickly search within text, just to name two examples
If the list is too long, you can filter it by file name, file extension and kind.
How to open a Changeset in Kaleidoscope
Opening a Changeset in Kaleidoscope needs to be triggered from your git environment. Git needs to tell Kaleidoscope what to compare. Below you’ll find an example for command line use and a short clip where we use Tower. Comparing branches should be possible in most git clients.
Command Line Use
The examples below assume that you have a branch called main that serves for ongoing development. In some environments, this may also be called develop or master.
To compare the changes made in a feature branch against the main branch when you are currently on the main branch, run:
git difftool ...branch-nameAnd when you are on the feature branch:
git difftool main...In git speak this is called a three-dot git diff, where you can specify a branch name, tag, or hash before and after three dots.
git difftool takes the same arguments as git diff, see the man page for more information.
Tower – Comparing branches
Select the two branches from the sidebar by ⌘-clicking two entries. Bring up the contextual menu and select Compare <entry> with <entry2>….
Note: For this to work, Kaleidoscope needs to be set as the default tool for git difftool. Head to the menu Kaleidoscope > Integration… > Git to set this up via a single button click.
Learn more
In a previous blog post about the Tower Git client, we show various ways you can use to start a code comparison in Kaleidoscope from Tower.
