forks - GitHub Changelog

forks

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

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

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

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

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

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