Удалите вилочную зависимость GitHub-репозитория


206

Как я могу заставить GitHub забыть или отстранить, что мое репо изначально было форком другого проекта?

Я разработал проект в GitHub. Теперь я вижу «раздвоенный от чего бы то ни было». Родительский репозиторий «что бы то ни было» больше не поддерживается. Мне было разрешено продолжать использовать кодовую базу исходного репозитория для создания независимого репозитория.

Есть ли способ отсоединить мой проект от исходного хранилища?

Ответы:


175

Вы можете связаться со службой поддержки github и попросить их переключить ваш репозиторий в «обычный режим».

На этой странице , абзац «Комментирование было сделано в ответвлении», объясняется, что для переключения необходимо пройти поддержку. Таким образом, вполне вероятно, что не существует способа сделать это самостоятельно (если только вы не уничтожите и не создадите заново свой репозиторий, что объяснялось ранее ... если вы сделаете это, будьте осторожны, если у вас есть билеты или вики, прикрепленные к вашему проекту, так как они будут быть удаленным!).


31
Я могу подтвердить, что обращение в службу поддержки работает безупречно, плюс они часто отвечают в течение нескольких часов :-)
BenC

1
Связанная страница больше не содержит заявленной информации.
Кара Брайтвелл

3
@MattBrennan Страница изменилась, но последний раздел по-прежнему содержит: «Чтобы отсоединить ветвь и превратить ее в автономный репозиторий на GitHub.com или GitHub Enterprise, обратитесь в службу поддержки GitHub или к администратору своего сайта, соответственно».
Томас Мулард

1
Супер быстро .. они ответили мне через 1 час. Спасибо
myDoggyWritesCode

2
В Github Enterprise вы можете найти его сейчас под admin-> Collaboration-> Network, и в зависимости от вашего варианта использования вы должны использовать «Make Root», «Detach» или «Extract».
Куци

45

Вы можете скопировать разветвленный репозиторий в новый репозиторий (без зависимости вилки) из пользовательского интерфейса github, а затем удалить исходный разветвленный:

  • Войдите в GitHub
  • Выберите знак + в правом верхнем углу и импортируйте репозиторий .
  • Импортируйте ваш разветвленный репозиторий. Новый репозиторий не будет иметь зависимости от форка.
  • Удалите оригинальный, разветвленный репозиторий в настройках репозитория.

1
Это было проще всего, и это сработало для меня :). Очень умный.
Мокси

1
У кого-нибудь еще была проблема с функцией импорта "зависание"? Мой был в "Обнаружении системы контроля версий вашего проекта ..." в течение 5 часов. Я не уверен, стоит ли меня в очереди, или это фактическое зависание. Репо мало. Соблазн оставить его на ночь на всякий случай, если я в очереди.
Бенджамин Уэст,

Мне наконец стало любопытно и я просто нажал «отменить». Нажатие на отмену позволило ему пропустить обнаружение VCS и просто импортировать код / ​​коммиты / ветки и т. Д. Это имело место при импорте Github -> Github. Импорт может не зависнуть, если я приехал из другого VCS? Точно сказать не могу. Обратите также внимание на то, что после второго репо я должен был дважды отменить, чтобы он заработал. Если CLI копирует все те же данные, что может быть лучшим методом, но надеюсь, что это поможет другим, выбравшим этот маршрут.
Бенджамин Уэст

9
Просто чтобы быть ясным, этот подход не будет сохранять проблемы и тянуть запросы.
Голопот

Работает как шарм! Спасибо, ты спасатель! :)
всемог

44

Убедитесь, что у вас есть все важные ветви и теги в вашем локальном репо, удалите репозиторий github, заново создайте репозиторий обычными средствами (без разветвления) и верните локальный репозиторий обратно git push --all. Обратите внимание, что если у вас есть локальные ветви, которые вы не хотите публиковать, возможно, стоит создать временный чистый локальный клон для этой операции.

Тем не менее, это также избавит от вики и проблем. Поскольку вики фактически является собственным репозиторием, с ним можно обращаться аналогичным образом, клонируя его, а затем воссоздавая и отправляя. Адрес репо находится на странице Git Access в Вики ( git@github.com:user/repo.wiki.git).

Это оставляет проблемы. Их можно экспортировать через API , но, насколько мне известно, вы можете создавать проблемы и комментарии только с вашим человеком, поэтому их полный импорт невозможен.

Так что, если вам нужно сохранить проблемы, вы должны пройти поддержку github, как предлагает Томас Мулард.


В зависимости от того, сколько существует проблем, может быть возможно перенести их один за другим в новый репозиторий перед удалением из старого из Интернета ( help.github.com/en/github/managing-your-work-on- github /… ). Я предполагаю, что определенный человек может передавать более 100 выпусков в час - не весело, но для многих репозиториев выполнимо.
Сума

22

Я получил аналогичную проблему и в конечном итоге использовал эту страницу помощи github, чтобы решить ее. Я не возражал против вики и отслеживания проблем, так как это было для моего блога, использующего тему, любезно разработанную другим пользователем.

Чтобы отключить разветвленный репо и использовать его как свой собственный после нескольких коммитов, не теряя всей истории:

git clone --bare git@github.com:user/forked_repo.git

Создайте новое пустое хранилище new-repositoryна сайте GitHub . И нажмите на зеркальную версию:

cd user.github.com.git/

git push --mirror git@github.com:user/new-repository.git

Можно переименовать на GitHub, forked_repositoryс другим именем, чтобы сохранить его в качестве резервной копии и проверять обновления, если это необходимо. Или просто удалите его.

Переименование в new-repositoryисходное имя делает работу. Как побочный эффект, ваши коммиты теперь появляются в вашей истории.


11

Это относится только к GitHub Enterprise, а не к github.com

Вы вошли в учетную запись с правами администратора:

  1. Перейдите в репозиторий, который вам нужно отсоединить: https://<ghe url>/<org>/<repo>
  2. Нажмите на кнопку «Администратор сайта» в правом верхнем углу.
  3. Нажмите «Сотрудничество» в верхней строке меню
  4. Нажмите «Сеть» на левой панели
  5. Нажмите «Сделать рут» на панели «Структура сети».
  6. принимать

Это было проверено на GitHub Enterprise 2.9


В зависимости от вашего варианта использования может быть более подходящим «Detach» или «Extract». Я нахожу 'Make Root' немного странным, так как он в основном инвертирует текущее направление root-> child. (Github Enterprise 2.17)
Kutzi

10

Используя информацию от aurelien и Clayton , я смог сделать это с помощью следующего:

$ git clone --bare https://github.com/my/forked_repo.git
<delete forked_repo on GitHub>
<recreate repo on GitHub using same name>
$ cd forked_repo.git
$ git push --mirror

Вот документация дляgit clone --bare :

Сделайте пустой Git-репозиторий. То есть вместо создания <directory>и размещения административных файлов <directory>/.gitсоздайте <directory>сам $GIT_DIR. Это очевидно подразумевает -n, потому что некуда проверить рабочее дерево. Кроме того, заголовки веток на удаленном устройстве копируются непосредственно в соответствующие локальные заголовки ветвей, без привязки к ним refs/remotes/origin/. При использовании этой опции не создаются ни ветви удаленного отслеживания, ни связанные переменные конфигурации.

Вот документация дляgit push --mirror :

Вместо того , чтобы называть каждый реф толкать, указывает , что все рефов под refs/(которая включает в себя , но не ограничиваясь ими refs/heads/, refs/remotes/и refs/tags/) быть зеркальным в удаленном хранилище. Вновь созданные локальные ссылки будут отправлены на удаленный конец, локально обновленные ссылки будут принудительно обновлены на удаленном конце, а удаленные ссылки будут удалены с удаленного конца. Это значение по умолчанию, если remote.<remote>.mirrorзадан параметр конфигурации .

Примечание: как и другие gitответы на основе, это не будет копировать проблемы, которые не являются частью gitрепо, такие как вики и проблемы. Пер Тапио:

  • Вики - это отдельное git-репо, с которым можно работать аналогично для Тапио. Адрес: git@github.com:user/repo.wiki.git.
  • Проблемы можно экспортировать через GitHub API, но есть проблемы, воссоздающие их, поскольку они могут быть созданы только вашим пользователем, поэтому при импорте информация будет потеряна.
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.