Роми

RTFM

И со слотами, и без слотов, и как только не пытался уже.

Попытайтесь открыть документацию (а совсем круто будет, если заведёте себе привычку читать документацию постоянно). Там в разделе, посвящённом компоненту таблицы, есть пример, который так и называется - "multiple select".

Кода я вхожу в контейнер:
docker-compose up -d nginx mysql phpmyadmin

Это команда запуска контейнеров, она не позволяет никуда входить. Соответственно, which mysql вы, судя по всему, выполняете на хосте, а не в контейнере.

не видит файл с дампом

А где он лежит-то? И где в его ищете?

как там внешние пути соотносятся с внутренними

Вот так они соотносятся: https://github.com/laradock/laradock/blob/27f50abe....
Соответственно, туда дамп кладите и там его ищите. Ну или добавьте свой volume с какими хотите путями (судя по вопросу, этот путь вам не подходит).

Может, вы уже как-то всё же документацию почитаете, разберётесь, что делаете? Не первый месяц ведь сюда ходите с, в принципе, элементарными вопросами.

Задача решается созданием вычисляемого поля. Один из вариантов:

CREATE TABLE test (
    id_1 INT,
    id_2 INT,
    ids VARCHAR(255) AS (CONCAT(LEAST(id_1, id_2), ' ', GREATEST(id_1, id_2))) STORED,
    PRIMARY KEY(ids),
    CHECK (id_1 <> id_2)
);

DEMO

В принципе, можно и триггером... но менее надёжно.

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

Хорошо подходит там, где мы выстраиваем pipe или reduce, для описания которых ФП подход является наиболее выразительным и лаконичным. Не знаком с архитектурой Ларавел, но могу предположить, что для авторизации прорисовывается некоторый пайплайн, где можно выполнять разные пайпы или фильтры для првоерки/валидации или чего-либо именно с таким подходом и это более лаконично...

Пример:

public function add(callable $pipe) {
    //..
}

...

$pipeline = (new Pipeline)
     ->add(fn() => true)
     ->add(fn(bool $enabled) =>'Maks enabled')
     ->add(new MaksHandler()) // тут класс с методом __invoke и работает как анонимка
;

Или я чего-то тут не учитываю, что нужно учесть?

Обычно, в master/main ветке находится стабильный код, который протестирован, и его можно в прод заливать.
Так что если пишешь 1 - вполне можно оставить разделение master-develop
А вот если нужно одновременно работать над несколькими фичами (например в одной ветке - основная фича, в другой - просто обновляешь фреймворки), то лучше всё-таки делить.

Скорее всего pull предлагает сделать не после push, а после нажатия кнопки синхронизации в VSCode.
До того как собственно сделает сам push, спрашивает «а не хотите ли сначала обновиться?»
Более точный ответ мы увидим в консоли, смотри там что происходит.
Скачивать ветку заново сразу после отправки действительно нет никакого смысла.

Это называется словом "трассировка".
Пошаговое выполнение программы средствами IDE, с контролем значений всех переменных.
На определенной строке программы ставится специальная метка, брекпойнт.
Дойдя до неё, интерпретация кода остановится, и дальше можно будет выполнять каждую строчку по одной, видя при этом значения всех переменных. Причем именно всех, а не только тех, которые ты добавил в дд.
То есть трассировка средствами IDE удобнее, быстрее и даёт больше информации, чем ручное колупание с вардамп.

В РНР этим занимается xdebug в связке с IDE

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

Это точно об X-debug.

Умение им пользоваться будет полезным в использовании незнакомого вам кода. Большинство ошибок можно найти данным инструментом более быстро, чем расставлять везде dd(). Вам нужно поставить одну точку, а дальше полный набор отладки.

Но мне не очень понятно зачем отлаживать свой код. Если код написан читаемо, то отлаживать его нет необходимости - достаточно покрыть его тестами. Даже если возникнет какая-то ошибка, то найти её можно быстро. Я ещё ни разу не пользовался X-debug для отладки именно своего кода. Код читаем и ошибка находится быстро. Более того, дошёл до того, что даже браузер не открываю, так как занимаюсь только backend частью. Мы недавно сдали проект с хорошим кодом и на демо-версии не было ни одной 500 ошибки, а покрытие тестов было всего 35%.

Поэтому тесты+читаемый код может вообще избавить вас от необходимости настройки данного инструмента. Разве что нарвётесь на какой-то баг библиотеки. Вот тогда и придётся «расчехлять» данный инструмент.

Это о xdebug

1. IDE понимает Symfony без дополнительных плагинов, на Laravel без плагинов писать не удобно.
2. Вам придется повсеместно использовать внедрение зависимостей через конструктор. Вы это и в Laravel могли делать, но там и другие варианты были (фасады, app('service_name')). В Symfony только DI и только через конструктор.
3. В Symfony вам придется пробрасывать данные к месту использования через аргументы. В Laravel вы могли достучаться до любого компонента при помощи статических фасадов и функций, вызвав их в любом произвольном месте, например могли вызвать request() где-то в модельке. В Symfony нужно будет пробросить данные запроса из контроллера через аргументы по всему стеку вызовов.
4. В Symfony вы перестанете наследовать свои классы от классов Symfony (за рядом исключений).
5. Конфиги вы будите писать в yaml (в этом есть плюсы и минусы)
6. В Symfony нет middleware (возможно есть какие-то сторонние пакеты, которые их реализуют, но обычно такой подход при разработки на Symfony не применяется)
7. В Symfony вы перестанtте манипулировать айдишниками и начнете манипулировать сущностями. То есть код $order->user_id = $user->id; превратится в $order->setUser($user);
8. Больше не надо писать миграции вручную, доктрина автоматически их сгенерирует.

Ну это то, что вспомнил, так то отличий может и больше будет.

1. Прежде всего нужно понимать, что любой Framework, в руках хорошего разработчика будет жить долго и хорошо.
   
2. Framework — это инфраструктура. Framework не предоставляет Вам готовый код и не задаёт архитектуру, он предоставляет Вам низкоуровневые инструменты или их быструю интеграцию, в которых нет необходимости писать с нуля под каждый проект. Хотя, ради практики, было бы не плохо попробовать это сделать, чтобы разобраться в данном вопросе, но сейчас не об этом. Исходя из этого Ваш код должен быть независим от какого-либо Фреймворка. Устарел Yii2 framework —поменяли контроллеры, немного инфраструктуры и код работает уже на Symfony или Laravel. Это касается не только Фреймворков, любая сторонняя библиотека должна быть изолирована от прямого использования. Это позволит Вам быть более гибче и сделает Ваш код менее связанным и зависимым.
   
3. Оба Фреймворка популярны и имеют право на существование. У всех разный порог входа, разное сообщество и разные решения. На Symfony код пишется чуть сложнее и дольше, так как нет привычных фасадов. Многие компоненты и Фреймворки используют компоненты Symfony в виде своих обёрток. Однако, нужно понимать, что Фреймворк задаёт немного стиля в разработке, у Symfony этот стиль более правильный и строгий. Поэтому, использование Symfony интуитивно подталкивает Вас к написанию более чистого кода, без погружения в различные паттерны.
   
4. Doctrine — это НЕ тот же Eloquent. Это совершенно разные вещи!
   Eloquent —это анти паттерн Active Record, а Doctrine это паттерн Data Mapper. Если речь идёт о быстрой разработке и не долгоживущем или небольшом проекте, то можно взять и её, однако на долгий срок лучше использовать Data Maper типа Doctrine, Cycle. При таком подходе ваши поля «не торчат» напрямую из базы данных в код. При изменении столбца в БД — его не придётся менять по всему проекту. Для Data Mapper подход — Code First (Вначале код), а для Active Record — Table Fist (Вначале таблицы). При использовании Data Mapper мы не думаем как будут храниться наши данные в БД, не думаем какая будет БД, что не скажешь по AR.
   

Тема фреймворков на Q&A поднимается очень часто. Лично мне приходилось много раз отвечать на подобные вопросы. Вы можете сами в этом убедится по моим ответам:

• Актуален ли Yii2 Фреймворк в 2020?
  
• Какой подход программирования на PHP выбрать в 202...
  
• Переход к PHP-фреймворку. Какому?
  

Поэтому, серьёзно к таким вопросам здесь не относятся. Чтобы понять разницу — Вам, очевидно, нужно попробовать оба Фреймворка в разных ситуациях. Со временем Вы сами всё поймете. А если Вас устраивает Laravel и не предвидится какого-то большого развития — пользуйтесь. Пару строк кода можно написать и без какого-либо Фреймворка. Главное — результат и правильно подобранный инструмент.

При этом, ревьювер зачастую ссылается на какие-то неведомые мне стандарты и правила, которые, дескать, "и так все знают" :-)

Это плохое ревью, и на какие-либо стандарты и нормы надо ссылаться.

- А существует ли где-то книга-учебник с такими вот правилами, следуя которым можно писать такой код, к которому уж точно никто не придерется?

Нет, тк не существует эталона.

Есть общие правила, про архитектуру, и ООП: чистая архитектура, порты и адаптеры, MVC, CQRS, SOLID, GRASP
Есть общие правила про оформление кода: чистый код, совершенный код (они немного противоречат друг другу), KISS, DRY, YAGNI.

А чтобы было меньше придирок на ревью:
1. Внедри кодстайл, и контролируй его при помощи всяких автоматических инструментов
2. Опиши архитектуру в каких-нибудь внутренних документах в проекте (можно прямо в репу запихать), и при реализации фич опирайся на эти документы.
3. Давай нормальные имена переменным, и избегай всяких code smell-ов, и антипаттернов
4. Пиши тесты

git stash -u && git stash drop

Даже два
git checkout .
или
git reset --hard