Случайно форкнул проект в GitHub, как теперь его удалить?
Случайно форкнул проект в GitHub. Проект x64dbg. Удалил у себя все файлы, но каталог master x64dbg остался. Как от него избавиться? И желательно от истории тоже.
Отслеживать
13.7k 12 12 золотых знаков 43 43 серебряных знака 75 75 бронзовых знаков
задан 10 сен 2015 в 1:38
user188653 user188653
2 ответа 2
Сортировка: Сброс на вариант по умолчанию
Форк — это самостоятельный репозиторий на GitHub, он создается для того, чтобы вы могли продолжить работу над проектом, сохранили всю историю изменений до форка и могли делать пулл-реквесты.
Если вам нужно только получить последнюю версию проекта, то форк для этого не нужен. Можно клонировать «родительский» репозиторий, причём достаточно будет неполного (неглубокого) клонирования.
Чтобы полностью удалить любой проект на GitHub (не обязательно форк):
- Перейдите на страницу проекта (репозитория).
- В правой части экрана нажмите на вкладку Settings в виде шестерёнки.
- В разделе Danger zone нажмите Delete this repository
- В текстовое поле введите полное название вашего репозитория
- Нажмите кнопку под текстовым полем для подтверждения.
Что происходит с вилками при удалении репозитория или изменении видимости?
Удаление репозитория или изменение его видимости влияет на вилки этого репозитория.
Warning:
- If you remove a person’s access to a private repository, any of their forks of that private repository are deleted. Local clones of the private repository are retained. If a team’s access to a private repository is revoked or a team with access to a private repository is deleted, and team members do not have access to the repository through another team, private forks of the repository will be deleted.
- You are responsible for ensuring that people who have lost access to a repository delete any confidential information or intellectual property.
- People with admin permissions to a private or internal repository can disallow forking of that repository, and organization owners can disallow forking of any private or internal repository in an organization. For more information, see «Managing the forking policy for your organization» and «Managing the forking policy for your repository.»
Deleting a private repository
When you delete a private repository, all of its private forks are also deleted.
Private forks and permissions
Private forks inherit the permissions structure of the upstream repository. This helps owners of private repositories maintain control over their code. For example, if the upstream repository is private and gives read/write access to a team, then the same team will have read/write access to any forks of the private upstream repository. Only team permissions (not individual permissions) are inherited by private forks.
Note: When you change base permissions for an organization, permissions for private forks are not automatically updated. For more information, see «Setting base permissions for an organization.»
Changing the visibility of an internal repository
If the policy for your enterprise permits forking, any fork of an internal repository will be private. If you change the visibility of an internal repository, any fork owned by an organization or personal account will remain private.
Deleting the internal repository
If you change the visibility of an internal repository and then delete the repository, the forks will continue to exist in a separate network.
Further reading
- «Setting repository visibility»
- «About forks»
- «Managing the forking policy for your repository»
- «Managing the forking policy for your organization»
- «Enforcing repository management policies in your enterprise»
Как обновить свой fork до последней редакции основного репозитория с помощью GitHub
Допустим, вы захотели внести изменения в чужой проект на Гитхабе. Для этого вы сделали fork чужого проекта, затем сделали клон этого fork’а к себе на компьютер, сделали изменения на компьютере, отправили сделанные изменения в свой репозиторий на Гитхаб и затем сделали Pull Requests в чужой репозиторий.
Предположим, что в чужом репозитории ваши изменения приняты, а вы, спустя некоторое время, снова решили внести некоторые изменения в этот проект. За это время другие разработчики также внесли некоторый вклад в этот проект. Поэтому, необходимо, что бы эти изменения подгрузились в ваш fork.
Самый простой способ загрузить актуальное состояние чужого репозитория, удалить свой fork и загрузить новый. Но, что если за это время вы тоже внесли в свой fork некоторые изменения. В этом случае удалив свой fork вы потеряете результаты своей работы.
Поэтому, чтобы не потерять результаты своей работы и при этом сделать свой fork актуальным, выполните следующие действия.
В своем аккаунте на GitHub откройте нужный вам репозиторий. Перейдите на вкладку Pull Requests.
Создайте новый реквест New pull request .
Появится сообщение There isn’t anything to compare (Тут не с чем сравнивать), нажмите ссылку switching the base .
Появятся отличия родительского и форкнутого проектов.
Нажмите кнопку Create pull request и введите название. Снова нажмите кнопку Create pull request . Вы перейдете в этот пул реквест.
Нажмите кнонку Merge pull request , а затем кнопку Confirm merge
Что происходит с вилками при удалении репозитория или изменении видимости?
Удаление репозитория или изменение его видимости влияет на вилки этого репозитория.
Warning:
- If you remove a person’s access to a private repository, any of their forks of that private repository are deleted. Local clones of the private repository are retained. If a team’s access to a private repository is revoked or a team with access to a private repository is deleted, and team members do not have access to the repository through another team, private forks of the repository will be deleted.
- You are responsible for ensuring that people who have lost access to a repository delete any confidential information or intellectual property.
- People with admin permissions to a private repository can disallow forking of that repository, and organization owners can disallow forking of any private repository in an organization. For more information, see «Managing the forking policy for your organization» and «Managing the forking policy for your repository.»
Deleting a private repository
When you delete a private repository, all of its private forks are also deleted.
Deleting a public repository
When you delete a public repository, one of the existing public forks is chosen to be the new upstream repository. All other repositories are forked off of this new upstream and subsequent pull requests go to this new upstream repository.
Private forks and permissions
Private forks inherit the permissions structure of the upstream repository. This helps owners of private repositories maintain control over their code. For example, if the upstream repository is private and gives read/write access to a team, then the same team will have read/write access to any forks of the private upstream repository. Only team permissions (not individual permissions) are inherited by private forks.
Note: When you change base permissions for an organization, permissions for private forks are not automatically updated. For more information, see «Setting base permissions for an organization.»
Changing a public repository to a private repository
If a public repository is made private, its public forks are split off into a new network. As with deleting a public repository, one of the existing public forks is chosen to be the new upstream repository and all other repositories are forked off of this new upstream. Subsequent pull requests go to this new upstream repository.
In other words, a public repository’s forks will remain public in their own separate repository network even after the upstream repository is made private. This allows the fork owners to continue to work and collaborate without interruption. If public forks were not moved into a separate network in this way, the owners of those forks would need to get the appropriate access permissions to pull changes from and submit pull requests to the (now private) upstream repository—even though they didn’t need those permissions before.
Deleting the private repository
If a public repository is made private and then deleted, its public forks will continue to exist in a separate network.
Changing a private repository to a public repository
When you change a private repository to public, all the commits in that repository, including any commits made in the repositories it was forked into, will be visible to everyone. However, the private forks will not automatically become public. Instead, each private fork will become a separate private repository and create its own independent network of repositories. Any new changes made to these networks will not be accessible from the original repository.
Deleting the public repository
If a private repository is made public and then deleted, its private forks will continue to exist as standalone private repositories in separate networks.
Further reading
- «Setting repository visibility»
- «About forks»
- «Managing the forking policy for your repository»
- «Managing the forking policy for your organization»
- «Enforcing repository management policies in your enterprise»