Snorway

как я обычно делаю:
1)создаю новую ветку со своей фичей(и ты автоматически в нее перейдешь):
git checkout -b name-branch
2)делаю что надо
3)коммичу

git add -A
git commit -m "Name commit"
git push origin name-branch

4)Обновляю свою ветку по отношению к master (так образом твой последний коммит будет стоять на вершине)
git pull --rebase origin master

5)Возвращаюсь в нужную ветку (master или developer)
git checkout master
6)Обновляю свою локальную ветку
git pull origin master
7)Сливаю изменения и делаю пуш

git merge name-branch
git push origin master

Сайт A - кэшбек
Сайт Б - магазин

Когда вы заходите на сайт А, то он записывает вам в куки метку. Потом передаёт её магазину Б. При этом если эта метка есть у вас, то цены в магазине Б будут сразу выше на несколько процентов. Но если используете кэшбек, то вам якобы сделают скидку в 5-10%, но по факту нет.

Изначально товар стоит - 10000
Цена товара с меткой - 10500
Цена со скидкой кэшбека - 10200

200 рублей забирает кэшбек себе, а магазин ничего не теряет. Ну и потом вам возвращают 300 рублей, вы думаете "Ух ты!", а на самом деле вы дали магазину деньги, чтобы он через какое-то время вернул их вам. При этом ещё и купили товар дороже на 200 рублей

Скорее всего - проблема в многократном создании объектов класса без уничтожения тех, которые уже не нужны.
Но правильнее, будет использовать один экземпляр такого класса, поддерживающего многомерную структуру (дерево, стек и т.д.) с клонированием объектов внутри самого класса. Это значительно экономит память на выделение для каждого нового создаваемого подобного объекта класса.

Наиболее надёжный способ проверить существование e-mail это сделать callout через инициацию SMTP-сессии. Достаточно будет получить 250 OK на команду RCPT TO с проверяемым адресом.
Но он не даёт 100% гарантии, поскольку некоторые серверы всегда говорят OK на любой адрес в поддерживаемых им доменах.

В целом сразу вас расстрою, то что вы хотите нельзя "разобрать" за пару месяцев. На это уйдет пару тройку лет. И книги которые стоит по этой теме прочитать имеет смысл перечитывать. Ну и практика практика практика.

Так же хочу заметить что "архитектура" это не что-то эдакое, а общее понимание команды разработчиков о том как функционирует приложение. Если этого общего понимания нет - у вас нет архитектуры. У многих разработчиков понимание пропадает уже через пару месяце стихийной разработки. Так что помимо архитектуры важно еще и процессы/методологии разработки подтянуть.

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

но совершенно не имею представления о правильной архитектуре приложений на php

"Правильно" не бывает, все зависит от задачи. "Правильная" архитектура является:

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

Вот и все. Далее уже есть принципы SOLID (читать Роберта Мартина), GRASP (Крэйг Ларман), GoF (лучше тут почитать head first design patterns или даже начать с Мэта Зандстры, у него помимо паттернов еще про процессы мельком рассказано).

Ну и смысла в этом всем нет если вы еще до конца не осознали что есть инкапсуляция и полиморфизм. Многие могут рассказать что значат эти термины, но на практике эти знания они не могут применить (чаще всего страдает инкапсуляция)

или написании чего-то своего с нуля на чистом php

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

идеально было бы вообще подробно расписанное сравнение внутреннего устройства нескольких фреймворков

Берете Symfony или Zend и вперед. Все остальные фреймворки "проще". То есть скрывают больше от разработчика. После них уже можно брать что угодно.

p.s. еще прочитайте тут: www.phptherightway.com

Джун джуну рознь. Чем больше знаний - тем лучше.
Троелсен и правда очень медленно и педантично повествует. Он удобен как настольная книга джуниора, как справочник - по конкретным задачам копать. Но, ИМХО, Шилдт будет приятнее.

Основные контейнеры - преимущества и недостатки. Сложность алгоритмов поиска и вставки, сортировки. Хэш-таблицы, хэш-код объектов, equality и как это все устроено. Неплохо бы знать про многопоточность и примитивы синхронизации (в общих чертах).
Хорошо бы знать кое-что про платформу .NET - типы-значения и ссылочные типы (про стек и кучу), про GC с поколениями, SOH/LOH, как можно устроить утечку памяти -> IDisposable.
Уметь делать запросы к базе через голый ADO.NET.
По базам данных: владеть основными запросами SQL, писать и вызывать хранимые процедуры. Знать что такое и зачем нужны индексы, нормализация, View, где смотреть query execution plan.
Суметь рассказать о том, что такое MVC, ориентироваться в основных паттернах.

Если курс на веб, то понимать работу HTTP, REST, знать основы фронта (приоритет селекторов в CSS, "всплывающие" объявления переменных в javascript, разницу "==" и "===", чем отличается асинхронность от параллельности и чем это грозит).

Вызовет уважение в глазах интервьюера: понимать и применять IoC/DI, уметь писать тесты, работать с ORM (EntityFramework допустим), async/await и SynchronizationContext.

Для начала почитать офф. доки: www.yiiframework.com/doc-2.0/guide-tutorial-core-v...

[ [ 'score' ], 'compare', 'compareValue' => 1, 'operator' => '>=' ],
[ [ 'score' ], 'compare', 'compareValue' => 100, 'operator' => '<=' ],
# или
[ [ 'score' ], 'in', 'range' => [ 1, ..., 100 ] ],
# или
[ [ 'score' ], function ( $attribute, $params ) {
    if ( !( $this->$attribute >= 1 && $this->$attribute <= 100 ) ) {
        # Ошибка!
    } 
} ],

В ActiveRecord "модель" совмещена с репозиториями. Либо можете просто написать свой сервис, который будет этим делом заниматься. Главное же в репозитории в том, что код который его использует понятия не имеет о том где хранятся данные.