PS. Посмотрите вакансии разработчиков, от джуна до сеньора в требованиях владеть гитом, наверное это просто так, из за отсутствующей необходимости ))
Каким волшебным образом наличие красивой истории изменений решает задачу "волнует как бы такие работники еще чего-нить не "нахимичили" (бэкдоры, левые ссылки)"?На Пысы ответ тут: https://searchengines.guru/ru/forum/1076201/page8#comment_16892174
Я вас спрашиваю как гит решит задачу, а вы мне, по очереди, рассказываете как это поможет в виде бэкапа или отката сайта. Так задача то не в этом, бэкап и откат сайта, если что, можно и без гита сделать. В чем его еще помощь в конкретно обозначенной задаче?
Хотя, ладно, это и правда не имеет смысла. Поскольку все точно понимают, что это не решает задачи ТС, гит для других целей и в других объемах, но продолжаете бессмысленный спор. Буду умнее, прекращу спор первым.
Например сейчас у сайта есть какое то "состояние", оно фиксируется в гите, все следующие изменения с десятками тысяч строк кода бэкдора будут видны в гите и их всегда можно откатить к требуемому состоянию. Это же защитит ядро php от того чтобы туда не подложили бэкдор?При чем тут гит вообще? Тут примерно равноценно как гит поможет при беременности вашей подруги? Это не тот инструмент, чтобы защищать от тупости раздачи рута всем кому не лень.
Так в чем разница этого инструмента от бэкапа в данной задаче? Как она поможет, если ему залили шелл, установили левые ссылки? Ему гит об этом расскажет? Нет. Извините, просто как инструмент "откатить" в данном случае он не решает искомую задачу - ЗАЩИТИТЬСЯ от нежелательного кода, который накодили исполнители. От того, что код будет где-то дополнительно лежать и его можно будет откатить - заказчик вдруг читать и понимать этот код не научится.Вы сами в модулях или готовых движках хоть раз его весь вычитывали? Нет, если вы не соавтор. Никогда этого не делали и делать не будете. Вы будете рассчитывать на то, что это "официальная скачанная версия" и доверять тем, кто ее создал. В силу того, что эта версия была уже многими установлена и проблемы не выявлены. Так и тут. И неважно, с репы вы будете забирать этот код или через ftp/ssh/http - ничего не изменится.
Что значит защитит ядро? Я могу записать код бэка или левую ссылку в любую часть кода php, js и даже в базу, с вызовом нужного куска из базы или даже с удаленного сервера. Вы в жизни не найдете это при помощи гита.
"При чем тут гит вообще"Так я это и спрашиваю. При чем тут гит? ) При том, что вы предлагаете решения сродни вашему же предложению - не работающее для любой задачи, которая возникает в разработке сайта. А эти задачи не ограничиваются контролем версий сайта. Вы, по сути, предлагаете заказчику перечитывать код исполнителя. Так он с таким же успехом мог бы и сам тогда ставить все, что ему нужно, раз ему нужно все заново переделывать и пересчитывать за исполнителем.
"Это не тот инструмент" Так я вам об этом и говорю, гит - это НЕ тот инструмент. Гит - это хранилище и возможность отката версий, это инструмент разработчика. Но никак не заказчика для проверки кода. Он никак не защитит от необходимости выдать рут для выполнения задач. Он никак не защитит от изменений контента в базе. И, если вы этого никак не можете принять, понимая, что это не тот инструмент - я, пожалуй, больше настаивать не буду. А то Вы уже спорите со своими же утверждениями )
Я ничего не понимаю…
Сначала хотел согласиться, но это можно решить. Такие же модули поставить самому у себя и сравнить с тем, что наделано. Покажет все изменения.
То есть, вы опять возвращаетесь к тому, что владелец сайта должен быть программистом, но он НЕ должен им быть. Он должен у себя держать денвер? Зачем, если он не программист? И второе - вы предлагаете заказчику ВЫПОЛНИТЬ работу, за которую он заплатил программисту. А зачем ему тогда нанятый программер, если он должен "поставить самому у себя и сравнить". Даже, если гипотетически предположить, что заказчик хоть что-то понимает в программинге - он сам же, по вашему и должен это все повторять? ) Вы видели хотя бы раз заказчика, у которого стоит денвер, для примера, и он за программистом повторно все делает и сравнивает - правильно ли тот сделал? )
Для этого нужно:1) мониторить правки2) верифицировать все правки3) иметь знания и понимания в данных правках, т.е. быть нормального такого уровня программистомВот поставит исполнитель модуль в ВП, собственно о чем речь и идет в посте. Каким образом ТС должен верифицировать весь этот модуль? Вы же не предполагаете, что он сможет вычитать десятки тысяч строк кода чужого движка? Каким образом проконтролировать откуда именно в этой версии взялся этот модуль? Каким образом проконтролировать, был ли этот модуль целиком скачан и установлен "как есть", или в него внесли пару строк для дыры в сайте?
Это не правки на две строки. Это внесение модулей, данных в БД, в структуру. В некоторых случаях нужно давать доступ, что бы на выделенном сервере админ поставил нужные пакеты в систему, сконфигурировал веб и многое другое. А в этих задачах гит и близко не лежит. Это невозможно верифицировать, ни по задачам, ни в объемах.
Тематика решает. Например, крайне трудно сделать низкий процент отказов, если информация, которую ищет пользователь - достаточно краткая и сразу на видном месте. Пользователь зашел, увидел, запомнил, вышел. Его в целом больше ничего и не интересовало. Он, конечно, возможно еще вернется и там уже будет больше времени на сайте, но до того - это будет считаться отказом, хотя нужную информацию пользователь получил в полном объеме. Можно, конечно, искусственно заставлять его искать эту инфу, задерживая на сайте, но это спорный этический момент.
Посмотрел поддерживаемые проекты: 5-10%, 15-20%, 25-30%, 35% отказы. Вообще нет единой цифры. Вот выше 40-50%, наверное, это уже будет перебор. Ну или привет боты.
