Поскольку уже существует существующий репозиторий, запуск

git config --bool core.bare true

в удаленном репозитории должен быть достаточным

Из документации core.bare

Если true ( bare = true), предполагается, что репозиторий будет голым без привязки рабочего каталога. Если это так, количество команд, требующих рабочего каталога, будет отключено, например git-add или git-merge (но вы сможете нажать на него).

Этот параметр автоматически догадывается git-clone или git-init при создании репозитория. По умолчанию репозиторий, который заканчивается на «/.git», считается не голым (bare = false), а все остальные репозитории считаются голыми (bare = true).

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

Сводка

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

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

Вскрытие проблемы

Когда ветвь проверяется, фиксация добавит новый фиксатор с головкой текущей ветви в качестве ее родительского элемента и переместит голову ветви в новую фиксацию.

So

A ← B
    ↑
[HEAD,branch1]

становится

A ← B ← C
        ↑
    [HEAD,branch1]

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

A ← B ← X
    ↑   ↑
[HEAD] [branch1]

Теперь пользователь больше не находится в ветке1, не попросив явно проверить другую ветку. Хуже того, пользователь теперь находится вне любой ветки, и любая новая фиксация будет просто болтаться:

      [HEAD]
        ↓
        C
      ↙
A ← B ← X
        ↑
       [branch1]

Гипотетически, если на данный момент пользователь проверяет другую ветку, тогда это оборванное сообщение становится честной игрой для сборщика мусора Git.

cd в каталог repo /, который вы нажимаете на удаленный компьютер, и введите

$ git config core.bare true

Для меня следующее трюк:

git config --global receive.denyCurrentBranch updateInstead

Я настроил диск F :, почти полностью, чтобы синхронизировать между моим рабочим столом Windows 10 и моим Windows 10, используя Git. Я закончил выполнение указанной выше команды на обеих машинах.

Сначала я поделился файловым диском F на компьютере. Затем я смог клонировать его на своем ноутбуке, запустив:

F: git clone 'file://///DESKTOP-PC/f'

К сожалению, все файлы оказались под «F: \ f \» на моем ноутбуке, а не под F: \ напрямую. Но я смог вырезать и вставить их вручную. После этого Git по-прежнему работал с нового места.

Затем я попытался внести некоторые изменения в файлы на ноутбуке, совершить их и вернуть их на рабочий стол. Это не сработало, пока я не запустил команду git config, упомянутую выше.

Обратите внимание, что я запускал все эти команды из Windows PowerShell на обеих машинах.

UPDATE: в некоторых случаях возникают проблемы с изменениями. Я, наконец, только начал набирать изменения, выполнив на компьютере следующее: я хочу вытащить последние фиксации:

git pull --all --prune

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