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

Дайте наводку где про это почитать подробнее, чтобы разобраться.

Гитобои если на что и намекают, то на свою якобы крутизну (хотя в реальности всё наоборот). Повышают своё ЧСВ на сёрче, тк больше негде. Им совершено плевать кому они что говорят, не понимая не только ЦА но и само это понятие им не ведомо.

И ничего не надо забывать. Нужно уметь пользоваться инструментами. ФТП не исключение.

https://searchengines.guru/ru/forum/1032502

Так я вроде дал - Github/ Github actions - в инете полно информации как как настроить репозиторий, как добавить ключи в репо для деплоя, как настроить автоматический деплой. Я использую GitFlow. То есть у меня есть мастер ветка, мерж в которую автоматически запускает процесс деплоя на сервер, а разработка  ведется в feature ветках, например. 

Просто с этим стоит один раз разобраться и потом весь процесс просто и легко контролируется. Дал доступ работемку в репо, он написал код, сделал пулл-реквест. ты его проверил, одобрил, вмержил в мастер- ветку и все. Вот эти сказки любителей править на сервере про плагины и изменения в базах - полный бред. Я например разворачивал локальную среду полностью  идентичную серверу, плагины тоже ставил локально, потом пушил их со всем кодом и в админке только активировал. Некоторые плагины выносят из гита и ручками ставят на сервак. Лишняя работа и нет гарантии  что не положишь сайт но так тоже делают. 

Повторюсь - инфы в сети горы и стоит просто разобраться как облегчить себе жизнь.

Пришлось мне пару месяцев назад столкнуться с такими крутыми перцами. Они скачали себе на сервер копию сайта и работали с ней, а я тем временем спокойно работал с файлами на сервере, контент-менеджер публиковал новости, вносил изменения в каталог. И вот через неделю те грамотеи наконец закончили свою работу и обновили сайт. А руководитель проекта спрашивает меня: куда делись те изменения, что вносились на днях на сайт? Вот хохма-то была!

И кстати, замечу ещё, что подобные обновления очень затрудняют поиск уязвимостей при взломе сайта.

Если бы вы знали про Git, то у вас такой ситуации просто не было бы, так же как и этой истории.  Sly32 именно об этом и говорит. Если задействовать git, такие ситуации просто исключаются на корню.

По порядку разберем твои сказки:

Ни один специалист не закачивает никаких копий.

Сайт хранится в гите и это является первоисточником. Никто и никода не лезет на сервак руками
          Репозитарий
|                       |                       |
local_env dev_env prod_env
Это минимальная структура. Все изменения вносятся сначала в репо, тестируются локально, потом на дев энве и если все хорошо уже тогда деплоится все в прод.  При этом есть возможность всегда откатить версию на предыдущее состояние в любой момент.
Точно так же локально поднимается бэкап базы, он может отставать на какое-то время от прода, но это не влияет никак на разработку. 
Если вносятся изменения в БД - точно так же они проходят через миграции с возможностью всегда откатить состояние - таблицы, связи етс...

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

Забыл про поиск уязвимостей - можно поподробнее? В чем сложность? Вот я могу поделиться опытом, потому что писал систему, которая КАЖДЫЙ закачанный на сайт файл прогоняет через антивирусник, та еще работа но все получилось и теперь ей активно пользуется несколько американских дилеров и автоаукционов

Тут дело не только во мне. Это владелец сайта должен в корне менять всю работу с сайтом. Это очень непросто.
И главное - чтобы что? Есть сайт, есть CMS, специально разработанная для работы с этим сайтом, нахрена нужен дубль, с какой целью?

И да, такой ситуации не было бы, если бы те умники не решили обновить весь сайт, вместо того, что бы как положено внести свои изменения через штатную CMS. Это называется костылить на ровном месте.

Нужно уметь правильно пользоваться правильными инструментами, а не рассуждать с умным видом, наслушавшись всякой ерунды.

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

Вот именно для этого и придуман гит. не надо ни у кого спрашивать. Собственно гит это как раз и есть система контроля версий.