Невозможно ли создать подпапку somme в репо на сервере?
если я сделаю:
git push origin dev/master
все работает найти
но если я сделаю
git push origin dev/sub/master
я получил это:
error: 'refs/heads/dev/sub' exists; cannot create 'refs/heads/dev/sub/master'
Я проверил с помощью «git branch -r» и напрямую с помощью ssh, еще не создана папка dev / sub.
что случилось?
Ответы:
Это не папка , а ветка . (Ну, может быть где-то задействована папка / каталог, а может и нет, поскольку ссылки «упаковываются» и перестают существовать как файлы в каталогах.)
b
существует, указанная ветка неb/anything
может быть создана.dev/b
существует,dev/b/c
не может быть создана.Это внутреннее ограничение git. В этом конкретном случае у удаленного
origin
есть ветка с именемdev/sub
(независимо от того, есть она у вас или нет, важно, есть ли она у удаленного). Для того , чтобы создать наorigin
филиал имениdev/sub/master
, необходимо сначала удалить ветку с именемdev/sub
наorigin
:(Конечно, удаление этой ветки может удалить там что-то важное, поэтому убедитесь, что вы знаете, что делаете. Как правило, вы можете
git fetch origin
сначала записать ихdev/sub
как своиorigin/dev/sub
. Затем вы можете создать локальную ветку с именем,dev/renamed-sub
указывающую на ту же фиксацию , создатьdev/renamed-sub
на удаленном, удалить удаленныйdev/sub
, а затем создатьdev/sub/master
на удаленном.)Если вы можете войти в систему на удаленном компьютере (в системе, в
origin
которой размещена), вы можете войти в репозиторий и просто переименовать локальнуюdev/sub
ветку. (Основываясь на комментариях ниже, я подозреваю, что там также есть сломанный сценарий автоматического развертывания, который, вероятно, следует исправить, чтобы развертывать только «развертываемые» ветки, а не все, что отправляется. Но я просто предполагаю здесь.)источник
release/1.1
иrelease/1.2
сrelease/1.1/hofix/prevent-upload-bork
&release/1.1/hotfix/assure-user-of-competence
, и т. Д. И сообщение об ошибке ведет сюда (спасибо), вместо того, чтобы указывать ограничение! Но спасибо за простое и понятное объяснение.refs/tags/foo
и другое, иrefs/tags/foo/2
, например, он не смог бы этого сделать: ему нужно было бы реализовать собственное хранилище значений ключей. Я думаю, что Git в любом случае будет вынужден реализовать собственное хранилище ключей и значений, но я не знаю, снимут ли они это ограничение.git checkout -- master
означает проверку файл с именемmaster
, а не название филиала).Я был в состоянии, когда я не мог даже получить, потому что в моем репо была информация о несуществующих удаленных ветках, которые я даже не проверял. Я решил это, запустив комбинацию (спасибо @torek) из:
git branch -r
список локальных копий удаленных филиаловgit ls-remote
список удаленных ветокgit fetch --prune origin
обновлять локальные копии удаленных веток ( мне это не помогло )git remote prune origin
удалить информацию об удаленных удаленных ветках ( это сделал )источник
git remote prune origin
была единственной командой, которую я выполнил, чтобы исправить это состояние ошибки. Действительно вводящее в заблуждение сообщение - в моем случае я пытался нажать "release / 2.6.0", и я удалил весь каталог 'refs / remotes / origin / release *', но git продолжал жаловаться,error: update_ref failed for ref 'refs/remotes/origin/release/2.6.0': cannot lock ref 'refs/remotes/origin/release/2.6.0': 'refs/remotes/origin/release' exists; cannot create 'refs/remotes/origin/release/2.6.0'
когда я пытался нажать / тянуть / получитьДля меня ->
Ошибка =
Решение =
источник
Принят в настоящее время ответ не помог мне , потому что у меня не было реф на удаленный репозиторий для удаления - это чисто на мой местный! Итак, если вы оказались в такой ситуации, вот что делать:
Это проблема, с которой я столкнулся:
Я попробовал принять предложение ответа, но получил следующее:
Так что рефери даже не существовал
origin
- он явно просто болтался где-то в моем локальном репо. Итак, я побежал$ git remote show me
и произвел:Что затем прояснило решение:
С этим проблема исчезла:
источник
git remote prune origin
исправила ее. Благодаря!Попробуйте эту команду, чтобы исправить это:
для выполнения ряда служебных задач в текущем репозитории и удаления недоступных объектов (путем вызова
git prune
иgit fsck --unreachable
).Подробнее:
git help gc
иgit help prune
источник
Если ничего не помогает, убедитесь, что ваша система репо не имеет ограничений для имен веток. В моем случае вы могли создавать только ветки, которые начинаются с
SD-<number>
. Любое другое именование даст вам только общее:источник
Приведенный выше сценарий будет записывать ошибки в XXX-errors.log и исправлять их, автоматически создавая и запуская XXX-exist-tags-delete.sh из XXX-errors.log с помощью следующих команд:
источник
git remote prune origin
исправил проблему для меняисточник
Как пользователь Windows, ни одно из решений до сих пор не решило проблему для меня. Причина, по которой я видел эту ошибку, заключалась в том, что (используя имена веток OP) я пытался создать ветку,
dev/sub
но кто-то другой создал ветку с именем,Dev
и, как мы все знаем, в Windows есть файловая система без учета регистра.Поэтому, когда окна пытались раскрыть,
dev/sub
он сначала пытался создать папкуdev
, но не смог, потому чтоDev
уже существовал.Решением было удалить
Dev
ветку локально и удаленно с помощьюgit branch -d Dev && git push origin :Dev
. Аgit pull
после этого все нормально работало.Еще один урок в будущем: имена веток всегда должны быть в нижнем регистре, чтобы избежать подобных ошибок.
источник
Я понимаю, что на это уже дан ответ, но у меня это не сработало. Я не заботился о локальных изменениях, поскольку он уже был выдвинут, но у меня возникли проблемы с откатом. В моем случае мы изменились на полпути между наличием «исправления» в качестве ветки к системе папок с родительской папкой в качестве «исправления».
- hotfix ---- hotfix / 1234_bug ---- hotfix / 3456_bug
Итак, я получал следующую ошибку:
После поиска похожих ошибок я наконец нашел решение в ветке обсуждения здесь .
источник
источник
Переименуйте
dev/sub
вdev/sub/something
, затем вы можете создать веткуdev/sub/master
.источник