Как организовать работу с git без клонирования сайта на локальный компьютер?

Question

[Сергей Смагин]

Запустили на продакшене pet проект (сервер VPS). Работа производится с разными разработчиками сугубо через фриланс.
Есть необходимость грамотно организовать дальнейшую доработку сайта через контроль версий. Насколько я понимаю работа через git/github подразумевает клонирование сайта на локальный комп разработчика. Но учитывая, что работа через фриланс и доработки носят не масштабный характер (без заключения договоров) не хотелось бы, чтобы каждый разработчик себе клонировал сайт.
Поэтому у меня есть вопрос как грамотно организовать дальнейшую доработку сайта?
Какие требования:
1. работа над сайтом без копирования его на локальный комп разработчика (в облаке может как-то можно???)
2. тестирование не на продакшне (то есть сначала надо чтобы на поддомен или клон сайта на том же vps только, как это правильно???)
Над проектом не будет работать больше 1 разработчика одновременно
Сейчас же я даю доступ тому или иному разработчику через SFTP, он сам смотрит, куда нужно вносить изменения и сразу заливает файл на рабочий (продашн) сразу. Естественно это дичь, поэтому нужно организовать нормально процесс.

Comments

[iBird Rose]

а что мешает стороннему разработчику в нынешней ситуации через sftp скопировать все файлы сайта?

[Сергей Смагин]

iBird Rose, ну как раз-таки ничего не мешает. а хотелось бы, чтобы не было все так просто "взял да и скопировал", так как работа с не всегда проверенными людьми.

[Aлександр]

Сережа, если люди не проверенные - очень опасно довать им доступ к продакшен или к репозиторию

[Олег]

Вижу три вещи, за которые Вы переживаете.
а) пароли и прочее в коде проекта
б) ценность данных в базе данных
в) сам код сайта

По паролям и всяким ключам к апи. Делаете две директории конфигов (рабочее / тестовое окружение)
В репозитории реальных конфигов не должно быть.

Вместо реальной базы переходите на технологию миграций. Разрабы пусть тестовую версию из скриптов локально развертывают.

Тут уже никак.

[Сергей Смагин]

Олег, спасибо

[Сергей Смагин]

Олег, спасибо за комментарий!

Answer 1

[Иван Кулаков]

Не, ну конечно можно прямо на гитхабе редактировать файлы, и делать коммиты, но это дичь полная.
По-моему, лучше сделать так:
1. Делаете репозиторий приватным, создаете в нем ветку dev
2. Проверенному человеку даете доступ через collaborators
3. Человек редактирует код в ветке dev и делает пулл реквест (редактируя через клон или сразу на гитхабе, как сам решит)
4. После тестов CI в workflow вы этот пулл реквест мёржите в ветку master/main
5. После мёржа запускается workflow CD и деплоится на продакшн на ваш VPS.

В целом, такая концепция распространена))

Comments

[Сергей Смагин]

спасибо за развернутый по пунктам ответ!

[Иван Кулаков]

Сережа, рад помочь, не забудьте отметить решением)

Answer 2

[Aлександр]

Почитайте что такое devops и CI/CD. Также поищите в инете что значит stage enviroment.

Gitlabs, в прочем как и Github имееют для CI/CD pipelines

Так же я бы рекомендовал, внедрить Git Branching Model. Это когда продакшен код и код который пушит разработчик находится в разных ветках. Код из ветки разработки переносится в продакшен только во время релиза, когда все оттестировано и работает. Какой- нибудь нерадивый разраб с умыслом или без может одним коммитом угробить весь продакшен.

В 2-х словах так не описать. В целом процесс выглядит Разработчик делает push в репозиторий. По этому событию запускается pipeline которая строит версию сайта из этого репозитория и выкатывает ее на stage окружение. Если пойти дальше - можно настроить автоматической тестирование перед тем как версия выкатывается на stage окружение.

Comments

[Сергей Смагин]

спасибо за наводку, я почитаю!