features

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

Say goodbye to unwanted files cluttering your repos, like *.jar or *.so. And limit who can make updates to sensitive files like your Actions workflows with the public beta of push rules. 🎉

A glimpse of push rules in action

You can now enable a new type of ruleset that allows you to control pushes to repositories based on file extensions, file path lengths, file and folder paths and file sizes. Push rules don’t require any branch targeting as they apply to every push to the repository, and also apply to all forks of the repo to ensure all pushes to the repository network are protected.

Push rules are now available for private and internal repositories for GitHub Teams, and across organizations for GitHub Enterprise Cloud.

Learn more about push rules in our documentation and join the community discussion to leave feedback.

See more

A total redesign of GitHub’s code search and navigation was released to all logged in GitHub users in May. Starting today, the new redesigned code navigation experience, including a file tree and symbols pane, will be available to anyone browsing anonymously on GitHub.com. To access the new code search experience, and make full use of the symbol navigation, create an account or log in to GitHub.com.

See more

GitHub Enterprise Cloud customers with enterprise managed users (EMU) can now integrate with Ping Federate as a formally supported SSO and SCIM identity provider in public beta. To get started, download the Ping Federate "GitHub EMU Connector 1.0" from the add-ons tab on the download page, under the "SaaS Connectors" heading. Add the connector to your Ping Federate installation and consult the Ping Federate documentation in addition to GitHub's SAML SSO and SCIM documentation for configuration.

PIC-Square-Logo-Primary

The "GitHub EMU Connector" is maintained and supported by our partner, Ping Identity. Ping additionally maintains their own release notes for this connector.

See more

We've now made it easier to understand changes to your repositories with the new activity view. Historically viewing pushes to a repository required contacting GitHub support. This new activity view gives users with read access the ability to self-serve insights to a repository and all of its changes.

You can access the Activity view from the main page of a repository by clicking "Activity" to the right of the list of files.

Location of activity view link on repo homepage

You can also access the activity view from the Branches page of any repository by clicking on the activity icon.

Branch activity icon

Activity view

From the activity view you can sort and filter to find exactly what you are looking for.

Filter activity type

Here is an example of how you could use the activity view to find a force push on a particular branch, and then compare the changes to the repository before and after the push:
Screen recording of the activity view

Learn more about the Activity view.

Already using the activity view? We'd love to hear your feedback.

See more

Bamboo Server and Data Center migrations to GitHub Actions are now in public beta! You can now plan, test, and automate the migration of your Bamboo pipelines to GitHub Actions easily and for free using GitHub Actions Importer.

For details on how to get started, check out our documentation. For questions and feedback about the public beta, please visit the GitHub Actions Importer community.

See more

At GitHub Universe last year, we announced a total redesign of GitHub's code search and navigation experience, powered by our all-new code search engine that we built from scratch. And in February, we announced our public beta.

Today, we are rolling out this feature to all GitHub users. Thanks to the members of the beta community for your excellent feedback and engagement throughout the beta!

Screenshot of code search results

Check out our blog post to learn more about how GitHub's new code search and code view can help you search, navigate, and understand your code. And if you have feedback, please share it with us in our feedback discussion.

See more

Today we are announcing the public beta of repository rules! 🎉

Repository rules are GitHub’s next evolution of branch protections to help make your repositories more secure and compliant at scale.

Screenshot of ruleset overview

Rules allow you to easily define protections for branches and tags in your repositories and, if you are a GitHub Enterprise Cloud customer, to enforce them across your organization. It is also easier for everyone collaborating on your repositories to know what rules are in place.

Creating rules

Screenshot of creating a ruleset

At the core of rules is the ability to define rulesets. A ruleset is a collection of rules that are enforced together. For example, you could require that all commits to a branch are signed and that those commits have two reviewers. Rulesets can also be applied to tags, allowing you to enforce rules on releases.

The ruleset page is the central place to view and manage all the rules for a repository. It shows the rules that are currently in place and allows you to add new rulesets or edit existing ones.

When creating a ruleset, you define its enforcement status as active or disabled. Active rulesets must pass for a commit to be merged, while disabled rulesets are not enforced; they will not prevent merges but allow admins to craft rules before enforcing them. Enterprise Cloud customers can also evaluate rulesets: a “dry run” mode for understanding the impact of new rules before they are active and enforced.

It’s also easier to target branches and tags in rulesets, with options to select the default branch, all branches, and branches or tags that match an fnmatch pattern. You can add multiple patterns to a ruleset to apply it to different branch and tag naming styles.

Viewing the rules

You can always know what rules are in place for a repository.

Anyone with read access to a repository can view its rules and what they mean. The rulesets overview is linked from the branches page by clicking the shield icon, and from a pull request, and from the output of the Git CLI when rules block a push.

From here, you can filter rules by branches or tags to understand how a rule might be enforced on your next push.

Screenshot of read only view of rules

Getting Started

Repository rules are now available to all GitHub cloud customers. To get started, visit the documentation to learn how to enable and use rules. For Enterprise Cloud customers, visit the documentation to learn about organization rulesets and more.

We want to hear from you on how we can improve repository rules! Join the conversation in the repository rules public beta discussion.

See more

Team Maintainers may now disable notifications resulting from a team @mention in GitHub issue and pull request comments through an optional configuration in the team settings page. Notifications resulting from PR review requests are unaffected by this setting. Existing issue and PR subscriptions are also unaffected. This team setting will also be exposed via API.

For more information, see the teams documentation.

See more

GitHub Actions Importer is now generally available to all GitHub users. You can now easily plan, forecast, and automate migrations from Azure DevOps, CircleCI, GitLab, Jenkins, and Travis CI to GitHub Actions. GitHub Actions Importer is a free extension of the official GitHub CLI and provides you with the confidence to migrate your CI/CD pipelines to continue delivering software efficiently.

gh-actions-importer

For details on how to get started, please check out our documentation. For questions and feedback, visit the GitHub Actions Importer community.

See more

Reading and understanding code is an absolutely critical task for software developers. Research suggests developers spend far more time reading code than writing it. Reviewing a pull request, planning a new feature, researching a system’s architecture, or determining how to fix a bug are all activities that rely on finding critical information scattered across the codebase.

That’s why we’ve built the new code search and code view—to help developers search, navigate, and understand their code, their team’s code, and the world’s open source code.

At GitHub Universe in November we announced the beta waitlist for the new code search and code view. Today we’re removing that waitlist. Now any user can access the new search and code viewing experience using this link, or via the feature preview menu. To access the feature preview menu, click your avatar at the top-right of a GitHub page and select Feature preview. Then select the beta and click the Enable button.

mockup screenshot of new code view and code search features

This beta brings three powerful new capabilities to GitHub.com. First, an entirely new search interface, allowing you to construct powerful queries with suggestions, completions, and the ability to slice and dice your results.

The second capability is our entirely new code search engine, capable of searching and even understanding code. It delivers more relevant results with incredible speed. Curious about how it works? Read about the groundbreaking technology behind the new code search in the GitHub blog earlier this month.

The third capability is a redesigned code view. The new view integrates search, browsing, and code navigation, allowing developers to rapidly traverse their code to find answers.

This is a big step forward for code search and navigation at GitHub, but we’re far from done. Check it out yourself, and share your feedback with us here.

 

See more

Understanding code is one of the most important parts of software development. Developers need to be able to quickly search, navigate, and understand their code to do their best work. That’s why we have dramatically upgraded the code search and browsing experience on GitHub with an all-new code search and code view beta that we’re excited to announce today!

You can access the new features by joining the waitlist.

A better way to search code

We’ve developed a new code search engine at GitHub completely from scratch, capable of finding relevant results with incredible speed. The all-new code search engine supports powerful features, like regular expressions, Boolean expressions, qualifiers, symbol search, and more!

We’ve also totally redesigned the search input, adding powerful capabilities like suggestions and completions as you type.

Screenshot of our redesigned search input

And the new search results UI allows you to slice and dice your results.

Screenshot of the search results page

These improvements replace the 2021 technology preview for GitHub code search at cs.github.com.

The all-new code browsing experience

This is the revamped code viewing experience for GitHub repositories. This experience has several new features including a tree pane for browsing files, symbol search, fuzzy search for files, sticky code headers, and much more! We’ve designed this code viewing experience to provide a generational jump in code browsing and viewing on GitHub.

Screenshot of the redesigned code browser

Starting with the new tree pane on the left, you can explore repository folders and files without changing pages or losing context. You can also search files within the repository, making it easier than ever to find the right file.

Screenshot of left tree pane

Moving on to the right-side symbols pane, you can simply click on a symbol in code, such as a function name, to view its definition and references across files.

Screenshot of symbols pane

In addition to symbol navigation, we re-vamped find-in-file and bound it to CMD/CTRL+F to be even better than before.

Along with the overhauled code view, we updated the blame view. You can toggle the blame view from the code view to keep context and view a file’s history.

Lastly, we reworked the file editing experience! Now you can edit a file without losing context, and we’ve made it easy to open a file in github.dev or GitHub Desktop.

There are so many features that couldn’t be listed here and we can’t wait for you to discover them! Over the next weeks we’ll ship many improvements that focus on accessibility and integrating feedback from the community.

Join the beta waitlist

We are eager for you to try the new code search and code view beta! Join the waitlist to get access.

This project is a major update to GitHub’s user experience that was made possible by the feedback you provided. Help make the experience even better by sharing your latest feedback here.

See more

Today we're releasing two new branch protections.

Require approval from someone other than the last pusher

Now, before a pull request can be merged, you can require it to be approved by someone other than the last pusher.
Meaning, the most recent user to push their changes will need a pull request approval regardless of the Require approvals branch protection. Or in the case of 1 approval required, someone other than the last user to push their changes will also need to approve. If the approvals come from other folks than the last pusher, those two approvals will be sufficient.

Screenshot of Last Push protection enabled.

Lock branch

This allows for branches to be locked, prohibiting changes. You can lock a branch allowing you to have a maintenance window and prevent changes, or to protect a fork so it only receives changes from its upstream repository.

To use this feature in a branch protection rule, enable Lock branch.

Screenshot of Lock branch with fork sync enabled

For more information, read About protected branches in the GitHub documentation.

We appreciate feedback on this and other topics in GitHub's public feedback discussions.

See more

We updated the web UI to make keeping forks in sync with their upstream repositories more intuitive. "Fetch upstream" has been renamed to "Sync fork," which better describes the button's behavior. If the sync causes a conflict, the web UI prompts users to contribute their changes to the upstream, discard their changes, or resolve the conflict.

Image of sync fork button

Read more about branches.

Read more about working with forks.

See more

Previously, when creating a fork all branches from the parent repository were copied to the new fork repository. There are several scenarios where this is unneeded, such as contributing to open-source projects. When all branches are copied, it could result in slow repo cloning and unnecessary disk usage. With this new feature, only the default branch is copied; no other branches or tags. This may result in faster clones because only reachable objects will be pulled down.

New fork page with ability to copy only the default branch

If you want to copy additional branches from the parent repository, you can do so from the Branches page.

Read more about copying additional branches.

Read more about branches.

Read more about working with forks.

See more