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

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

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

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

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

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

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

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

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

You can now use the web UI to synchronize an out of date branch of a fork with its upstream branch. If there are no merge conflicts between the branches, the fork's branch is updated either by fast-forwarding or by merging from the upstream's branch. If there are conflicts, you will be prompted to open a pull request to resolve.

Fetch upstream up to date, no conflict, and conflict flows

See more

GitHub CLI 1.9 allows you to work with GitHub Actions in your terminal:

  • List and view workflows and runs with gh workflow list, gh workflow view, gh run list, and gh run view
  • View the logs for a particular run with gh run view --log
  • View the logs for runs with jobs that failed with gh run view --log-failed
  • Download run artifacts with gh run download
  • Re-run runs with failed jobs using gh run rerun
  • Watch runs in progress using gh run watch
  • Trigger workflows with the workflow_dispatch event using gh workflow run
  • Enable and disable workflows with gh workflow enable and gh workflow disable

Learn more about GitHub CLI and check out the blog post to learn more about this release.

See more