Skip to content

code

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

Explore the content of your npm packages with the new code explorer

You can now view the content of a package with the updated code explorer directly on the npmjs.com portal. We have improved the reliability, performance and have now made this feature available for free. You no more need to download a package to view its content. With this feature, you can easily scrutinise packages to make sure it is safe for use in your application. The code explorer provides syntax highlighting for .js, .ts, .md, .json and other commonly used file types in npm packages. You can also view the content of any previous version of a package.

Start by exploring the npm package.

See more

Better suggested pull request description from commit message

When opening a pull request from a comparison that only includes one commit, GitHub defaults the title and description to the subject line and body of that commit's message. Authors who write detailed git commit messages that adhere to the widely accepted convention of wrapping at 72 characters per line may have noticed that this can result in strange formatting because of how GitHub Flavored Markdown treats newlines.

We now take and automatically reformat the commit message when suggesting the pull request description, making it look just as good as the commit message it came from when viewed on github.com, GitHub Mobile, and other tools.

An image of a PR being opened before and after this change

Learn more about Creating Pull Requests

See more

File Finder: Customize Default Exclusions

The repository file finder is a convenient way to jump to a specific file by typing part of its path. It can be accessed by pressing t or using the “Go to file” button.

The file finder hides files in directories like vendor/ and build/ by default. These exclusions can now by customized using linguist attributes in a .gitattributes file. For example:

vendor/** linguist-vendored=false
build/** linguist-generated=false

An image of the file finder locating files in a repository's build directory using fuzzy search

Learn more about the file finder
Learn more about .gitattributes

See more

Warning about bidirectional Unicode text

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

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

All repositories are labeled public, private, or internal

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

Flag unsigned commits with vigilant mode

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

Pull request events now included in the audit log

Pull request and review-related events are now included in the audit log at both the enterprise and organization levels. This helps administrators better monitor pull request activity and ensure security and compliance requirements are being met.

Events now included in the audit log:

  • A pull request is created, merged, closed, reopened, converted to draft, or marked ready for review
  • A review is requested or a request is removed
  • A review comment is added, updated, or deleted
  • A review is submitted, dismissed, or deleted

Events can be viewed from the web UI, exported as CSV or JSON, or accessed via REST API. You can also search the audit log for specific pull request events. For example action:pull_request filters for events directly on a pull request, action:pull_request.merge shows just merge events, and action:pull_request_review shows review events.

Learn more about audit log and available pull request actions

See more

Updated pull request auto-merge behavior for users without write access

To prevent unexpected changes from potentially slipping in after auto-merge is enabled on a pull request, auto-merge is now disabled automatically when new changes are pushed by a user without write access to the repository.

Note: users without write access can still update their pull requests to bring in changes from the base branch without having auto-merge disabled, but auto-merge will be disabled if the update results in merge conflicts that have to be resolved. This is to prevent merge-conflicts being deliberately used as a way to introduce code that hasn't been fully reviewed by the people with write access to the project.

Learn more about automatically merging pull requests when all merge requirements have been met.

See more

Hyperlink support for submodules with relative paths

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