Skip to content

repos

Subscribe to all “repos” 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

A warning is now displayed when a file's contents include bidirectional Unicode text. Such text can be interpreted or compiled differently than it appears in a user interface. For example, hidden, bidirectional Unicode characters can be used to swap segments of text in a file. This can cause code to appear one way and be interpreted or compiled another way.

image

This security issue is the topic of the Common Vulnerabilities and Exposures (CVE) publication: CVE-2021-42574. If your use of bidirectional Unicode characters is intentional and not malformed, you can ignore the warning.

To review a file for which this warning is displayed, open it in an editor that will display the hidden, bidirectional Unicode characters, like Visual Studio Code which highlights the characters by default. Then, verify that the characters are necessary and not disguising text that will be interpreted or compiled differently than it appears.

For more information, refer to Trojan Source: Invisible Source Code Vulnerabilities.

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

Public repositories now have a public label next to their names like private and internal repositories do.

Previously, repositories had a label next to their name that indicated if they were private or internal, but there was no label if they were public. This led to people not recognizing that a repository was public and accidentally committing private code to it. Now, public repositories have a public label next to their name like private and internal repositories do.

image

Learn more about repository visibility.

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

You can now copy the full, raw contents of a file in your repository to the clipboard with just one click. Previously, you would need to open the raw file, select all, and then copy.

To copy the contents of a file, navigate to the file and click the Copy raw contents button on the toolbar:


This feature is available in most desktop web browsers.

Learn more about working with files.

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

The new Required Conversation resolution branch protection rule and Conversations menu is now generally available. Easily discover your pull request comments from the files changed tab and require that all your pull request conversations are resolved before merging.

conversations-menu

You can enable and disable the conversation resolution branch protection rule through your repository branch settings, or with our REST and GraphQL APIs. Apart from this change, we are also introducing a new type of webhook event that is triggered when a conversation is resolved or unresolved.

Learn more about discovering and navigating conversations.

See more

On GitHub today, half of all pull request review conversations are left unresolved prior to merging. Now it is easier for authors to discover unresolved comments from the conversations menu in the files changed tab.

image

In addition to making it easier for you to discover conversations in your pull requests, a new branch protection option gives admins the ability to require all review conversations be resolved before the pull request can be merged. This helps ensure all review conversations are seen and addressed prior to merging.

image

Both features are currently in beta. Let us know what you think: give feedback.

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

To improve security and confidence in the authenticity of your contributions, you can flag commits and tags on GitHub.com that are attributed to you but not signed by you. With vigilant mode enabled (now available in beta), unsigned commits attributed to you are flagged with an Unverified badge. This can alert you and others to potential issues with authenticity.

The author and committer of a Git commit can easily be spoofed. For example, someone can push a commit that claims to be from you, but isn’t. Like showing a passport, committers can increase trust in their commits by signing them with a GPG or S/MIME key. And now, when you enable vigilant mode, commits will be flagged if they’re attributed to you but not signed by you. This raises attention if someone tries to spoof your identity as a committer or author. With vigilant mode enabled, all of your commits and tags are marked with one of three verification statuses: Verified, Partially verified, or Unverified.

Commits and tags are marked with one of three verification statuses

Try it yourself! First, check out how to automatically sign your commits. Then, enable vigilant mode in your account settings:

Vigilant mode in GitHub.com personal account settings

Be sure to enable vigilant mode after you start signing your commits and tags. Once you enable it, any unsigned commits or tags that you push to GitHub.com will be marked "Unverified," including past commits.

Learn more about vigilant mode.

See more

Submodules defined with relative paths are now clickable in the web UI, making it easy to navigate to linked repositories. Previously, only submodules with absolute URLs were clickable.

Only relative paths following the format ../{repo} (a repository with the same owner) or ../{owner}/{repo} (a repository with a different owner) are supported.

To learn more about submodules, see Working with submodules on the GitHub blog.

See more