Git: git fetch <branch>оканчивается на "xxx / xxx не похоже на git репозиторий" - PullRequest
0 голосов
/ 04 мая 2020

У меня проблемы с получением одной указанной c ветки из моего удаленного репо.

Если я делаю git ветка -a , вывод:

* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
  remotes/origin/release/2.0.23175_BBDDv10
...

и это нормально, все мои филиалы находятся в удаленном режиме, но как только я это сделаю

git fetch origin/release/2.0.23175_BBDDv10

я получу:

fatal: 'origin/release/2.0.23175_BBDDv10' does not appear to be a git repository
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Я владелец репо и у меня есть права на него, и если я сделаю это:

git remote -v

, то получится:

origin  https://xxxm@xxx.org/xxxxx/xxxxxxx.git (fetch)
origin  https://xxx@xxx.org/xxxxx/xxxxxxx.git (push)

Таким образом, «origin» указывает на то, где оно должно.

На данный момент Я застрял в состоянии получить одну указанную c ветку (еще не пробовал - все)

Что-то добавить на всякий случай:

Не уверен, что это может иметь какое-то отношение к этому, но на всякий случай и, если это поможет, могу добавить, что вчера я по ошибке нажал два очень больших файла, а затем удалил их оба после 'BFG Инструкции Repo Cleaner (https://rtyley.github.io/bfg-repo-cleaner/). За ними легко следить, и мои большие нежелательные файлы исчезли из локальной и удаленной / истории.

1 Ответ

0 голосов
/ 04 мая 2020

Команда git fetch принимает ноль, один или два или более аргументов:

  • git fetch: вызвать по умолчанию remote (обычно origin) ) и получить все
  • git fetch <em>remote</em>: вызвать с именем пульт дистанционного управления. Обычно вы должны использовать origin здесь.
  • git fetch <em>remote</em> <em>branch1 ... branchN</em>: вызвать с именем remote, и когда он перечисляет свои ветви, выберите только указанные c по имени ветви.

Вы пытаетесь использовать последнюю из этих трех форм, но делаете две отдельные ошибки:

  1. Вы необходимо предоставить имя пульта, в этом случае origin.
  2. * origin/* имена в ваш Git являются результатом вашего Git переименование их Git ответвлений , чтобы они не конфликтовали с именами ваших собственных ветвей.

Следовательно, вы хотите:

git fetch origin release/2.0.23175_BBDDv10

, который вызывает их Git, спрашивает их о их release/2.0.23175_BBDDv10 ветви и обновляет ваше origin/release/2.0.23175_BBDDv10 имя.

Если вы находите это запутанным, будьте уверены, это запутывает

Вся эта история о том, где косые черты go и когда, сбивают с толку, пока вы не поймете два вещи:

  • третье слово - обычная origin часть - не является ответвлением имени (master, release/2.0.23175_BBDDv10) и не является удаленным слежением имя (origin/master, origin/release/2.0.23175_BBDDv10). Это третий тип имени, удаленное имя.
  • Branch имена типа master и release/2.0.23175_BBDDv10 являются частными для каждого хранилища. Вы можете см. их с git fetch, но ваши git fetch переименовывают их, чтобы сделать ваши имена для удаленного слежения как origin/release/2.0.23175_BBDDv10.

Так Вы всегда должны помнить, чтобы спросить, когда у вас есть название филиала, , чье название филиала это: ваше или их? Ну, вы действительно должны помнить это, когда вы подключаете оба Gits, с git push, git fetch или git pull (который работает git fetch):

  • С git push у вас будет Git попросить их Git установить одно из их ответвлений . Вы отправите им некоторые коммиты по мере необходимости, тогда ваш Git спросит их: Пожалуйста, установите ______ (имя-ветви) на ______ (коммит-га sh ID), если все в порядке. (Использование git push --force превращает этот вежливый запрос в команду.)

  • С git fetch вы получите Git их имена branch получите любые новые коммиты из в свои собственные Git, а затем обновите свои имена для удаленного слежения (origin/*).

  • git pull работает git fetch, поэтому он делает то же самое, что и git fetch. (После успешного завершения git fetch git pull запускает вторую команду Git, обычно git merge. Обычно я советую избегать git pull, пока вы действительно не поймете, как git fetch и вторая Git команда работает, поскольку каждый отдельный шаг достаточно запутан, но это личный выбор, который вы должны сделать сами.)

В сторону

Вот простое правило для большинства Git пользователей: никогда не используйте git fetch --all.

(Это ничего не нарушает , но это не означает, что люди думают, что это означает.

(правило для продвинутых Git пользователей: , пока не используйте его . Подождите, нет, это правило для оптимизации . ?)

...