TL; DR: вы можете настроить общий Git так, чтобы receive.denyCurrentBranch был установлен на updateInstead. Убедитесь, что вы точно знаете, что это значит, прежде чем делать это! Скорее всего, вам следует настроить общий репозиторий как bare репозиторий. См. Также Каковы последствия использования receive.denyCurrentBranch в Git?
Long-ish
git init samplerepo создает новый пустой каталог с именем samplerepo, затемсоздает новый пустой репозиторий в этом каталоге, так что samplerepo является рабочим деревом для нового пустого репозитория. Этот новый пустой репозиторий не имеет коммитов и поэтому не имеет ветвей (пока). Каталог samplerepo будет содержать только один подкаталог, .git, содержащий собственное хранилище.
Создав этот пустой репозиторий, вы затем клонируете его. Процесс клонирования даст вам предупреждение о клонировании пустого репозитория, потому что различные вещи, как правило, немного странны при работе с пустыми репозиториями. В любом случае этот клон также не имеет ветвей, потому что имя ветви, подобное master, может существовать только при наличии хеш-идентификатора некоторого существующего действующего коммита. Пустой репозиторий не имеет коммитов.
Несмотря на отсутствие веток, пустой репозиторий по-прежнему на ветви. Это просто на ветке, которой не существует. Вот тут и возникает странность.
Далее вы создали файл в своем рабочем дереве в клоне, использовали git add, чтобы скопировать файл в индекс для этого клона, и запустили git commit. Это создало самый первый коммит в клоне, который теперь не пустой. Создание этого коммита позволило ветке master появиться, что она и сделала. (Теперь вы можете создать бесконечное количество дополнительных имен веток, если хотите: все должны обязательно идентифицировать этот существующий коммит.)
Наконец, вы сказали своему Git связаться с другим Git в общей области. , //networkdrive/myrepo/samplegitrepo. 1 Ваш Git дал этому другому Git этот единственный сделанный вами коммит, который этот Git сохранил в этом хранилище - тот, что находится на общем диске. Затем ваш Git попросил Git создать или обновить имя ветки master, чтобы идентифицировать один коммит. Так оно и было.
Создание коммита в другом Git не влияло на рабочее дерево этого Git. Это нормальное поведение репозитория Git: добавление в него новых коммитов через git push не влияет на его дерево работы. На самом деле, вообще, добавление новых коммитов в ветку, которую он проверил, обычно полностью отрицается . Причина, по которой это было разрешено здесь, заключается в том, что проверенная ветвь - ее master - не существует, по той же причине, по которой изначально master вашего клона не существовало.
Теперь, когда ветвь существует , будущие попытки нажать master будут отклонены из-за сброса receive.denyCurrentBranch, что приведет к тому же поведению, что и при установке true. Существует много дискуссий в различных ответах на Каковы последствия использования receive.denyCurrentBranch в Git? Вы должны прочитать его.
1 Более типично, вы бы связались с целым отдельным хостом по некоторому URL https:// или ssh://. Тогда у другого хоста будет способ аутентифицировать вас и решить, предоставить ли вам доступ к хранилищу Git там. В этом случае ваш собственный Git запускает второй экземпляр Git для работы на общем диске. Это позволяет Git продолжать работать так, как будто вы разговариваете с другой машиной, даже если он просто говорит с другой копией, работающей на общем диске. Ваша ОС автоматически выполняет аутентификацию через общий диск.
Вот где материал --shared становится важным, если вы планируете позволить другим пользователям на другом компьютере позволить их ОС позаботиться о совместном доступе. Ориентированная на Linux настройка Git --shared=true или --shared=group - это то, к чему --shared по умолчанию - зависит от групповых разрешений в стиле Linux. Вы показываете различные пути Windows, и разрешения Windows, как правило, сильно отличаются от Linux, так что это может не достичь того, чего вы хотите. Я не "делаю" Windows, поэтому не знаю, как выполнить то, что вы хотите, но это стоит некоторого внимания.