Take a break from the command line with GitHub Desktop

Wedded to Git version control and the GitHub cloud service? Learn how to take advantage of the newest member of the team

Take a break from the command line with GitHub Desktop
flickr/Ben Scholzen

Git has become the lingua franca of code. From its birth of scratching Linus Torvalds’ version-control itch, it has grown to become the repository of choice. Git’s cloud incarnation, GitHub, has become the public face of source control -- where recruiters look at candidates’ code and commits and where much of the world’s open source software is developed and shared.

GitHub Desktop is intended to simplify working with the service, bringing common GitFlow techniques to your desktop while still giving you an offline copy of your repositories so that you can work anywhere. With both Mac and Windows versions, built using a common core, it’s an important tool. It handles synchronizing your code with the cloud, managing branches, and showing changes -- so you can work in your usual code editors without having to worry about whether it has integration plug-ins.

Acquiring GitHub Desktop is quick and easy, with the installer downloading the latest version as part of the install process. Once installed it walks you through a quick tutorial showing you how to branch a repository, commit changes, then handle pull requests and merges. The tutorial is built into the app and can be hidden at any time.

At the heart of the tool is a graphical view of a repository, showing the branches and differences, that helps you navigate through your and your collaborators' changes. Looking rather like a public transport map, it gives you a view of your current branch and the commits you’ve made. A drop-down menu lets you pick a branch, with the graph showing the commits since you last branched off. As the client is connected to the cloud service, it keeps up to date with changes in all the branches, showing where pull requests have been made and where commits in the master branch haven’t yet been merged into your current branch.

Commits and pull requests are handled just like you're used to with GitHub, with file system integration so that you can use your choice of editors and development tools. Or you could simply use GitHub Desktop to monitor the Git tooling built into your IDE.

It’s interesting to understand how GitHub built a cross-platform application like this. To learn more, I spoke to GitHub’s Amy Palamountain, part of the company’s Desktop Engineering team.

The move to a new client was initially driven by a change in application strategy and a need to consolidate code. “We originally had two different teams, making two different Git clients,” Palamountain told me. With a focus on Git as a protocol, rather than GitHub as a service, it meant that key use cases weren’t being addressed, especially around collaboration. “What our users need is a way to collaborate on GitHub, so we focused on that as a single team, working on parity between clients.”

A single team working on a cross-platform application makes a lot of sense, as it allows ideas to be shared and lets the team focus on key cross-platform elements. In this first release that’s been a focus on developing tooling to make it easier to see changes in your code. As Palamountain says, “Then we started to share a piece of code that we called the comparison graph, which sits at the very top of the app and lets you navigate between your current branch and the master branch, viewing commits and navigating through your history and performing merges.”

The Windows and Mac versions may look similar, but they’re still native platforms under the hood sharing one common piece of code at the moment. Future versions will share more, building on this first release.

Building the comparison graph was one of the first tasks handled by the new joint team, focusing on the user experience that GitHub wanted to expose. As Palamountain explained, “The comparison graph focuses on common workflows. We built a common prototype to test theories on user experience and the workflow.” The graph is written in HTML5 and JavaScript, then embedded in the application as a Web component, integrating with native code.

Getting the user experience right was important, and the joint team was able to work with a lot of people with a lot of design experience. One key person was GitHub’s product designer, Steve Smith, who, Palamountain says, “We were able to bounce off ideas and lean on him for expertise.” The team also ran a beta program to get users interested in the new tooling. More than 35,000 signed up, and about a quarter of them ended up running the program. The beta was used to gather feedback, and the team made changes to the designs as a result. “We could see the different ways people are using the software,” Palamountain noted.

Using Web components meant the team was able to quickly port to both platforms using its own Web framework. As Palamountain notes, GitHub used its own framework. “Surprisingly, the code for the comparison graph didn’t need complex frameworks.”

Being able to control the endpoint also helped a lot, Palamountain says. “The other reason we do this is that tools like jQuery support a lot of browser technologies, and here we are completely in control of the browser technologies. On Mac it’s WebKit, on Windows it’s Chromium. We don’t have to work around cross-browser technology -- it’s quite freeing.” It also means there’s a much lower code overhead and a smaller download.

Copyright © 2015 IDG Communications, Inc.

How to choose a low-code development platform