After months of blood, sweat and tears from us on the FishEye team, today we’re releasing the Commit Graph. I’m proud of what we’ve achieved: now developers can use FishEye to visualize their repository to see the bigger picture about how their changes interact with everyone else’s. It’s worth experimenting for yourself, but the graph has made us more productive already. I thought I would share with you some of the ways we’ve already started using it on the FishEye team.
We’ve got a few requirements for commits before they get into a release. One of them is that your code needs to be reviewed. The Commit Graph rocks at showing you which commits are ready, and which aren’t. Using the Reviewed changesets highlighter, we can see which commits are ready for merging (Green dots mean the review is complete), and which ones aren’t (Red dots mean no review, and Yellow ones mean there is a review in progress).
My Team Lead, Seb, uses it for another purpose. I’m not very good at ensuring my latest changes are in review. I usually stop by Crucible every other day and move all my commits into review at once. Unfortunately, that’s not always fast enough. He uses the review highlighter to see how far behind I am and annoy me into getting my code reviewed. It works well.
When you merge a commit, you’re merging every commit that commit ever merged with.
Knowing that a particular commit is reviewed isn’t enough. Their ancestry could include some ugly code that you don’t want in the release. Probably the most useful part of the Commit Graph for me is the Lineage highlighter. I can click on a branch head and immediately see what changes have yet to be merged in. Or I can click a commit-to-be-merged and see which commits it’s related to, and then make sure those are also reviewed and ready.
Dealing with issues.
My commits are a means to an end. And most of the time, the end is a JIRA. When cleaning up my JIRA issues and getting them into a good state, I often use the JIRA issues highlighter (only available if you have a UAL-connected JIRA instance) to see if my commits have been merged in yet. That way I can be sure I’m only closing issues once they’re guaranteed to be in the release. If I didn’t do this, I’d end up forgetting about my unmerged commits until the release is already out the door.
Sharing is caring
The permalink icon in the top right of the graph lets you share your current view of the graph, including the branches you are currently viewing. Yes, the URL can be quite long and I didn’t think it would be that important at first, but we’ve made good use of it here. Whenever our release manager puts up a new version of our dogfood instance, he links to the Commit Graph showing all the feature branches that made it into that version. It’s a very nice way to see what has changed (unless you’re nick).
The graph is great, but it’s usually not the end of my workflow. I’ve gotten a lot of use out of the ID and branch name that appear in the changeset hover and in the cog menu. A Ctrl/Cmd+C makes for a quick and easy paste into an hg update or hg merge (also good for svn switch or svn merge…or whatever SCM command you want to run). This is great when I’m looking for a changeset in the graph and am ready to merge it into the mainline or make more commits off of it.