Skip to content

git

Subscribe to all “git” posts via RSS or follow GitHub Changelog on Twitter to stay updated on everything we ship.

→ ~ cd github-changelog
→ ~/github-changelog|main git log main
showing all changes successfully

GitHub Desktop 3.3 – Repository rules

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.

GitHub Desktop’s “Create a branch” dialog showing a disallowed branch name error

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.

GitHub Desktop’s commit message area, showing an error for a commit message rule failure

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.

GitHub Desktop’s commit message area, showing a generic error for a failed repository rule

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.

GitHub Desktop’s commit message area, showing bypass warnings for a commit message rule and another rule

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.

Automatic updates will roll out progressively, or you can download the latest GitHub Desktop here.

See more

GitHub Desktop community adds “Check Out a Commit” and “Double click to Open External Editor”

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.

Shows check out a tag commit with new context menu option

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.

Shows double clicking in the history view to open a file

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.

Clone dialog with one repo having the Archive tag added

Accessibility

GitHub Desktop is actively working to improve accessibility in support of GitHub’s mission to be a home for all developers.

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

Automatic updates will roll out progressively, or you can download the latest GitHub Desktop here.

See more

Improved Git error message for broken repositories

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".

See more

Rebase commits now created using the merge-ort strategy

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%.

Learn more about the Git merge-ort strategy and merge methods for pull requests.

See more

GitHub Desktop makes force pushing and fetching easy and adds pull request comment notifications

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.

Gif that shows a user pressing fetch to put the repository in a diverged state. Then, shows the user opening the new dropdown and force pushing their changes to overwrite the changes in the remote.

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.

Accessibility

GitHub Desktop is actively working to improve accessibility in support of GitHub's mission to be a home for all developers.

GitHub Desktop 3.2.1

  • Misattributed warning is announced in 'Git' preferences/options by screen readers – #16239
  • The Preferences/Options dialog content is still visible when zoomed at 200% – #16317
  • Up/down arrow can be used to navigate autocomplete lists like emoji again – #16044
  • Focus history and changes list when accessed via keyboard shortcut or menu – #16360
  • On Windows, app level menu bar and menu items are announced by screen readers – #16315
  • Keyboard shortcuts for resizing app sidebar and file lists – #16332
  • Misattributed commit popover does not clip when app is zoomed – #16407
  • Accessibility improvements for the co-authors input – #16335
  • Commit completion status is announced by screen readers – #16371, #16340
  • Improve accessibility of dialogs for screen reader users – #16350
  • Accessibility improvements for autocompletion suggestions – #16324
  • Learn more links are descriptive for screen readers – #16274
  • Popover titles are announced by screen readers – #16270
  • Show offset focus ring for buttons, vertical tabs etc – #16288
  • Application main menu on Windows doesn't clip when zoom is set to 200% – #16290
  • Button and text box contrast bumps – #16287
  • Other email input in "Git" preferences/Options and misattributed popover email select have a screen readable label – #16240
  • Add/remove co-authors button is now keyboard accessible – #16200

GitHub Desktop 3.2.3

  • NVDA reads number of suggestions when an autocompletion list shows up – #16526
  • The undo commit confirmation modal message is screen reader announced – #16472
  • Clipping and overlapping of the changes list is fixed at 200% zoom – #16425
  • The commit message avatar is now a toggle tip making the commit author details keyboard accessible – #16272
  • The commit length hint is keyboard and screen reader accessible – #16449
  • The changes list header checkbox tooltip description is announced by screen readers – #16457
  • The changes list header checkbox tooltip is keyboard accessible – #16487
  • Announce a file's state of inclusion in the commit on the changes list – #16420
  • Display focus ring around focused control after dismissing a dialog – #16528
  • Identify the changes list and history commit list as the changes and history tab panels for screen readers – #16463
  • Windows title bar controls do not interrupt screen readers in browse mode – #16483
  • Make radio theme selection look like radio buttons. – #16525
  • Improve accessibility of GitHub Enterprise login flow – #16567"
  • Screen readers announce sign in errors – #16556"

Automatic updates will roll out progressively, or you can download the latest GitHub Desktop here.

See more

Block ambiguous branch and tag names

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.

See more

SSH Certificate requirement update

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.

Screenshot of the SSH Certificate requirement checkbox

This change also applies when the enterprise-level setting requires SSH certificates across all organizations in the enterprise.

To learn more, see "Managing your organization's SSH certificate authorities" or "Managing SSH certificate authorities for your enterprise".

See more

GitHub Desktop 3.2 – Preview your Pull Request

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.

Preview Pull Request Image showing debugger in a diff

Learn more about GitHub Desktop here.

See more

Git archive checksums may change

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.&lt

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.

See more

GitHub Desktop improves force pushing and fetching along with many great open source contributions

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.

ALT GitHub Desktop repository in a diverged state with Repository menu open showing force push menu item

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.

Learn more about GitHub Desktop here.

See more

GitHub Desktop improves submodule support and now supports multi-commit diffing

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!

Screenshot of GitHub Desktop displaying a submodule diff

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.

Screenshot of GitHub Desktop displaying multi-commit diffs

Learn more about GitHub Desktop

See more

Git commit author shown when squash merging a pull request

The author of the Git commit created when squash merging a pull request is now shown before merging. Previously, the commit author was only shown when merging with a merge commit.

image

Also, if the user merging the pull request also opened it and has multiple email addresses configured, a drop-down now lets them choose a different email address to use for the commit's author.

image

These improvements are designed to ensure Git commits created by squash merging are associated with the correct email address.

Learn more about merging a pull request.

See more

Merge commits now created using the merge-ort strategy

When GitHub creates merge commits, like to test whether a pull request can be merged cleanly or to actually merge a pull request, it now uses the merge-ort strategy. merge-ort is a relatively new Git merge strategy that is significantly faster (for example, complex merge commits that previously took 5 or more seconds to create are now created in less than 200 milliseconds) and addresses subtle correctness issues found in the merge-recursive strategy. And because merge-ort is the default merge strategy in the latest releases of Git, merge results are now more predictable and consistent between your local machine and GitHub.

Learn more about the Git merge-ort strategy and merge methods for pull requests.

See more

GitHub Desktop 3.0.6 Community Contributions

GitHub Desktop 3.0.6 brings a slew of community contributions! As an open source project, we are always so grateful to our contributors who make Desktop better for themselves and others. Additionally, we’ve improved the recognition of default branch changes.

Adds:

  • Add Warp terminal integration for macOS. Thanks @lhvy!
  • Add PyCharm Community Edition support on macOS. Thanks @tsvetilian-ty!
  • Add context menu to the current branch and current repository toolbar. Thanks @uttiya10!

Fixes:

  • Older versions of Sublime Text and SlickEdit are also recognized as external editors. Thanks @vbwx!
  • Fix commit shortcut (Ctrl/Cmd + Enter). Thanks @tsvetilian-ty!
  • Show 'Email' label on the preferences form when user is not signed in. Thanks @andymckay!
  • Fix invalid URL state while the "Clone Repository" modal is open. Thanks @tsvetilian-ty!
  • Fix commit description with three lines overflowing when it shouldn't. Thanks @HeCorr!
  • 'Update from default branch` menu item allows quick merge of upstream. Thanks @uttiya10!
  • Unified diff line gutter context menu items for discard changes no longer enabled when whitespace is hidden.
  • 'Show Whitespace Changes' popover appears as expected on unified diff.
  • On pull or fetch, make sure the default branch is updated to match the repository settings.
  • Fix notifications on Windows 10 builds prior to the Creators Update.

Improvements:

  • Add ability to skip staggered release to ensure the latest version is downloaded.

Learn more about GitHub Desktop

See more

Block potentially destructive Git pushes

This beta feature allows repository admins to block Git pushes to a repository when they are potentially destructive.

Developers have had branches deleted from their repository when someone pushes changes with Git's --mirror option. The --mirror option is potentially destructive because it makes the remote repository exactly match the local clone. When run by accident, if the remote has more branches or different data than the local clone, many branch deletes and force-pushes can happen at the remote without any warning. This is often embarrassing for the one who pushed and a big challenge to recover from. Here's a real-world example: git push origin –mirror deleted all of my colleagues' branches.

This destructive situation can usually be identified by multiple branch or tag updates being pushed at the same time. The new beta feature being announced here allows admins to block potentially destructive pushes by limiting the number of branches and tags that can be updated by a single push. This can prevent or limit the loss of data.

To use this beta feature, click Settings in a repository that you are an admin of. Next, select General (the default, top-most tab). Then toggle the setting named Limit how many branches and tags can be updated in a single push as shown below. Set the number appropriately for your needs. We recommend the default maximum of 5 branch or tag updates allowed in one push. The minimum value is 2 since two branch updates are required by Git to rename a branch in a single push: delete branch and create branch. Lower numbers are more restrictive of which pushes are allowed, and higher numbers are less restrictive but have more potential for being destructive. As part of this feature's beta, we'd like to learn which number works best for you.

Image showing the setting labeled "Limit how many branches and tags can be updated in a single push."

We appreciate feedback on this and other topics in GitHub's public feedback discussions.

See more

Improved verification of historic Git commit signatures

GitHub will now verify Git commit signatures and show commits as "Verified" even if their public GPG signing keys are expired or revoked (but not compromised). You can also upload GPG keys that are expired or revoked to your GitHub user profile.

Using GPG or S/MIME, you can sign Git commits. These commits are marked "Verified" in GitHub's web interface, giving others confidence that they come from a trusted source because they carry their committer's signature.

GPG keys often expire or are revoked when no longer used. Previously, when a public GPG key stored in a GitHub user profile was expired or revoked, all commits that had ever been signed with that key would be shown as "Unverified" on GitHub. That raised unnecessary concern since the commits were validly signed before their key was expired or revoked. Now, when a user's GPG key expires or is revoked for a reason other than being compromised, GitHub will continue showing commits that were previously signed with that key as "Verified." You can also upload GPG keys that are expired or revoked. Besides maintaining trust in commits’ sources, this allows GPG keys to be added or rotated for greater security without losing the “Verified” status of previously signed commits.

An image of GitHub showing a commit's signature as verified even though its public GPG key is expired

For more information, visit About commit signature verification in the GitHub documentation.

We appreciate feedback on this and other topics in GitHub's public feedback discussions.

See more

GitHub Desktop 3.0 brings better integration with your GitHub pull requests

GitHub Desktop 3.0 is bringing a closer integration with GitHub pull request workflows.

  • Real-time desktop notifications:
    • Pull Request Reviews: You know right away when your PR is approved, you need to make changes, or someone provided you with a feedback.
    • Pull Request Check Run Failures: You know as soon as your checks fail so you can quickly get them resolved and your PR ready for review.
  • Improved interaction for your pull request's checks:
    • Improved UX for rerunning checks
    • Ability to rerun failed GitHub Action checks
    • Ability to rerun individual GitHub Actions checks

Learn more about GitHub Desktop

See more

Removed unencrypted Git protocol and certain SSH keys

GitHub changed which keys are supported in SSH and removed the unencrypted Git protocol.
You can read more about the motivation behind these changes in our blog post from last September.
As a reminder, these changes were:

  • Removed all support for DSA keys
  • Required SHA-2 signatures on all RSA keys uploaded after November 2, 2021 (RSA keys uploaded prior to the cutoff may still use SHA-1 signatures)
  • Removed legacy SSH algorithms HMAC-SHA-1 and CBC ciphers
  • Permanently disabled the unencrypted Git protocol
See more

Audit log streaming is generally available

GitHub audit log streaming is now out of beta and generally available. Your experience using audit log streaming will not change, but we expanded the number of options you have for where you can stream your audit and Git events:

  • Amazon S3
  • Azure Blob Storage
  • Azure Event Hubs
  • Google Cloud Storage
  • Splunk

Enterprise owners can set up their stream in minutes by navigating to their enterprise account settings under the Audit log tab and configuring the collection endpoint.

Learn more about audit log streaming

See more
View more changes