smilingcheater

1. Таких конструкторов нет

2. Если у мультирегионального интернет магазина нет полмиллиона на Битрикс (с внедрением) то может и не нужен такой бизнес ?

Под ваше железо - больше чем 1660S/Ti смысла нет никакого, упор будет в старый процессор и память.

git используют не только для просмотра изменений некоторых файлов но и разворачивания проекта в другом месте, странно будет если развернется огрызок верно?)

Для joomla - нет. Получившийся репозиторий будет сложно (невозможно) использовать просто из за его гигантского размера. Единственный вариант - это какая-то застарелая, многолетне исправляемая в исходниках версия системы, которую просто страшно потерять. Надеюсь, это не такой случай :)
Вообще - помещать в СВОЙ репозиторий нужно только СВОИ файлы - те, которые не идут с инсталляции системы и плагинов, а добавлены вручную.
Нужно обязательно проверить, что репозиторий можно раскрутить в работоспособный проект с нуля, для этого служит композер или еще какие пакеты установки.

Как понять микросервисы?

Прочитать соответствующую книгу (а лучше ещё парочку про DDD или хотя бы посмотреть этот доклад)

Затем ответить на несколько вопросов:
1. Почему вы решили, что микросервисы что-то вам дадут?
2. Есть ли у вас настоящие причины для микросервисной архитектуры? (А именно: зоопарк технологий с невозможностью написать 99% на одном языке; более тысячи разработчиков; сложность выкатки монолита в виде часов прогонов CI/CD — тестов, билда, деплоя, стопоров выкатки в виде кучи проблем из-за разработчиков; вы такие же большие как гугл, убер, амазон и т.п.). Или вам просто нравится модное слово "микросервисы"?

Не получится создать хорошую микросервисную архитектуру без умения создать хороший модульный монолит. В этом случае вы получите не только все проблемы плохого монолита: высокая связанность, каскадные падения, долгий CI/CD; но и все проблемы микросервисов: их надо оркестрировать (у вас же есть команда, которая будет поддерживать инфраструктуру?); каждому микросервису нужно своё CI/CD (и хорошее); сеть может (и будет) лагать и обрываться; длительность запросов увеличится на порядок(ки) (особенно если выбрать какой-нибудь JSON-RPC over HTTP); нужно предусмотреть failover strategy (например, идемпотентные ретраи. Вы же уже знаете про correlation id, саги и что делать, если прилетел network error на запрос в другой сервис "списать 10 баксов"?) и circuit breakers; трейсы и логи, которые не пришлось бы искать по сотням .log файлов от каждого сервиса; бизнес-логика расползётся по разным микросервисам и нарушит SRP (пофиг, что нарушит, важнее то, что это починить будет сильно сложнее). Список можно продолжать долго.

Использовать подходы Git flow или Github flow

Поддержу Sand : берём Devops Roadmap и подтягиваем скиллы сверху вниз. Если хочется продолжать работать дальше в сетевом администрировании (вакансии Network Engineer с требованием знания Ansible/Salt были и 7 лет назад, только не у нас), то должны научиться раскатывать конфиги из гита и мониторить всё описанное хозяйство со сбором логов.

лол. Написать video streaming платформу с нуля на вебсокетах. Без обид, но одно это предложение уже говорит о том, что вы не сможете этого сделать. Стриминг не делается на tcp никогда. Вообще мало кто сможет такое сделать, а уж в одного так и подавно. Есть простое правило: если стриминг видео является не основой вашего бизнеса (как, например, у твича, юдеми, и тп), а просто каким-то доп функционалом, ни в коем случае не пишите свой велосипед. Берите vimeo и не усложняйте себе жизнь в 1000 раз.

Все что вы задали, это не вопросы по гиту. Это вопросы по SDLC - и на эти вопросы можете ответить только вы.
Гит это просто инструмент версионирования, а не доставки контента.
Тем более, что даже неизвестно сайт у вас крутится на виртуалке или на хостинге, и в принципе там git поставить есть возможность или нет.

Да, гитом тоже можно синхронизировать изменения между разными енвайрнментами, но вот те вопросы которые вы задаете - вы сами должны придумать удобный пайплайн и выбрать инструменты (git, scp, rsync, какой-нить CI/CD инструмент или что угодно)

В чём вопрос? Нужно диагностировать, почему падает сервер.

Раз всё настолько плохо, что даже SSH отваливается - дело не в нгинксе и не в РНР.

Второй вариант это хорошая попытка, но недостаточно полно реализованная. Писать надо хотя бы так

(function() { 
    foreach([true] as $condition) {
        $condition = ($condition) ? true : false; 
        while ($condition) {
            switch (true) {
                case ($this->inComplete(($oldStatus), ($newStatus))):
                case ($this->outComplete(($oldStatus), ($newStatus))):
                    ($this->action());
                    ($this->save());
            }
            break;
        }
    }
})();

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