Я хотел бы знать, практично или даже разумно связывать репозитории git вместе. Ситуация, о которой я думаю, заключается в том, что у меня есть репозитории git на удаленном веб-сервере, где главная ветвь - это та, которая указывает на отдельную структуру веб-корневого веб-сайта разработки, которую все мои веб-разработчики могут отправлять свои файлы для тестирования. После того, как все пройдет проверку и веб-сайт по-прежнему будет функционировать должным образом в процессе разработки, менеджер проверит изменения, а затем использует git из структуры разработки для фиксации изменений в производственных репозиториях на том же сервере, тем самым сделав изменения живыми.
Проблема, которую я пытаюсь решить, заключается в том, что разработчики в настоящее время имеют доступ к действующему веб-сайту и вносят в него простые изменения. Иногда эти изменения нарушают работу веб-сайта, особенно если они никогда не проходят проверку. Я бы хотел, чтобы все было направлено через ветку разработки, заставило его пройти тестирование, и только затем передать его в производственную версию веб-сайта. Я не ожидаю, что это полностью решит мою проблему, но я надеюсь, что это значительно уменьшит количество глупых ошибок, которые делают его в продакшене.
Я также не хочу вставлять лишний уровень сложности, который не нужен, поэтому мой вопрос о том, разумно ли это делать. В настоящее время все разработчики используют sftp для отправки файлов, поэтому использование git может встретить некоторое сопротивление, но мне очень нравится идея управления версиями и отката к заведомо исправному состоянию, если что-то ускользнет.
Поэтому мне нужен совет по использованию git таким образом или альтернативные методы того, как другие справляются с этим сценарием.
Как упоминалось в комментарии @EEAA, вам почти наверняка нужна система CI / CD, а не цепочка репозиториев git. Я совсем недавно исследовал go.cd, и он имеет хорошую поддержку для описываемых вами развертываний на основе утверждения, через веб-интерфейс, вместо того, чтобы требовать от людей извлечения / отправки кода.
Я твердо верю (как человек, занимающийся техническим менеджментом) в идею о том, что менеджер должен доверять своим разработчикам, чтобы они не делали глупостей, и если разработчики делают глупые вещи, то виноват менеджер - либо потому, что соответствующие ожидания не были введены в действие, или потому что были наняты не те люди. Если разработчики продвигают сломанный код вживую, менеджеру необходимо выяснить, почему разработчики это делают, и решить который проблема, не мешать разработчикам публиковать код вживую.