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

We are rolling out a few minor updates to the user experience for GitHub repositories starting today, in order to be more responsive, performant and more easily accessed by a broader range of users.

Repository Overview:
Screenshot of repository overview page showing entering a letter to expand to go to file menu.

  • Go to file: Quickly get to the file you want from the top of every repository using our existing code search and navigation experience.
  • Special files: If you have Code of Conduct, License, or Security files in your repository, they are now shown in tabs alongside your README.

Branches:
Screenshot of branches page showing the overview tab for branches of GitHub Docs repos.

  • Status checks: At a glance, see the status checks’ details on any branch.
  • Stale Branches: The overview page for branches no longer defaults to showing stale branches to improve load times. You can still easily see stale branches by clicking the “Stale branches” tab.

Commits:
Screenshot of Commits page filtered by date and user.

  • Filters: New commits filters allow you to sort by users or limit results to specific date ranges.

These changes have been in a feature preview for the past few months and thanks to community insights, we’ve made several improvements that allowed us to now exit the preview, and bring these enhancements to everyone on GitHub. Join the conversation about this release in the community discussion.

See more

In October, we launched the beta of Repository Custom Properties, enabling you to attach key-value pairs to repositories in your organizations. Among many scenarios, one of the key components we had envisioned was the ability to filter your repository properties. Making it easier to find exactly the set of repositories you were looking for.

Starting today, you can enable a new list view for repositories. This update improves accessibility and performance and introduces a new filter bar supporting properties.

To enable select New organization repositories view option in the feature preview dialog.

PNG Custom Properties Feature Preview.

Learn more about managing custom properties for your organization and managing rulesets for your organization.

Head over to the community discussions to share your feedback.

See more

Beginning January 8th, 2024, we will be making changes to the repository insights UI and API on GitHub for repositories with over 10,000 commits. The targeted UI and API have very low usage and rely on a legacy service we’re moving away from.

User Interface Updates

We are removing the following data:

  1. Under Insights > Contributors, we are removing addition/deletion counts for repositories with over 10,000 commits, as well as the dropdown that shows the graphs associated with additions and deletions. All the commit counts and commit count graphs will remain unchanged.
Current page Repos with over 10,000 commits after the change is made
The current Insights > Contributors tab The new tab which shows no dropdown for additions and deletions, and no addition and deletion counts
  1. Under Insights > Code Frequency, we will only show data for repos with under 10k commits.
Current page Repos with over 10,000 commits after the change is made
The current Insights > Code Frequency tab which shows a graph of additions and deletions over time The new tab which shows that there are too many commits to generate this graph

REST API Modifications

Alongside the UI changes, the following API changes will be implemented:

  1. The REST API responses for repositories with 10,000+ commits will report 0 values for the addition and deletion counts to improve performance. This impacts the /repos/{owner}/{repo}/stats/contributors endpoint to get all contributor commit activity
  2. The /repos/{owner}/{repo}/stats/code_frequency API endpoint will return a 422 status code for repos with 10,000 or more commits.
    • This is different from the previous two because this endpoint only returns additions/deletions, which we will no longer return for repos with over 10k commits. The previous two endpoints also return the total number of commits, which we will continue to generate.

For users who continue to need detailed addition and deletion statistics for large-scale repositories, we suggest using the following Git command, as described in the Git documentation:

git log --pretty="format:%m%ad----%ae%n%-(trailers:only,unfold)" --date=raw --shortstat --no-renames --no-merges

See more

You can now archive all repositories in an organization with a single click. Archiving an organization will:

  • Archive all repositories in the organization
  • Set a key in the API to indicate the org has been archived
  • Restrict activities in that organization such as creating new repos
  • Display a banner on the organization's profile indicating that it's been archived

To archive an organization, go to the organization's settings page and click the "Archive organization" button in the Danger Zone. This will launch a background job which performs the archiving; once complete, the banner will show up on the organization's profile page.

For more information on organization archiving, including how to un-archive an organization, see "Archiving an organization"

This feature is in public beta. We'd love to hear your feedback on how it works for you.

See more

The Custom Repository Roles REST API has moved to general availability, with a breaking change to the path used.
Previously, the API was found at /orgs/{org}/custom_roles – it has been moved to /orgs/{org}/custom-repository-roles. With organization-level custom roles in progress, we found that the custom_roles path was wasn't specific enough and could generate confusion.
The deprecated beta API will be removed from api.github.com in 6 months, on September 7th, 2023.
On GitHub Enterprise Server, the API will be available at its new path in version 3.9. The previous API to list roles was added in GHES 3.4, and will be removed with the next API version.

To learn more about custom repository roles, see "About custom repository roles" and "Custom repository roles REST API".

See more

Custom repository roles enable Enterprise organization administrators to define and assign least-privilege roles for their repositories, beyond the standard Read, Triage, Write, Maintain, and Admin roles.

Now, REST API endpoints to create and update custom repository roles are available in a public beta for GitHub Enterprise Cloud customers. These new endpoints build on the existing custom repository role APIs that allow assignment of those roles to a team or user. The endpoints accept PATs from organization admins, as well as calls from properly authorized OAuth and GitHub apps.

These REST APIs will be supported in GitHub Enterprise Server 3.8, after they reach general availability in GitHub Enterprise Cloud.

Find out more about programmatically creating custom repository roles.

We'd love to get your feedback through your account team, or in our community Discussions board topic.

See more

Custom repository roles are now GA for GitHub.com and Enterprise Server 3.5.

Organization admins can create custom repository roles available to all repositories in their organization. Roles can be configured from a set of 35 fine grained permissions covering discussions, issues, pull requests, repos, and security alerts. Once a role is created, repository admins can assign a custom role to any individual or team in their repository.

Custom repository roles can be managed in the Repository roles tab of your Organization settings:

image

Custom repository roles are also supported in the GitHub REST APIs. The Custom Roles API can be used to list all custom repository roles in an organization, and the existing APIs for granting repository access to individuals and teams support custom repository roles.

To get started with custom repository roles, read the docs.

See more

You can now enable debug logging when you re-run jobs in a GitHub Actions workflow run. This gives you additional information about the job's execution and its environment which can help you diagnose failures.

To enable debug logging, select "Enable debug logging" in the re-run dialog.

Re-run dialog screenshot

You can also enable debug logging using the API or the command-line client.

For more details see
Re-running workflows and jobs.

For questions, visit the GitHub Actions community.

To see what's next for Actions, visit our public roadmap.

See more

To further reduce the risk of a user using Actions to merge a change into a protected branch that was not reviewed by another person, the organization setting to disallow Actions from approving pull requests, which was introduced in January 2022, has been extended to also limit Actions from creating pull requests.

The Allow GitHub Actions to create and approve pull requests setting can be managed by admins in organization settings under Actions > General > Workflow permissions.

image

See more

A CODEOWNERS file defines the users or teams responsible for different parts of your repository, and helps ensure the right people are included in pull request reviews. We've shipped some improvements that make it easier to work with CODEOWNERS!

Surfacing syntax errors

Syntax errors are now surfaced when viewing a CODEOWNERS file from the web. Previously, when a line in a CODEOWNERS file had a syntax error, it would be ignored or in some cases cause the entire CODEOWNERS file to not load.

Screenshot of a CODEOWNERS file with errors

GitHub Apps and Actions can access the same list of errors using new REST and GraphQL APIs.

See which CODEOWNERS will be requested for review

When creating a new pull request or after pushing new changes to a draft pull request, any CODEOWNERS that will be requested for review are now listed:

Screenshot of pending reviewers on a draft PR

This gives you an early look at who will be requested to review once the pull request is marked ready for review.

Comment on the same line

Comments in CODEOWNERS files can now appear at the end of a line, not just on their own line:

*.js    @js-owner       # All JavaSript files

Learn more about CODEOWNERS files.

See more

We have introduced a new policy setting that controls whether GitHub Actions can approve pull requests. This protects against a user using Actions to satisfy the "Required approvals" branch protection requirement and merging a change that was not reviewed by another user.

To prevent breaking existing workflows Allow GitHub Actions reviews to count towards required approval is enabled by default. However, an organization admin can disable it under the organization's Actions settings.

image

See more

Instead of allowing all or no users to force push, admins can now be selective about who can force push to a repository.

The image below shows how in the past, admins could use a branch protection rule to allow force pushes for everyone or no one, including admins:

Branch protection rule to allow everyone or no one to force push

This all-or-nothing approach didn't support limiting force pushes to select users or teams of an admin's choosing. For example, you might have wanted to allow only a few people to force push, or you had an automated process that solely needed to force push.

Now, you can be specific about the people and teams who are allowed to force push. As shown in the image below, select Allow force pushes and Specify who can force push. Then, search for and select the people and teams who should be allowed to force push.

Branch protection rule to allow everyone, no one, or select users or teams to force push

For more information, visit Managing a branch protection rule.

See more

Now, only admins can rename branches that are protected by branch protection rules.

GitHub allows repository collaborators to rename every branch in a repository, with the exception of the default branch.
When a collaborator renames a branch, any non-wildcard branch protection rules that apply to that branch are also changed to match the branch's new name.
Because only admins can modify branch protection rules, renaming of a protected branch is now limited to admin users.

For more information, visit Renaming a branch and Managing a branch protection rule.

See more

You can now control which GitHub App a required status check is provided by. If status is then provided by a different app or by a user via a commit status, merging will be prevented. This ensures all changes are validated by the intended app.

Screenshot of a repository's required status check settings, specifying which GitHub App is required for each status check

Existing required status checks will continue to accept status from any app, but can be updated to only accept status from a specific app (see Editing a branch protection rule). Newly-added required status checks will default to the app that most recently reported the status, but you can choose a different app or allow any app to provide the status.

For more information see our documentation about protected branches.

See more

Administrators can now allow specific users and teams to bypass pull request requirements.

For context, this image shows how administrators can use branch protections to require pull requests for all changes to a branch:

screenshot of option to protect matching branches

This is a good practice, but you may want to make exceptions to this rule for specific people and teams. For example, if you have an automated process that calls GitHub APIs to make changes in a repository, you may want to permit that automation to make changes without creating a pull request.

Now, when you require pull requests and their related protections for a branch, you can specify people and teams who should be free from those requirements. As shown in the image below, select Allow specific actors to bypass pull request requirements. Then, search for and select the people and teams who should be allowed to bypass the requirements.

Screenshot of option to bypass PR requirements

For more information, visit Managing a branch protection rule.

See more

You can now require that all changes to a protected branch are made using a pull request, but without requiring reviews. This can be useful when you want to use pull requests for tracking purposes or to simplify your continuous integration (CI) configuration, but don't want to gate merging on review.

Previously, you could create a branch protection rule that required pull requests with approving reviews before commits could be merged into a branch. When pull requests were required, approving reviews were also required. This didn’t meet the needs of users who wanted to require pull requests for tracking purposes or CI validation, but who didn’t want their ability to merge to be gated by approving reviews.

Now, requiring pull requests and requiring approving reviews are separate options of protecting a branch. For example, you can now require pull requests without requiring reviews, or with requiring approving reviews. This flexibility lets you choose what is best for you and your branches.

image

For more information, visit Managing a branch protection rule.

See more