Как доверить управление сайтом на движке Wordpress работнику?

Например сейчас у сайта есть какое то "состояние", оно фиксируется в гите, все следующие изменения с десятками тысяч строк кода бэкдора будут видны в гите и их всегда можно откатить к требуемому состоянию. Тем самым это поможет ТС. Плюс гит это не просто заливка изменений на сервер, у гита, как правило, есть мастер ветка, она развернута на сервере (проде), любые изменения делаются через мерж/пулл реквест в эту ветку, а в этом реквесте видны все изменения которые будут сделаны в этой мастер ветке, например вот какой то пул реквест с утечкой памяти в fpm в ядре php, видно в каком файле какие изменения вносятся и кем. Это же защитит ядро php от того чтобы туда не подложили бэкдор?

При чем тут гит вообще? Тут примерно равноценно как гит поможет при беременности вашей подруги? Это не тот инструмент, чтобы защищать от тупости раздачи рута всем кому не лень.

Это не отсутствующая необходимость, гитом можно пользоваться даже локально или прям на сервере редактируя по ftp, я практически уверен, что у большинства если зайти на проект там будет в файловой что то типа

- index.php
- index1.php
- index2.php
- style.css
- style.new.css
- style.old.css

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

PS. Посмотрите вакансии разработчиков, от джуна до сеньора в требованиях владеть гитом, наверное это просто так, из за отсутствующей необходимости ))

Ну то есть вы, как и Sly32, предлагаете работать так:
- развернуть на тестировочном сервере копию сайта
- после внесения изменений в эту копию переносить изменения в гит
- после этого через гит переносить изменения на рабочий сайт
- делать дамп базы данных и обновлять БД рабочего сайта.

Верно я понял, или это не так?

Так в чем разница этого инструмента от бэкапа в данной задаче? Как она поможет, если ему залили шелл, установили левые ссылки? Ему гит об этом расскажет? Нет. Извините, просто как инструмент "откатить" в данном случае он не решает искомую задачу - ЗАЩИТИТЬСЯ от нежелательного кода, который накодили исполнители. От того, что код будет где-то дополнительно лежать и его можно будет откатить - заказчик вдруг читать и понимать этот код не научится.

Вы сами в модулях или готовых движках хоть раз его весь вычитывали? Нет, если вы не соавтор. Никогда этого не делали и делать не будете. Вы будете рассчитывать на то, что это "официальная скачанная версия" и доверять тем, кто ее создал. В силу того, что эта версия была уже многими установлена и проблемы не выявлены. Так и тут. И неважно, с репы вы будете забирать этот код или через ftp/ssh/http - ничего не изменится.

Что значит защитит ядро? Я могу записать код бэка или левую ссылку в любую часть кода php, js и даже в базу, с вызовом нужного куска из базы или даже с удаленного сервера. Вы в жизни не найдете это при помощи гита.

"При чем тут гит вообще"
Так я это и спрашиваю. При чем тут гит? ) При том, что вы предлагаете решения сродни вашему же предложению - не работающее для любой задачи, которая возникает в разработке сайта. А эти задачи не ограничиваются контролем версий сайта. Вы, по сути, предлагаете заказчику перечитывать код исполнителя. Так он с таким же успехом мог бы и сам тогда ставить все, что ему нужно, раз ему нужно все заново переделывать и пересчитывать за исполнителем.

"Это не тот инструмент"
Так я вам об этом и говорю, гит - это НЕ тот инструмент. Гит - это хранилище и возможность отката версий, это инструмент разработчика. Но никак не заказчика для проверки кода. Он никак не защитит от необходимости выдать рут для выполнения задач. Он никак не защитит от изменений контента в базе. И, если вы этого никак не можете принять, понимая, что это не тот инструмент - я, пожалуй, больше настаивать не буду. А то Вы уже спорите со своими же утверждениями )

Каким волшебным образом наличие красивой истории изменений решает задачу "волнует как бы такие работники еще чего-нить не "нахимичили" (бэкдоры, левые ссылки)"?
На Пысы ответ тут: https://searchengines.guru/ru/forum/1076201/page8#comment_16892174

Я вас спрашиваю как гит решит задачу, а вы мне, по очереди, рассказываете как это поможет в виде бэкапа или отката сайта. Так задача то не в этом, бэкап и откат сайта, если что, можно и без гита сделать. В чем его еще помощь в конкретно обозначенной задаче?

Хотя, ладно, это и правда не имеет смысла. Поскольку все точно понимают, что это не решает задачи ТС, гит для других целей и в других объемах, но продолжаете бессмысленный спор. Буду умнее, прекращу спор первым.

Не распыляйтесь. Это бессмысленно. Вряд ли можно доказать что-то тем, кто может только критиковать, без предложения альтернатив.

О чем вообще говорить, если на прямое решение возможной проблемы говорят, что ТС не программист, разбираться не обязан?

На эту тему не было бы спора, если бы ты понимал КАК гит работает. Но я честно в это сомневаюсь. Как и тут есть понимание - 

Налицо явное непонимание работы. 

В гит НЕ надо ничего переносить! Он отслеживает ЛЮБОЕ изменение состояний системы real-time. Ты добавил слэш - он это тут же зафиксировал. Commit просто фиксирует пул изменений. Как поможет решить задачу ТС - об этом уже не только лишь все написали - есть интсрументы для аострочного сравнения кода, в отличие от бэкапа. Даже неспециалист может посмотреть, какие изменения и когда были внесены работником. Разве не об этом суть топика? Как защитить - тоже все просто - ограничить доступ, например запретить мерж в мастера, настроить работу только через форки И так далее.

Советую очень не вешать ярлыки гитбоев а попробовать разобраться. 
Это как с докер. Нет у тебя ресурсов чтоб

Ну так сделай локально полную копию сервера. Это не опенсервер - тут ты можешь делать как хочешь все - версия линуеса/винды(для извращенцев) конфигурация, базы данных, кэш - у тебя локально будет все соответствовать и не придется думать - а заработает ли это на сайте?

Аргументов  толковых против я так и не услышал. Одно нежелание разобраться как это работает и внедрить. Рельно давно уже не видел вакансий, где не требовалось бы знание, хотя бы базовое гита/hg/svn

Сказки. Причем без малейших аргументов. Могу запросто расписать флоу, который ни один студент не потянет и серьезная контора просто не станет браться за написание ерунды. Да и отличия там будут грандиозные.

Я уже раз пять спрашивал здесь, как работать на реальном сайте, а не в фантазиях, но ответа так и не получил. Сплошное надувание щёк, и ничего более.

Где я должен "добавить слэш"? Вот у меня есть реальный сайт, на котором я должен установить плагин. Как это отследит твой гит?

А ничего, что существует удалённый репозиторий, где вроде как сохраняются изменения, сделанные всеми участниками проекта? А то твой единомышленник, br.almighty, даже не подозревает о существовании такового.

Ты честно не понимаешь как гит работает? Ты же вроде писал что знаешь и не используешь просто за ненадобностью! Я реально в шоке. Так вот - гит будет отслеживать ВСЕ изменения! Ты просто настраиваешь директорию, в которой лежит на хосте сайт и все. Или ты думаешь: что плагин это какая-то магия? Это просто код))) И гит прекрасно его увидит. Я уже писал, что плагины я устанавливал локально, тестировал и деплоил их уже как код сайта, в админке только активировал. На хостинге я не делал НИЧЕГО руками! Так же и обновления: локалка - тест - деплой и никак иначе. 

Почитай уже как гит работает, нет там волшебства.

Да он как раз и понимает прекрасно как это все работает. Почитай про форки и бранчи в гите и как все собирается в релизы - если осилишь, может отпадут вопросы)))

CMS - это не нечто уникальное, активация плагинов через БД - известная практика. Она по механизму скорее всего соответствует хорошо известному разработчикам мезанизу feature toggle -  когда весь новый код прячется под условие, определенный ключ, который вычитывается из хранилища и выполняет или нет определенный участок кода. Ксли что-то пошло не так тв просто отключаешь и все. Ничего особенного