VoidVolker

Может. Вы со своим проектом можете работать в любом каталоге, в корне у вас основные файлы или вложены куда-то глубже - не имеет значения. Из вашего описания вообще не понятно что у вас не получается и что именно вы хотите сделать. Прочитайте ман сначала и просто следуйте по шагам инструкции как работать с гит: gitscm.org
Для работы с репозиторием нескольким разработчикам вам надо настроить рабочий процесс - выдать разработчикам права, настроить организацию/проект в вашем гите, организовать документацию и прочее. Типовой рабочий процесс - github flow. Для работы приложения на сервере настраиваются CI/CD процессы для автоматизации доставки и развёртывания проекта на сервере. Это тоже настраивается отдельно. В разных сервисах этот процесс отличается в деталях, но основные приципы везде одинаковые. Вам просто следует открыть руководство пользователя и прочитать о том, как сделать то, что вы хотите сделать.

Ставите на целевой сервер gitlab-runner и далее настраиваете деплой стандартным способом через gitlab ci/cd. Триггеры деплоя - стандартные PR в master ветку только мэйнтэйнером или администратором проекта/группы. Все остальные разработчики работают по стандартному github-flow режиму ну или какой у вас там рабочий процесс принят. В идеале, конечно, следует делать деплой через SSH, как вариант - прокинуть сервер гитлаба в закрытый контур через любой шифрованный тунель, а внутри контура настроить прямой доступ к нему по DNS.
Раз стоит цель настроить деплой без SSH в закрытый контур, то значит разрешение на такой деплой уже есть. А если нет - ну, что ж, это уже ответственность ТС и что делать в этом случае это уже совсем другой вопрос.

Вот так: https://habr.com/ru/articles/346066/

Поднять можно на любом. Вопрос только в юзабельности полученного решения.
UPD:

Свой гитлаб. Дело в том, что нужно минимизировать утечку, в т.ч. использованием внешних сервисов

В таком случае максимальную версию малинки с 8ГБ ОЗУ + SSD диск для ОС и данных или для данных можно подключить сетевое хранилище, например. Этого будет достаточно для работы сотни-двух пользователей. Больше - скорее всего будут лаги/тормоза.

Вот так: https://habr.com/ru/articles/346066/

Приобрести нужный объем, очевидно же: https://docs.github.com/ru/actions/using-github-ho...

Просто не надо делать еще одну отдельную копию репозитория. Файлы легко редактируются без дополнительного копирования в отдельный каталог. Скачать репозиторий с сервера - внести изменения - залить изменения на сервер. Все просто.

Правильное решение: нанять человека, который знает и умеет организовывать команду или как минимум есть опыт работы в команде и он знает как все должно быть. Без такого опыта - потратите кучу времени и денег на настройку и отладку всех требуемых процессов, а так же на набивание своих шишек. Опишу кратко как оно примерно должно быть - примерно, потому что везде есть свои ньюансы. Структура команды примерно такая: клиент <-> прожект менеджер <-> тим лид <=> тех. лид <=> разработчики, QA, дизайнеры и остальные. Далее, рабочий процесс организовывается с использованием системы управления задачами - например JIRA, Redmine и прочее, а так же по подходящей вам методологии. Для локальной разработки разворачивается локальная среда, в т.ч. фронтэнд, бэкэнд, БД - скриптом, в докере, в виртуалке и т.п. (как удобнее). Для тестирования и отладки в окружении близком к проду - разворачивается тестовый сервер для запуска и проведения тестов, и сервер разработки - для разворачивания текущего процесса разработки (можно и совмещать). Т.о., любой разработчик может спокойно локально провести разработку фичи, произвести пуш в дев ветку и увидеть результат на дев-сервере и результат тестов. Команда тестирования так же может проводить полноценное ручное тестирование на тестовом сервере или на сервере разработки. И, соответственно можно показывать клиенту прогресс разработки по конкретным задачам.

Проще всего сразу в конфиге SSH прописать ключ для хоста и тогда SSH сам использует этот ключ, когда гит его запустит. .ssh/config:

Host github.com
  IdentityFile ~/.ssh/id_ed25519

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

Host github.com-project-1
  HostName    = github.com
  IdentityFile ~/.ssh/project-1
Host github.com-project-2
  HostName    = github.com
  IdentityFile ~/.ssh/project-2

И соответственно для клонирования нужного репозитория использовать соответствующий для него хост. Т.о. все настройки ключей доступа для всех проектов будут в одном месте - в конфиге SSH, а не разбросаны по куче разных скриптов и файлов.

1. Установить гит
   
2. Добавить путь к нему в переменную окружения PATH (...\Git\cmd)
   
3. Перезагрузить систему
   

UPD: поставил гит на чистой системе - установщик сам добавил путь в переменную окружения. Так что достаточно просто поставить и все будет работать из коробки.