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

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

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

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

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

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

When GitHub creates merge commits, like to test whether a pull request can be merged cleanly or to actually merge a pull request, it now uses the merge-ort strategy. merge-ort is a relatively new Git merge strategy that is significantly faster (for example, complex merge commits that previously took 5 or more seconds to create are now created in less than 200 milliseconds) and addresses subtle correctness issues found in the merge-recursive strategy. And because merge-ort is the default merge strategy in the latest releases of Git, merge results are now more predictable and consistent between your local machine and GitHub.

Learn more about the Git merge-ort strategy and merge methods for pull requests.

See more

Previously, we announced a change to how <num> parameters work for autolink references, switching from numeric to alphanumeric IDs. We heard from a number of customers who still need numeric identifiers. Now when creating an autolink reference, you can use an alphanumeric or numeric identifier.

Screenshot of Autolink references

Autolinks are available in repositories with GitHub Pro, GitHub Team, GitHub Enterprise Cloud, and GitHub Enterprise Server. For more information, see GitHub's products.

Learn more about autolinks at Configure autolinks 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

GitHub now supports SSH commit verification, so you can sign commits and tags locally using a self-generated SSH public key, which will give others confidence about the origin of a change you have made. If a commit or tag has an SSH signature that is cryptographically verifiable, GitHub makes the commit or tag "Verified" or "Partially Verified."

image-of-verified-commit

If you already use an SSH key to authenticate with GitHub, you can now upload the same or a different key pair’s public key to use it as a signing key. There is no limit to the number of signing keys you can add to your account. For more information, visit SSH Commit Verification in the GitHub documentation.

image-of-ssh-signing-key-ui

See more

You can now create a custom role to bypass branch protections without having to grant the Admin role. Previously, to bypass 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 Bypass branch protections permission, allowing just the right amount of access.

Image of Custom roles Inherited from Maintain role that adds the new Bypass branch protections permission

To enforce branch protections for all Admins and roles with the "Bypass branch protections" permission, enable Do not allow bypassing the above settings in your branch protection rules.

Image of checkbox selecting Do not allow bypassing the above settings

This permission differs from the Push commits to protected branches permission, which allows pushing to a protected branch, but branch protection rules will still apply and could result in a push being denied.

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

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

See more

Code review on GitHub has evolved a lot since we introduced the ability to comment on an individual commit in 2008. Users today can propose a change using a pull request, which provides a first-class experience for reviewing, discussing, evolving, and ultimately accepting or rejecting a change. While pull requests are the recommended way to review and discuss proposed changes, commenting on individual commits is still currently supported.

We recently rolled out a change to no longer show comments added to individual commits (comments added outside the context of a pull request) on the pull request timeline. Previously, if a pull request happened to include a commit that had commit comments, those comments would appear on that pull request’s timeline. Users often reported that these comments were irrelevant to the pull request or caused confusion when added by someone not involved in the review.

Note: this change does not impact the ability for users to comment on individual commits or review a pull request one commit at a time.

Comparing commit comments and review comments

To help understand this change, let’s compare commit comments with pull request review comments.

A commit comment is a comment added by a GitHub user to an individual commit or to a line of a file changed in a commit. Commit comments are stored on GitHub and surface in various places in the GitHub UI, including at the bottom of the commit page (/:org/:repo/commit/:sha):

image

A commit comment is associated with a commit. A commit comment cannot be added from the pull request page and cannot be replied to or resolved like a pull request review comment because it does not belong to the pull request. A commit comment can be indirectly associated with a pull request if that pull request includes the commit.

A pull request review comment is a comment added by a GitHub user to a changed line (or the lines surrounding it) in a pull request. Review comments are usually added from the Files changed or Commits tab of the pull request page and are directly associated with the pull request.

image

Unlike commit comments, pull request review comments do not surface outside the context of the pull request since they belong to the pull request.

What changed

Prior to this change, comments on individual commits (made outside the context of the pull request) would appear in the timeline of any pull request that included that commit:

image

With this change, commit comments (like the highlighted 029541b comment) no longer appear in the pull request timeline.

The timeline events REST and GraphQL APIs also no longer return commit comments associated with any commits included in the pull request.

What did not change

This change did not impact a user’s ability to add, view, or manage comments on individual commits.

  • Users can still add comments to individual commits or changed lines in a commit
    image
  • Users can still review pull requests one commit at a time and add review comments
  • Commit comments still surface on the commits listing page
    image
  • Commit comments still surface at the bottom of the commit page
  • Commit comments are still accessible from the Commits tab of the pull request page
    image
  • Commits pushed to a pull request head branch still surface in the timeline and on the Commits tab of the pull request page

There was also no impact to commit messages, i.e. the message stored with the Git commit. Commit messages continue to surface everywhere they previously surfaced, including on the pull request page.

We want to hear from you

If you have feedback or questions about this change, let us know here: https://github.com/orgs/community/discussions/28924

See more

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

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

Previously, when creating an autolink reference for a repository, you could only use a numeric identifier in the <num> parameter. This format didn't support integration with platforms that use alphanumeric identifiers, like the last segment of this Trello card URL: https://trello.com/c/3eZr2Bxw. Now you can create an autolink with an alphanumeric identifier.

Any previously created autolinks will continue to support only numeric identifiers so that they continue working as before. Only newly created autolinks will support alphanumeric identifiers.

Autolinks are available in repositories with GitHub Pro, GitHub Team, GitHub Enterprise Cloud, and GitHub Enterprise Server. For more information, see GitHub's products.

Learn more about autolinks at Configure autolinks in the GitHub documentation. We appreciate feedback on this and other topics in GitHub's public feedback discussions.

See more

A dropdown has been added to the Fork button to help you quickly find your forks of a repository. This includes forks in your personal account and in organizations that you're a member of.

Example of the "your existing forks" dropdown

This feature was inspired by Refined GitHub – an impressive open source project maintained by @fregante. The feature was requested of GitHub through the GitHub Stars program.

Read more about forking a repository in the GitHub documentation.

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

See more

Previously, three aspects of repository forks caused friction to innersource collaboration and administration:

  1. Repositories could not be forked within a single organization.
  2. Repositories with internal visibility could not be forked to an organization.
  3. Enterprise owners lacked control over where repositories could be forked.

These obstacles have been addressed with the following new features. We’re always looking for new ways to improve repository collaboration and we welcome your ideas.

Fork a repository to the same organization as its parent

Previously, a repository could be forked only to a different organization or user account.

Now, a repository can be forked to the same organization as its parent repository, addressing situations where people are working in one organization and don’t want to fork a repository to a different organization or user account.

Fork internal repositories to enterprise organizations

Previously, when a repository with internal visibility was forked, the fork was automatically created in the person’s personal account space and its visibility was changed to private.

Now, people can fork an internal repository to an organization in the same enterprise, and the fork will retain its internal visibility. When forking an internal repository, you can choose which of the enterprise’s organizations should receive the fork – similar to forking a public repository, except that:

  1. The destination organizations will be limited to those within the enterprise of the parent repository.
  2. You will not be permitted to change the internal visibility of the fork while forking it.

Enterprise owners can limit where forks can be created

Previously, enterprise owners couldn’t restrict where repositories in the enterprise could be forked. This was important for them to keep confidential repositories from accidentally being forked to an exposed location.

Now, enterprise owners can control where enterprise members can fork repositories. Forking can be limited to preset combinations of enterprise organizations, the same organization as the parent repository, user accounts, and everywhere.

Image of enterprise settings for controlling where repositories can be forked

More information

Learn more about working with forks, or enforcing a policy for forking repositories, in the GitHub documentation.

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

See more

This beta feature allows repository admins to block Git pushes to a repository when they are potentially destructive.

Developers have had branches deleted from their repository when someone pushes changes with Git's --mirror option. The --mirror option is potentially destructive because it makes the remote repository exactly match the local clone. When run by accident, if the remote has more branches or different data than the local clone, many branch deletes and force-pushes can happen at the remote without any warning. This is often embarrassing for the one who pushed and a big challenge to recover from. Here's a real-world example: git push origin –mirror deleted all of my colleagues' branches.

This destructive situation can usually be identified by multiple branch or tag updates being pushed at the same time. The new beta feature being announced here allows admins to block potentially destructive pushes by limiting the number of branches and tags that can be updated by a single push. This can prevent or limit the loss of data.

To use this beta feature, click Settings in a repository that you are an admin of. Next, select General (the default, top-most tab). Then toggle the setting named Limit how many branches and tags can be updated in a single push as shown below. Set the number appropriately for your needs. We recommend the default maximum of 5 branch or tag updates allowed in one push. The minimum value is 2 since two branch updates are required by Git to rename a branch in a single push: delete branch and create branch. Lower numbers are more restrictive of which pushes are allowed, and higher numbers are less restrictive but have more potential for being destructive. As part of this feature's beta, we'd like to learn which number works best for you.

Image showing the setting labeled "Limit how many branches and tags can be updated in a single push."

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

See more