VoidVolker

Поднять можно на любом. Вопрос только в юзабельности полученного решения.
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: поставил гит на чистой системе - установщик сам добавил путь в переменную окружения. Так что достаточно просто поставить и все будет работать из коробки.

Дело в изменении даты записи в файл. Изменилась дата файла — гит считает, что файл изменился, даже если ничего в нем не изменилось.