Алеандр

Без понимания того, как будут использоваться такие данные, что конкретно будет логироваться, будет ли это персонализироваться, есть ли в данных реальные персональные данные - ответа на вопрос не будет. Одно дело собирать статистику по тому, какие кнопки нажимают пользователи, чтобы потом провести A/B тестирование, например и, другое дело, если будут собираться и потом использоваться персонально данные о том, что вот этот верифицированный юзер искал это, находил это, делал вот это. Соответственно, исходя из задач, целей и инструментов можно будет дать ответ. А по исходным данным - ответ невозможен, только теория.

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

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

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

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

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

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

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

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

Вы путаете незнание или нежелание с отсутствующей необходимостью.

Расскажите, каким образом гит спасет в ситуации ТС, если я, как гипотетический исполнитель, на его сайт вкорячу бэкдор, при том, что это будет зашито внутрь десятка установленных плагинов с десятками тысяч строк кода? Ну, или как его спасет гит, когда ему нужно будет на его сервер поставить мне, как его гипотетическому админу сервера - нужные пакеты и расширения для php с рутовыми правами?

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

Да нет, это все как раз основные моменты )
Именно потому, что вы предлагаете не соответствующий инструмент для решения поставленной задачи. Инструмент, который ничего не решает, без "оговорок", которые отсутствуют в искомом ТЗ.

Он вообще никак не решает поставленную задачу. Мне сложно понять, как вы умудряетесь спорить с очевидным фактом.

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

Для этого нужно:
1) мониторить правки
2) верифицировать все правки
3) иметь знания и понимания в данных правках, т.е. быть нормального такого уровня программистом

Вот поставит исполнитель модуль в ВП, собственно о чем речь и идет в посте. Каким образом ТС должен верифицировать весь этот модуль? Вы же не предполагаете, что он сможет вычитать десятки тысяч строк кода чужого движка? Каким образом проконтролировать откуда именно в этой версии взялся этот модуль? Каким образом проконтролировать, был ли этот модуль целиком скачан и установлен "как есть", или в него внесли пару строк для дыры в сайте?

Это не правки на две строки. Это внесение модулей, данных в БД, в структуру. В некоторых случаях нужно давать доступ, что бы на выделенном сервере админ поставил нужные пакеты в систему, сконфигурировал веб и многое другое. А в этих задачах гит и близко не лежит. Это невозможно верифицировать, ни по задачам, ни в объемах.