Ну щас. Прекрасно file_get_contents справляется с любыми задачами.
Дело не в file_get_contents, а в кривых руках. А ими за что не возьмись - всё криво будет.
Конечно же это неправда. Коммиты очень сложно уничтожить, так как это неизменяемые сущности по своей природе. Они лишь убираются с витрины и до них становится сложнее добраться.
Но если вам так дорог мусор, то вам ничто не мешает повесить на него тег и они останутся с вами навечно.
Зачем мне быть на стрёме? Гит никогда ничего не удаляет и все ходы записаны в журнале. Легким движением руки можно легко откатиться на момент до неудачного слияния и rebase.
Мне трудно представить такую ситуацию, что через месяц захочется покопаться в мусоре и снова пересобрать старые косяки. Обычно проблемы видны сразу.
Контроль версий происходит во всех ветках. А важные мы защищаем от удаления.
Так как rebase это именно удаление и пересоздания на новом месте. Если это делать с общей веткой, то придется всех коллег заставлять тоже удалить у себя эту ветку и создать на новом месте, куда она перекинется. Никто не будет этим страдать и поэтому защищают ветки.
Чтобы управлять историей, а не хранить её в виде археологических слоёв.
Rebase не «уничтожает» историю, а переписывает её так, чтобы она оставалась линейной и читаемой.
Git — не архив, а инструмент. И да, rebase — часть нормального рабочего процесса, если понимать, когда и зачем его применять.
Старые коммиты никуда не удаляются. Если что-то пошло не так, ветка возвращается в предыдущее состояние одной командой. Не надо тут вводить в заблуждение )))
Как раз наоборот: когда вы работаете с веткой один и ленитесь причесать историю через интерактивный rebase перед отправкой в вышестоящий репозиторий — вот тогда это действительно остаётся на вашей совести. ))
есть бэкенд на PHP, есть бизнес-требование перейти на JS
Vitsliputsli, вот когда ТС завалит ту элементарщину, с которой сюда явился - зовите его к себе и снабжайте документацией, погружайте во флоу... и вообще, благотворительность - это похвально, конечно.
а вы мальку сразу дадите рабочую задачу, чтобы сначала нужно было недельку поразбираться в проекте и документации?
1. производительности при переиспользовании подготовленного выражения
2. безопасности. в случае с EMULATE_PREPARES=true получаем не настоящее подготовленное выражение, а лишь экранирование, что-то близкое к использованию mysqli_real_escape_string() вокруг параметров
3. более корректной работы с типами данных
PDO::ATTR_EMULATE_PREPARES => falseclass ServiceLocator
{
public function getDB(): DB
{
...
}
}catch(PDOException $sql_connect_e)
{
echo ("Ошибка подключения к базе данных. SQL erorr: ". $sql_connect_e->getMessage() ."");
die();
};catch(PDOException $sql_connect_e)
{
echo ("Ошибка подключения к базе данных. SQL erorr: ". $sql_connect_e->getMessage() ."");
throw $sql_connect_e;
};Есть нюанс в том, что у меня несколько баз в колхозе и пользователю мне нужно показывать кто упал и почему упал.
throw $sql_connect_e;
Это предупреждение не имеет никакого отношения к работе с БД.
Прочитайте про отправку заголовков в http - и сделайте так, чтобы они устанавливались до отправки первых данных.
У вас вывод результата join нескольких таблиц, разумеется здесь не очевидно, что удалять или редактировать, т.к. это не одна таблица. Почему предупреждения в такой странной форме - это вопрос к приложению которое его выдало.