GitHub’s Got A New Desktop Client. Should We Care?
The dev world responded with a collective “yeah, whatevs” shrug and went back to pushing command line code.
I confess that I, too, was a shrugger. I do not know a single developer who uses the GitHub desktop, old or new. But after my initial knee-jerk dismissal of last Tuesday’s announcement, it occurred to me to think for a moment of the developers who worked to build this app. Sure, it was some developers somewhere who labored to bring us utterly useless apps like Man Poke and Human To Cat Translator. But this is GitHub! Surely its in-house development team must know a thing or two about making an app that could make our work lives better, or easier, or … something.
So I decided to take a look for myself: download GitHub Desktop 1.0 and see what it does. I am not a total n00b to this, since the first time I ever played around with GitHub I basically got played by GitHub in return — the website pretty much steamrolls first-time users into downloading the client. (Which I dutifully did, only in those days it was the original Mac-flavored native desktop app). It lingered for a day or two on my hard drive, but even über beginner me liked bash better and I’ve never looked back.
Producing a tool for programmers without Linux support, srsly?
There has been the usual hackerchat hatin’ that accompanies anything new, and the word on Desktop 1.0 was that it is slow, bloated, and gobbles RAM like my kid gobbles Pop Tarts. So, going in, I was on guard. But, once hands-on with it, found myself pleasantly surprised. It was a neat little Git client, compact and reasonably swift to start. The usage did quickly climb to 120MB, but then stabilized. This seemed a tad excessive, but then Slack — also an Electron app — consumes over 500MB on my machine. And, unlike Slack, when idling in the background the GitHub Desktop 1.0 uses almost zero percent CPU.
I won’t waste your time, or mine, with play-by-play description of the UX. You can try it for yourself, and you’ll like it or you won’t. Or maybe, like me, you’ll like the desktop app well enough but fail to see how it fits into your own personal workflow.
There are a couple handy features that I do like, though. Foremost being the ability to view pull requests as they get merged into the repository, a process that the desktop client streamlines over the usual GitHub browser interface. Also, I like that I can one-click clone repos directly from the browser, with the desktop client politely opening when I do so. Visual inspection of diffs appears greatly improved in the Desktop 1.0, too. And speaking of desktops, I’m hoping there is a utility in there that generates desktop notifications when issues are created, code is pushed, etc. — how cool would that be? — but if there is one it’s not obvious, at least to me upon initial inspection, and I haven’t yet taken time to dig for it.
One thing that puzzled me right away, though: given that Desktop 1.0 has been in beta release since May, and this is finally the Official Release, I was surprised to find that there is no Linux version of the application. Producing a tool for programmers without Linux support, srsly? The open source community jumped in, because yay awesomeness, and there is now at least one working Linux version of the Desktop app, this one housed in a fork created by Jiawen Geng.
I can see reasons why GitHub didn’t commit resources to building a Linux version of GitHub Desktop, at least as a first priority. (The company claims to be getting around to it eventually — a GitHub open issue thread on the topic has been officially tagged “future-work.” But: basically, the whole of GitHub is already built for programmers, and most of us get there on our own just fine. Maybe a new, even more user-friendly GitHub GUI is intended to make the glories of GitHub attainable for other people: designers, artists, and those brand new to coding of any kind. All of whom are unlikely to be working in a Linux shell.
So, What DOES Desktop 1.0 Do For Devs?
I decided to ask Phil Haack, director of engineering for client apps at GitHub, exactly that question.
“Even for git command line “junkies,” we think there are features that complement the workflow of experienced developers,” Haack told me. He himself is a daily Desktop 1.0 user, and offered some of his own experience with the app by way of example:
“Often, I’ll be working in my editor and in my shell, writing code, running commands to install packages, etc. Then, at some point, I have some unrelated work I need to commit. Ideally, my commit history should tell a story of the changes we’ve made. Each commit should represent a logical grouping of related work – the same way a method in code should do one thing.
Git has the notion of partial commits. If a file has 10 changes, you may want to commit five of those changes into one commit and the other five in another. Alternatively, you might want to aggregate changes from multiple files into a commit. Doing that on the command line is a bit tricky and it’s hard to visualize all the changes.
GitHub Desktop excels at this. From the Changes setting, developers can see all the changes in their working directory. They can check files to include, and uncheck files to exclude from the commit. Moreover, they can select specific changes by clicking in the gutter to include or exclude specific chunks of changed code. It’s very powerful!
What’s great is that if I’m a power user, I might be in the shell. To reduce the friction of going from shell to creating a commit, you can run the ‘github .’ command. The ‘.’ represents the current directory. It could be a full path to a repository. GitHub Desktop will launch and switch focus to the current directory so developers can quickly create a commit and get on their way.”
Another Reason We Should Maybe Care about Desktop 1.0
Developers don’t work alone. Yes, we are ultimately in charge of building the software, but the development process includes all kinds of helping hands. And not all of them belong to techies. For example: as annoying as the marketing department folks might be, they are trying to do their job of actually selling what we build. And the designers take care of that right-brained creative stuff. So — hear me out here — maybe another reason to care about GitHub Desktop is because it’s a way to help them do their jobs better by making available the essential functionalities of git via the creature comforts of a friendly GUI. Case in point: one of the new features in 1.0 is image diffs — perfect for graphic design versioning.
Point being, if GitHub Desktop is really able to make Git-For-Everybody at least a partial reality, then the app does end up making developers’ lives easier — just not in the way you’d first think. It’s true that we would likely have to invest some hands-on time up front showing various non-techie team members how to actually use it. (Pro tip: break the ice by showing them how to use the emojis feature!).
But: just envision the beautiful potential payoff of a world where instead of calling yet another meeting, we can start to handle at least some changes and versioning via desktop. We’ll always have the CLI. But maybe it’s time to look for a middle ground where we can meet the other members of the team. GitHub Desktop 1.0 might be one place to plant that flag.