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

New Enterprise accounts have metered billing for Git LFS

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

For more information, visit “About enhanced billing for Git Large File Storage” and “Using the enhanced billing platform for enterprises.”

Questions or suggestions? Join the conversation in the community discussion.

See more

GitHub Desktop 3.4 – Reset to Commit and Accessibility Settings

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.

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.

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

See more

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
View more changes