GitHub Desktop 2.0: Stashing, Rebasing, Co-Authors, and Improved Workflow Support

This article is based on a summary originally published on itbrief.co.nz, drawing from GitHub’s official announcement by Billy Griffin on the GitHub blog.

GitHub Desktop 2.0: What Changed and Why It Matters

GitHub Desktop 2.0 marked a significant step forward for developers who prefer a graphical interface over the command line. The release focused on two highly requested Git operations — stashing and rebasing — while also adding co-author attribution, emoji support in commit messages, and tighter pull request integration with GitHub.com.

According to GitHub’s Billy Griffin, the update was driven directly by user feedback: “We’re focused on listening to our users and supporting the workflows you need to be most successful when building software. Whether you’re a seasoned developer or brand new to concepts like version control, GitHub Desktop puts the things you need most front and centre.”

Stashing: Save Work-in-Progress Without Committing

One of the most common friction points in a Git-based workflow is needing to switch branches before your current changes are ready to commit. Previously, this often meant either making a premature commit or discarding changes temporarily — neither of which is ideal.

GitHub Desktop 2.0 surfaces Git’s stash functionality through a user-friendly interface. When switching branches with uncommitted work, developers are now prompted to either:

• Bring the changes to the new branch — useful when the work is relevant to the branch you’re switching to.
• Leave the changes on the current branch — stashing them so you can return later without losing progress.

As Griffin explains: “It’s a common situation: you’re in the middle of reproducing and fixing a bug, and you need to switch context temporarily… In Desktop 2.0, if you’re not ready to commit your work, you can choose to bring your changes to the new branch or keep them on your current branch.”

For teams practicing trunk-based development or juggling multiple feature branches, this reduces interruption and makes context-switching significantly less disruptive.

Rebasing: Keep Commit History Clean

Many teams enforce a linear commit history to make git log and code review easier to follow. Before Desktop 2.0, developers who wanted to rebase rather than merge had to drop to the command line — a barrier for less experienced contributors.

Desktop 2.0 adds native rebase support, giving teams the choice of how to integrate branches without leaving the application. Griffin notes:

“Developers have also shared that many teams prefer a clean commit history without merge commits… If you’re used to merging branches normally, you can still continue using the same workflow. But if you work in a repository where you don’t want those merge commits, Desktop 2.0 now supports rebasing to help you keep that commit history clean.”

Importantly, the merge workflow remains available — this is an opt-in capability, not a replacement. Teams can standardise on whichever strategy suits their project without forcing individuals to the CLI.

Co-Author Attribution: Giving Credit Where It’s Due

Pair programming and mob programming sessions often result in commits that represent the work of multiple people, but only the person who pushes gets credited. GitHub Desktop 2.0 addresses this by allowing developers to tag co-authors directly in the commit UI.

To add a co-author, you mention their GitHub username in the commit dialog. GitHub then resolves the attribution and includes it in the commit metadata, ensuring contribution graphs and pull request history accurately reflect everyone involved. This is especially valuable for teams that track individual contributions for performance reviews or open-source recognition.

Emoji Support in Commit Messages

GitHub Desktop 2.0 also added support for emoji in commit messages — a small but popular quality-of-life improvement. Projects that follow conventions like Gitmoji use emoji prefixes to communicate the nature of a change at a glance (e.g., 🐛 for bug fixes, ✨ for new features). Desktop 2.0 makes composing these messages easier without copy-pasting from external sources.

Pull Request Integration: Bridging GitHub.com and Your Local Machine

A key theme of Desktop 2.0 is reducing the number of times a developer needs to switch between the desktop application and the browser. The release introduced tighter pull request integration:

• Open any pull request from GitHub.com directly in Desktop — the branch is checked out locally and ready for review or testing without manual setup.
• Suggested next steps after a commit — once a commit is complete, the application surfaces contextual actions, such as creating a pull request, reducing the cognitive overhead of remembering what to do next.
• Easier pull request creation — the workflow from local branch to pull request is now more streamlined, reducing the number of manual steps required.

Griffin described the direction: “Looking forward, you can expect to see more in GitHub Desktop that surfaces context from GitHub.com to help make you even more productive on your local machine.”

The Broader Goal: Lowering the Barrier to Entry

GitHub Desktop 2.0 reflects GitHub’s stated goal of making professional-grade version control workflows accessible to developers at all skill levels. Features like stashing and rebasing have long been available via the Git CLI, but their complexity makes them intimidating for newcomers. By surfacing these capabilities with clear UI prompts and descriptive language, GitHub Desktop 2.0 helps teams standardise workflows without requiring every team member to have deep Git expertise.

For DevOps teams onboarding junior developers or contributors from non-engineering backgrounds, this kind of tooling can meaningfully reduce training overhead and improve consistency in how code changes are managed.

Summary of GitHub Desktop 2.0 Features

GitHub Desktop is a free, open-source application available for macOS and Windows. The source code is available on GitHub.