Skip to content

repositories

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

View repository pushes on the new activity view

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

The new code search and code view is now generally available

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

Pre-fill form fields when creating a new repo

You can now create new repositories with pre-filled form fields, making it even easier to define the right info for your new repos from the start.
There are a number of query string parameters available, including:

  • name
  • description
  • visibility
  • owner
  • template_name
  • template_owner

To get started you can craft a query string at the end of https://github.com/new starting with ? followed by the fields and their values.

See the example below for more details:

https://github.com/new?owner=octocat&name=new-boilerplate&description=A%20new%20boilerplate%20repository&visibility=private&template_owner=actions&template_name=boilerplate

Learn more about Creating a new repository

We appreciate your feedback in GitHub's public feedback discussions

See more

Enhancements for admins bypassing branch protections on github.com

When editing a file on github.com, repo admins, actors with the bypass branch protections permissions, and actors in bypass lists on branch protections will now default to creating a new branch instead for directly committing. You can still commit directly to a protected branch, but doing so will add notifications in-line highlighting that some rules will be bypassed.

Historically the default behavior was to push through any branch protections with no notifications they were being bypassed.

Now we recommend creating a branch for admins eligible to bypass branch protection rules. This behavior occurs when adding new files to a repository as well as during pull requests.

Screenshot of commiting directly to a repository
Screenshot of bypassing rules in a PR>

We appreciate your feedback in GitHub's public feedback discussions

See more

Fixed bug that allowed a hovercard URL to be used to display the name, description, and star count of any repository

On March 30, 2023, we fixed a bug that allowed a dependency graph hovercard URL to be used to retrieve the name, description, and star count of any repository on GitHub.com. The bug was introduced on March 28, 2023 and our investigation has found no evidence of exploitation. To exploit the bug, a specific header needed to be set when making a request to the URL and the numeric ID of a repository provided. The URL would then return the HTML content designed to be used for a hovercard UI element with the repository name, description, and star count in the response.

This bug was reported to GitHub via the GitHub Bug Bounty program.

See more

Introducing Repository Rules Public Beta

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

Info messages for bypassing branch protections in Git

We now show bypassed branch protection rules in response to Git pushes. These are information messages and are not designed to block workflows.

Historically there was no indication after a Git push that branch rules had been bypassed.

Repo admins, actors with the bypass branch protections permissions, and actors in bypass lists on branch protections will now see a list of rules that were bypassed.

Screenshot of Git command line interface showing list of rules

We appreciate your feedback in GitHub's public feedback discussions

See more

New Forks page view

screenshot of list of fork repos

We've made improvements to the Forks Insights tab to give you much more information on the forks of your project. Now when you visit the Insights tab for a repository the Forks section will display a sortable and filterable list of forks. You'll also now see more details about each of the forks, like how recently they were updated, their stars and pull requests. To see an example, check out the forks of GitHub's docs repository.

See more

No more waitlist – code search and code view are available to all in public beta

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

More love for innersource collaboration and enterprise fork policies

In June 2022 we updated fork capabilities to include forking a repository into the same organization as its upstream repository, forking internal repositories to enterprise organizations, and for enterprise owners to limit where forks can be created. This opened up a lot of new possibilities for collaboration!

We recently updated fork capabilities again to unblock an additional workflow: fork repositories into another organization more than once. Before, when you tried to fork a repository into another organization that already had a fork of that repository, your option to finish forking into that organization was grayed out and GitHub let you know that a fork already exists in the target organization. With this update, you will have the option to continue forking it using a unique name.

screenshot of forking when the repo already exists and has a red warning triangle

screenshot of forking when the fork has been renamed and has a green check

We welcome your feedback on this in GitHub’s public feedback discussions.

See more

Manage branch protection rules with a new permission

You can now create a custom role to manage branch protections without having to grant the Admin role. Previously, to manage branch protections you had to be an Admin which provides additional permissions that may not be needed. For tighter control of Admin permissions, you can now craft a custom role that has the Edit repository rules permission, allowing just the right amount of access.

Image of Custom roles that shows the new Edit Repository Rules permission

This permission grants the ability to create, edit, and delete both branch protection rules and protected tags.

For more information, visit Managing custom repository roles for an organization in the GitHub documentation.

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

See more

False-alert flags will appear in audit logs due to a bug in branch protections

Organizations and enterprises using branch protections may see false-alert flags in their security log for protected_branch.policy_override and protected_branch.rejected_ref_update events between January 6 and January 11, 2023.
These events were improperly emitted due to a change in the underlying logic that checks if branch protection criteria have been met.

No action is required from impacted users with regards to these events. GitHub has a policy to not delete security log events, even ones generated in error. For this reason, we are adding flags to signal that these events are false-alerts.

an audit log entry with the flash message displayed above it

See more

Rename repositories while transferring them

Now admins can transfer and rename a repository at the same time. Before, each action was separate.

In the transfer repository screen, choose “Select one of my organizations”. The “Repository name” field will appear below. You must be an admin on the target organization to rename the repository. Renaming isn’t available if you “Specify an organization or username”.

Optionally change the name the repository will have after transferring. Then complete the transfer!

Learn more about transferring a repository.

See more

Repository archive date now shown in UI

In a small but frequently requested improvement, GitHub now shows the date that an archived repository was put into read-only mode to indicate it is no longer actively maintained.

Previously, you could see that a repo was in the 'archived' state and probably infer from the commit log when it last saw activity, but the actual date the archiving happened was not surfaced anywhere. Now there's a date included in the "this repo is read-only" banner at the top of the repository view.

New repository banner showing an archived repository and the date on which it was archived

Repositories archived prior to November 9th, 2022, will display a more generic message.

Repository banner showing the generic message that it was archived prior to November 9th, 2022

See more

Introducing an all-new code search and code browsing experience

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

New Branch Protections: Last Pusher and Locked Branch

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

Enterprise fork policies for organizations

Previously, we announced the ability for enterprise owners to limit where private and internal repository forks can be created. We heard from some customers that they need a more granular control over fork permissions for each organization within the enterprise.

Now, we've added the ability for enterprise organization admins to set fork policy at the organization level, further restricting enterprise policy. Forking can be limited to organizations within the enterprise, within the same organization, user accounts and organization within the enterprise, user accounts, or everywhere. Fork policies cascade from the enterprise policy to organization policy to repository policy. Enterprise policies dictate the policy options available for organizations, i.e. an organization admin can only set a more restrictive forking policy than the enterprise allows.

Screenshot of organization fork policy settings

See more
View more changes