Как отвязать проект от репозитория
Перейти к содержимому

Как отвязать проект от репозитория

Как отключить локальное репозиторий git от удаленного мастера

Как полностью отключить локальный репозиторий git от всех удаленных веток?

Я клонировал репозиторий git с github.com, но затем он был удален, и я не хочу, чтобы git сообщал о каких-либо изменениях, которые необходимо «подтолкнуть». Я пробовал погуглить, но думаю, что моя терминология неверна, и я ничего не нахожу.

Могу ли я просто удалить разделы [remote «origin»] и [branch «master»] из моего файла .git/config , или это нарушит мое локальное репо?

3 ответа

git remote rm origin должен работать.

Если вы удалите папку .git, она отключит ваше локальное репо от удаленного.

Чтобы удалить пульт: git remote remove origin

Чтобы добавить пульт: git remote add origin yourRemoteUrl и затем git push -u origin master

2.5 Основы Git — Работа с удалёнными репозиториями

Для того, чтобы внести вклад в какой-либо Git-проект, вам необходимо уметь работать с удалёнными репозиториями. Удалённые репозитории представляют собой версии вашего проекта, сохранённые в интернете или ещё где-то в сети. У вас может быть несколько удалённых репозиториев, каждый из которых может быть доступен для чтения или для чтения-записи. Взаимодействие с другими пользователями предполагает управление удалёнными репозиториями, а также отправку и получение данных из них. Управление репозиториями включает в себя как умение добавлять новые, так и умение удалять устаревшие репозитории, а также умение управлять различными удалёнными ветками, объявлять их отслеживаемыми или нет и так далее. В данном разделе мы рассмотрим некоторые из этих навыков.

Вполне возможно, что удалённый репозиторий будет находиться на том же компьютере, на котором работаете вы. Слово «удалённый» не означает, что репозиторий обязательно должен быть где-то в сети или Интернет, а значит только — где-то ещё. Работа с таким удалённым репозиторием подразумевает выполнение стандартных операций отправки и получения, как и с любым другим удалённым репозиторием.

Просмотр удалённых репозиториев

Для того, чтобы просмотреть список настроенных удалённых репозиториев, вы можете запустить команду git remote . Она выведет названия доступных удалённых репозиториев. Если вы клонировали репозиторий, то увидите как минимум origin — имя по умолчанию, которое Git даёт серверу, с которого производилось клонирование:

Вы можете также указать ключ -v , чтобы просмотреть адреса для чтения и записи, привязанные к репозиторию:

Если у вас больше одного удалённого репозитория, команда выведет их все. Например, для репозитория с несколькими настроенными удалёнными репозиториями в случае совместной работы нескольких пользователей, вывод команды может выглядеть примерно так:

Это означает, что мы можем легко получить изменения от любого из этих пользователей. Возможно, что некоторые из репозиториев доступны для записи и в них можно отправлять свои изменения, хотя вывод команды не даёт никакой информации о правах доступа.

Обратите внимание на разнообразие протоколов, используемых при указании адреса удалённого репозитория; подробнее мы рассмотрим протоколы в разделе Установка Git на сервер главы 4.

Добавление удалённых репозиториев

В предыдущих разделах мы уже упоминали и приводили примеры добавления удалённых репозиториев, сейчас рассмотрим эту операцию подробнее. Для того, чтобы добавить удалённый репозиторий и присвоить ему имя (shortname), просто выполните команду git remote add <shortname> <url> :

Теперь вместо указания полного пути вы можете использовать pb . Например, если вы хотите получить изменения, которые есть у Пола, но нету у вас, вы можете выполнить команду git fetch pb :

Ветка master из репозитория Пола сейчас доступна вам под именем pb/master . Вы можете слить её с одной из ваших веток или переключить на неё локальную ветку, чтобы просмотреть содержимое ветки Пола. Более подробно работа с ветками рассмотрена в главе Ветвление в Git.

Получение изменений из удалённого репозитория — Fetch и Pull

Как вы только что узнали, для получения данных из удалённых проектов, следует выполнить:

Данная команда связывается с указанным удалённым проектом и забирает все те данные проекта, которых у вас ещё нет. После того как вы выполнили команду, у вас должны появиться ссылки на все ветки из этого удалённого проекта, которые вы можете просмотреть или слить в любой момент.

Когда вы клонируете репозиторий, команда clone автоматически добавляет этот удалённый репозиторий под именем «origin». Таким образом, git fetch origin извлекает все наработки, отправленные на этот сервер после того, как вы его клонировали (или получили изменения с помощью fetch). Важно отметить, что команда git fetch забирает данные в ваш локальный репозиторий, но не сливает их с какими-либо вашими наработками и не модифицирует то, над чем вы работаете в данный момент. Вам необходимо вручную слить эти данные с вашими, когда вы будете готовы.

Если ветка настроена на отслеживание удалённой ветки (см. следующий раздел и главу Ветвление в Git чтобы получить больше информации), то вы можете использовать команду git pull чтобы автоматически получить изменения из удалённой ветки и слить их со своей текущей. Этот способ может для вас оказаться более простым или более удобным. К тому же, по умолчанию команда git clone автоматически настраивает вашу локальную ветку master на отслеживание удалённой ветки master на сервере, с которого вы клонировали репозиторий. Название веток может быть другим и зависит от ветки по умолчанию на сервере. Выполнение git pull , как правило, извлекает (fetch) данные с сервера, с которого вы изначально клонировали, и автоматически пытается слить (merge) их с кодом, над которым вы в данный момент работаете.

Начиная с версии 2.27, команда git pull выдаёт предупреждение, если настройка pull.rebase не установлена. Git будет выводить это предупреждение каждый раз пока настройка не будет установлена.

Если хотите использовать поведение Git по умолчанию (простое смещение вперёд если возможно — иначе создание коммита слияния): git config —global pull.rebase «false»

Если хотите использовать перебазирование при получении изменений: git config —global pull.rebase «true»

Отправка изменений в удаленный репозиторий (Push)

Когда вы хотите поделиться своими наработками, вам необходимо отправить их в удалённый репозиторий. Команда для этого действия простая: git push <remote-name> <branch-name> . Чтобы отправить вашу ветку master на сервер origin (повторимся, что клонирование обычно настраивает оба этих имени автоматически), вы можете выполнить следующую команду для отправки ваших коммитов:

Эта команда срабатывает только в случае, если вы клонировали с сервера, на котором у вас есть права на запись, и если никто другой с тех пор не выполнял команду push . Если вы и кто-то ещё одновременно клонируете, затем он выполняет команду push , а после него выполнить команду push попытаетесь вы, то ваш push точно будет отклонён. Вам придётся сначала получить изменения и объединить их с вашими и только после этого вам будет позволено выполнить push . Обратитесь к главе Ветвление в Git для более подробного описания, как отправлять изменения на удалённый сервер.

Просмотр удаленного репозитория

Если хотите получить побольше информации об одном из удалённых репозиториев, вы можете использовать команду git remote show <remote> . Выполнив эту команду с некоторым именем, например, origin , вы получите следующий результат:

Она выдаёт URL удалённого репозитория, а также информацию об отслеживаемых ветках. Эта команда любезно сообщает вам, что если вы, находясь на ветке master, выполните git pull , ветка master с удалённого сервера будет автоматически влита в вашу сразу после получения всех необходимых данных. Она также выдаёт список всех полученных ею ссылок.

Это был пример для простой ситуации и вы наверняка встречались с чем-то подобным. Однако, если вы используете Git более интенсивно, вы можете увидеть гораздо большее количество информации от git remote show :

Данная команда показывает какая именно локальная ветка будет отправлена на удалённый сервер по умолчанию при выполнении git push . Она также показывает, каких веток с удалённого сервера у вас ещё нет, какие ветки всё ещё есть у вас, но уже удалены на сервере, и для нескольких веток показано, какие удалённые ветки будут в них влиты при выполнении git pull .

Удаление и переименование удалённых репозиториев

Для переименования удалённого репозитория можно выполнить git remote rename . Например, если вы хотите переименовать pb в paul , вы можете это сделать при помощи git remote rename :

Стоит упомянуть, что это также изменит имена удалённых веток в вашем репозитории. То, к чему вы обращались как pb/master , теперь стало paul/master .

Если по какой-то причине вы хотите удалить удаленный репозиторий — вы сменили сервер или больше не используете определённое зеркало, или кто-то перестал вносить изменения — вы можете использовать git remote rm :

При удалении ссылки на удалённый репозиторий все отслеживаемые ветки и настройки, связанные с этим репозиторием, так же будут удалены.

Удалить форк-зависимость репозитория GitHub

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

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

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

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

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

Обновление от января 2022 г.:

Используйте виртуальный помощник чат-бота GitHub по адресу https://support.github.com/request/fork .

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

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

ПРИМЕЧАНИЕ. Этот подход не сохранит проблемы и запросы на вытягивание.

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

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

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

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

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

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

git clone —bare [email protected]:user/forked_repo.git

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

git push —mirror [email protected]:user/new-repository.git

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

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

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

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

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

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

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

Make a bare Git repository. That is, instead of creating <directory> and placing the administrative files in <directory>/.git , make the <directory> itself the $GIT_DIR . This obviously implies the -n because there is nowhere to check out the working tree. Also the branch heads at the remote are copied directly to corresponding local branch heads, without mapping them to refs/remotes/origin/ . When this option is used, neither remote-tracking branches nor the related configuration variables are created.

Instead of naming each ref to push, specifies that all refs under refs/ (which includes but is not limited to refs/heads/ , refs/remotes/ , and refs/tags/ ) be mirrored to the remote repository. Newly created local refs will be pushed to the remote end, locally updated refs will be force updated on the remote end, and deleted refs will be removed from the remote end. This is the default if the configuration option remote.<remote>.mirror is set.

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *