We’re rolling out two exciting new features in the latest GitHub Desktop Beta to make your workflow even smoother:
Multi-domain support: Do you work across multiple GitHub instances? You can now sign into more than one domain so you can focus more on your code and less on sign-in flows.
Filterable changes: Do you find yourself endlessly scrolling through a long list of changed files? Now, you can filter by filename to review your changes faster. This makes it easier to locate and select exactly what you need for your next commit!
GitHub Desktop now allows you to open your repositories with any editor or shell, even if it’s not on the list of supported integrations. Supercharge your integrations with advanced configurations including specifying command line arguments.
Accessibility Improvements
Fixed: The “Open a Pull Request” and “About” dialog’s headings are announced via NVDA – #19107
Fixed: The branch selection popover in the “Open a Pull Request” dialog does not close on filter clearing – #19106
Fixed: The contrast ratio of icon in the diff file warnings is at least 3:1 – #19097
Fixed: The “Push Local Changes” confirmation dialog uses “alertdialog” role such that screen readers announce entire dialog contents – #19098
Fixed: Emoji’s provide descriptions for screen readers – #19101
Fixed: Stop improper announcement of \”dialog\” role on the autocompletion suggestions popover – #19114
Improved: Screen readers announces when users expand context in a diff – #19128
Improved: The squash dialog provides visual input labels – #19100
Improved: The search inputs across the app provide visual labeling in the form of a search icon – #19103
Community Contributions
Added: The external editor Cursor is supported on macOS – #17462. Thanks @bjorntechCarl!
Added: The external editor JetBrains RustRover is supported – #18802. Thanks @Radd-Sma!
Enterprise accounts on GitHub.com, created after June 2, 2024, along with organizations owned by these accounts, have access to the enhanced billing platform. This includes enhanced billing for Git Large File Storage (LFS). Enterprises who participated in the beta program also have access to this platform. Other Enterprise accounts on GitHub.com, and Free, Pro, and Team accounts, will gain access to the enhanced billing platform in the coming months.
The enhanced billing platform transitions Git LFS from a pre-paid, quota-based model (data packs) to a post-paid, usage-based model (metered billing). This new platform offers better spending control and detailed visibility, allowing for a clearer understanding of your usage with more granular controls.
Additionally, GitHub is increasing the free, included amount of Git LFS resources for Enterprise accounts on the enhanced billing platform. They will now receive 250 GiB of storage and 250 GiB of download bandwidth per month at no cost. Beyond these amounts, storage for Git LFS files will cost $0.07 per GiB per month (USD), and download bandwidth will cost $0.0875 per GiB per month (USD).
GitHub Desktop 3.4 lets you reset back to a specific commit quickly with “Reset to Commit” and improves discoverability of key application controls.
Resetting to Commit
With Reset to Commit, it takes one click to set your local history back to your latest pushed commit, with all of the reverted changes landing back into your changes list. While similar to using the undo function, Reset to Commit allows for resetting more than one commit at a time. By adding a new way to modify your history, Reset to Commit fits right along side undoing, reverting, amending, squashing, reordering, and cherry-picking features.
Improved Accessibility: Diff Checkmarks and Underlined Links
GitHub and the Desktop team are committed to making GitHub Desktop a tool for all developers. With GitHub Desktop 3.4, links are underlined by default and checkmarks are used in the diff to indicate whether a line is selected to be committed. These changes are aimed to enhance discoverability, be keyboard-accessible, and be semantically marked up to enable interaction with assistive technologies.
For users who want to opt out of these changes, check out the new Accessibility settings pane to customize your experience.
Repository rules allow you to easily add scalable protections for branches and tags on your repositories. This feature was recently made generally available, and GitHub Desktop 3.3 now adds support for repository rules in the form of preemptive warnings and errors if your work fails a rule configured by an administrator of your repository. These rules can fail when commits are pushed to GitHub, which may not be ideal if you queue up multiple commits before pushing. Advanced warning allows you to make changes before committing, saving you time and frustration.
Repository rules
Administrators can configure many different repository rules that apply to branches or tags. If a commit fails any of them, you won’t be able to push it to GitHub. This can be frustrating if you have multiple commits queued up, because the whole push will fail and you may have to perform a rebase to fix the failed commits. GitHub Desktop will now preemptively warn you if a commit you’re working on will fail a rule when you eventually try to push it. These warnings happen in several ways.
Branch creation
Specific branch names may be disallowed. You’ll now see an error if you try to create a branch that isn’t allowed.
Metadata rules
GitHub Enterprise Cloud customers can utilize metadata rules that require certain fields to conform to specific values. One example being commit messages, which can be required to match a specific string or a regex pattern. These metadata rules are fully supported in GitHub Desktop 3.3.
Additional rules
Certain rules have remediations that aren’t supported by GitHub Desktop, such as requiring status checks to pass. These rules are bundled into a catch-all error message above the commit button.
Bypassing
Administrators can allow certain apps, roles, or teams to bypass rulesets. If you can bypass rules, the guidance shown is in the form of warnings instead errors, to let you know to be extra careful.
Shout out to our open source contributors
GitHub Desktop is proud to be an open source project and represents both GitHub and the open source community. Thanks to @le0pard for creating the RE2JS library being used for repository rules regex matching.
In 3.2.8, GitHub Desktop is shipping two great community contributions of highly requested features — “Check Out a Commit” and “Double Click to Open in Your External Editor”.
Alongside that, we have a nice addition to the clone dialog where you can quickly see if a repository has been archived, as well as many accessibility enhancements.
Check Out a Commit
A big thanks to @kitswas for his work in adding the ability to check out a commit from the history tab, a much asked for feature.
Double Click to Open in Your External Editor
We would also like to give a shout out to @digitalmaster with another highly requested feature add of being able to double click on a file to open it in your external editor, whether that is in the history or changes view.
Quickly Identify Archived Repositories when Cloning
Another great add with this release is being able to tell at a glance which repositories in your cloning dialog are archived and likely not suitable for cloning.
In so, we have the:
– addition of aria-label and aria-expanded attributes to the diff options button – #17062
– number of pull requests found after refreshing the list screen reader announced – #17031
– ability to open the context menu for the History view items via keyboard shortcuts – #17035
– ability to navigate the “Clone a Repository” dialog list by keyboard – #16977
– checkboxes in dialogs receiving initial keyboard focus in order not to skip content – #17014
– progress state of the pull, push, fetch button announced by screen readers – #16985
– inline errors being consistently announced by screen readers – #16850
– group title and position correctly announced by screen readers in repository and branch lists – #16968
– addition of an aria-label attribute to the “pull, push, fetch” dropdown button for screen reader users – #16839
– aria role of alert applied to dialog error banners so they are announced by screen readers – #16809
– file statuses in the history view improved to be keyboard and screen reader accessible – #17192
– ability to open the file list context menu via the keyboard – #17143
– announcing of dialog titles and descriptions on macOS Ventura – #17148
– announcing of the “Overwrite Stash”, “Discard Stash”, “Delete Tag”, and “Delete Branch” confirmation dialogs as alert dialogs – #17197, #17166, #17210
– improvements of contrast in text to links – #17092
– tab panels in the branch dropdown announced by screen readers – #17172
– stash restore button description associated to the button via an aria-describedby – #17204
– warnings in the rename branch dialog placed before the input for better discoverability – #17164
– errors and warnings in the “Create a New Repository” dialog are screen reader announced – #16993
Other Great Fixes
The remote for partial clone/fetch is recognized. Thanks @mkafrin! – #16284
Association of repositories using nonstandard usernames is fixed – #17024
The “Preferences” are renamed to “Settings” on macOS to follow platform convention – #16907
The addition of the Zed Preview as an external editor option – #17097. Thanks @filiptronicek
The addition of the Pulsar code editor as an external editor option on Windows – #17120. Thanks @confused-Techie
Fixing the detection of VSCodium Insider for Windows – #17078. Thanks @voidei
The \”Restore\” button in stashed changes is not disabled when uncommitted changes are present. – #12994. Thanks @samuelko123
At GitHub, we store multiple copies of every Git repository our customers push up. Every once in a while, one copy of a Git repository can wind up in a broken state. Usually, our maintenance processes fix the copy automatically, and no one ever notices the problem. Under very rare circumstances, the automation is unable to fix the problem, requiring manual intervention. To prevent further damage from accruing, the automation marks the repository "broken" and doesn't allow further changes (pushes or maintenance).
The GitHub web interface has long shown an informative message informing viewers that the repository is broken. With this change, the Git client will also receive a similar message. Previously, Git would report an unactionable, confusing, and very low-level error such as "fatal: bad tree object 3c8f2e6c8252929ce8334d52bd33b2bc358e7e4c".
✕
Wait! Don't Go Yet 🚀
Get our FREE eBook "10 Programming Tips That Changed Everything" when you subscribe!
Last year, we made merging pull requests much faster by using the merge-ort strategy. Now, rebase commits get the same merge-ort treatment. This results in significantly improved speed: the P99 (the average time to complete rebases excluding the 1% slowest outliers) used to take around 3.6 seconds. P99 with the new strategy is 0.35 seconds. Because of the speedup, the fraction of PR rebases which fail due to timeouts dropped from 1.3% to 0.14%.
GitHub Desktop 3.2.3 makes force pushing and fetching through the newly added fetch/pull dropdown menu items as well as adding pull request comment notifications. Since 3.2.1, GitHub Desktop has also released more than 30 accessibility improvements.
Force-pushing and Fetching
In GitHub Desktop 3.1.5, we added the ability to force-push and fetch to the Repository menu item when applicable. Now, when those menu items would be available, the pull/push/fetch button becomes a dropdown so users can easily force push or fetch.
Pull Request Comment Notifications
If you have been enjoying our Pull Request notifications on your repositories, you will be happy to hear we have expanded those notifications to include when someone has commented on your pull request as well so that you can keep up to date on the latest conversations happening on your pull request.
GitHub blocks branch and tag names which begin with refs/.
Under the hood, all Git refs begin with a prefix (refs/heads/ for branches and refs/tags/ for tags). In typical use, though, users rarely see these prefixes, so they're silently handled by GitHub, the Git client, and other tools. When a similar string is used as the beginning of the visible part of the branch or tag name, this results in ambiguity: did the user intend refs/heads/feature or refs/heads/refs/heads/feature? In nearly all cases, refs/ in front of a branch or tag name is accidental and becomes a problematic surprise later.
This change blocks new introductions of such names. Repositories with existing branches named this way can still push updates to those branches.
✕
Wait! Don't Go Yet 🚀
Get our FREE eBook "10 Programming Tips That Changed Everything" when you subscribe!
The "Require SSH certificates" policy now allows GitHub apps to call Git APIs using a user-to-server token, bringing them up to parity with OAuth app support.
The SSH certificate requirement mandates that users in your organization call Git APIs using an SSH certificate issued by your organization, in place of their own SSH key or a PAT.
To support automation, it has an exception in place for OAuth apps and GitHub app server-to-server tokens, which allows applications you've approved to call Git APIs for your organization.
With this change, we are extending that exception to GitHub app user-to-server tokens, for when a user has signed into a GitHub app that's installed in your organization.
This change also applies when the enterprise-level setting requires SSH certificates across all organizations in the enterprise.
In GitHub Desktop 3.1, we introduced viewing the diff of changes across multiple commits. This allows you to be certain there are no unintended changes in the group of commits you are about to push. Taking that feature to the next level, GitHub Desktop 3.2 allows you to Preview your Pull Request – see a diff of all the changes being introduced by your feature branch into your repository's default branch.
We are reverting this change for now. More details to follow.
The default compression for Git archives has recently changed. As result, archives downloaded from GitHub may have different checksums even though the contents are completely unchanged.<
GitHub doesn’t guarantee the stability of checksums for automatically generated archives. These are marked with the words “Source code (zip)” and “Source code (tar.gz)” on the Releases tab. If you need to rely on a consistent checksum, you may upload archives directly to GitHub Releases.
These are guaranteed not to change.
✕
Wait! Don't Go Yet 🚀
Get our FREE eBook "10 Programming Tips That Changed Everything" when you subscribe!
GitHub Desktop 3.1.5 improves support for force pushing and fetching through the newly added Repository menu items as well as supporting pull request notifications on forks. This release also comes with many great contributions (12 changelog entries! ✨❤✨) from our open source contributors.
Force-pushing and Fetching
Previously, a user could only force push after an action such as rebasing. Now, when users find their branch in any diverged state, they can opt to use the force push Repository menu item. For example, a user can force push when commits exist on the remote that they are sure they want to overwrite.
Similarly, a user may find themselves in a new local branch they are not ready to publish, yet they want to fetch to see if there are any new changes on their main branch they would want to merge in. Instead of having to switch branches, they can use the Repository menu item to fetch those changes.
Notifications for Forks
If you have been enjoying our Pull Request notifications on your repositories, you will be happy to hear that with 3.1.5 those same notifications are supported on forks.
Open Source Contributions
We love the help we get from the open source community, providing many fixes and improvements for everyone to enjoy.
Thank you @angusdev for contributing all these fixes:
Hide window instead of hiding the app on macOS
The repository change indicator is visible if repository list item is selected and in focus
Tooltips are positioned properly if mouse is not moved
Tooltips of long commit author emails wrap to multiple lines
Clone repository progress bar no longer hidden by repository list
Close repository list after creating or adding repositories
Thank you @tsvetilian-ty for adding support for JetBrains Toolbox and JetBrains Fleet editor for Windows.
Thank you @zipperer for adding support for emacs editor.
Thank you @patinthehat for adding support for JetBrains PhpStorm and WebStorm editors
Thank you @daniel-ciaglia for adding support for VSCodium as an external editor.
Thank you @Shivareddy-Aluri for adding the ability to copy tag names from the commit list.
Thank you @j-f1 for improving the the diff view by adding highlighting to Arduino's .ino files as C++ source.
GitHub Desktop 3.1 improves submodule support and now supports multi-commit diffing.
Submodule support just got much better from GitHub Desktop by providing a more detailed “diff” when they have changes. You will now know whether submodules are just pointing at a different commit or if there are changes within them that you must commit. You can also open the submodule at the click of a button!
You can now also see all the changes across multiple commits by just selecting them. That way, you can be certain about the changes you’re about to push or merge onto another branch, and make sure no unintended changes are included in them.
