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

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

Set via API whether a repository allows forking

You can now set whether a repository allows forking when creating or updating it using either the REST or GraphQL API.

Previously, APIs for creating and updating repositories didn't consider the fields allow_forking (REST) or forkingAllowed (GraphQL). Now, this field can be set before invoking the API to configure whether a repository allows forking.

For reference, see documentation for the REST API and GraphQL API.

See more

Easier to search branches by exact name

Previously, in the code browser, when you were searching for a branch by typing its name, a branch with the exact name of what you typed could appear at the bottom of the list of matching branches. This made it hard to recognize and sometimes requiring scrolling to the end of the list to select the branch.

Now, when a branch name exactly matches what you type in the search box, it appears at the top of the list of matching branches for faster recognition and selection.

image

See more

The push webhook payload provides a consistent head_commit on tag creation

When a new tag is created, the push webhook payload will now always include a head_commit object that contains the data of the commit that the new tag points to. In other words, the head_commit object will always contain the commit data of the payload's after commit.

Previously, during tag creation, there were certain circumstances where the head_commit would contain the data of a different commit.

See more

A simpler API for authoring commits

The new GraphQL mutation createCommitOnBranch makes it easier to add, update, and delete files in a branch of a repository.

This new API offers a simpler way to commit changes compared to the existing Git database REST APIs. With the new createCommitOnBranch mutation, you do not need to manually create blobs and trees before creating the commit. This allows you to add, update, or delete multiple files in a single API call.

Commits authored using the new API are automatically GPG signed and are marked as verified in the GitHub UI. GitHub Apps can use the mutation to author commits directly or on behalf of users.

See the GraphQL API reference for more information on using createCommitOnBranch. You can also try it in the GraphQL API Explorer! If you need a refresher on how to use the GraphQL API, see our guide.

See more
View more changes