Unit of Work - это паттерн определяющий логическую транзакцию т.е. атомарную синхронизацию изменений в объектах, помещённых в объект UoW с хранилищем (базой данных).

Если обратиться к исходному описанию этого паттерна у Мартина Фаулера - то видно что объект, реализующий этот паттерн отвечает за накопление информации о том какие объекты входят в транзакцию и каковы их изменния относительно исходных значений в хранилище. Основная работа производится в методе commit() который отвечает за вычисление изменений в сохранённых в UoW объектах и синхронизацию этих изменений с хранилищем (базой данных).

Паттерн Unit of Work как правило не является полностью самостоятельным, он обычно тесно связан с паттерном Identity Map, задача которого - сохранение карты созданных объектов, взятых из хранилища с тем чтобы гарантировать что одна единица информации из хранилища представлена ровно одним экземпляром объекта данных в приложении. Это позволяет избежать конфликтов изменений т.к. не допускает ситуации когда два объекта, представляющих один и тот же элемент данных в хранилище, изменены по-разному. Информация из Identity Map используется в методе commit() паттерна Unit of Work для вычисления разницы между исходными данными и накопленными изменениями.

Поскольку для вычисления разницы (и, соответственно, определения того что и каким образом должно быть изменено в хранилище) необходимо знать какие данные и как именно хранятся в объектах - как правило необходима также реализация паттерна Metadata Mapping, описывающего связь между содержимым хранилища (к примеру таблицами и столбцами базы данных) и классами / свойствами объектов.

Также, если данные в хранилище не являются независимыми (к примеру связи между таблицами в базе данных) - может потребоваться реализации ряда паттернов, отвечающих за сохранение информации о связях между данными (это паттерны раздела Object-Relational Structural Patterns в каталоге паттернов).

Подводя итог: сам по себе Unit of Work довольно прост в своём внешнем интерфейсе, но реализация его корректной работы требует предоставления множества дополнительных данных, поэтому миниатюрных примеров привести не могу.

Если говорить о PHP - то лучшей реализацией этих паттернов на PHP безусловно является Doctrine ORM. В частности в разделе Working with Objects документации Doctrine можно найти хорошее описание и множество примеров использования паттернов, описанных выше.

Визуально выглядит вполне пристойно и очевидных косяков почти нет, но если копнуть глубже - возникают вопросы.

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

Из наиболее заметного - заглавная картинка с автомобилем в PNG которая занимает почти 600кб и из-за этого грузится весьма и весьма неспешно (и заметно для пользователя). В целом это по большей части косяк дизайнера, не приложившего усилий к тому чтобы выбрать правильную графику (автомобиль снят явно на улице и отражения в стёклах дают существенный вклад в визуальный шум и, как следствие, в размер картинки, нужно было выбирать фотографию сделанную в специальном помещении). Кроме того дизайнер, очевидно, не слышал про требования к такси в Нью-Йорке и рисовал как взбредёт в голову, но оставим это на его совести. Сочетание фоновой картинки, на которой весь траффик едет в обратном направлении и делает автомобиль такси нарушающим правила дорожного движения - тоже на совести дизайнера.

Однако и в этом случае и, тем более, в случае фоновых изображений ниже по странице вы допускаете ошибки с выбором форматов файлов, способами их вставки в страницу и оптимизацией. К примеру из картинки с автомобилем можно выжать почти 100кб просто за счёт использования оптимизаторов. Гораздо грустнее ситуация с фоновыми картинками ниже по тексту. Во-первых вы сохраняете фотографии в PNG, получая на выходе файлы по мегабайту, хотя они же в JPEG занимали бы в 5-10 раз быстрее. Во-вторых вы, скорее всего, сохранили фоновые картинки уже обработанными (затемнёнными). Я не видел макета, но предположу что там эти картинки стоят в их оригинальном виде и на них наложены какие-нибудь фильтры. На первый взгляд кажется что проблемы нет, но на практике (в случае вёрстки для реального сайта) вы вынуждаете человека который будет поддерживать сайт либо готовить картинки с такой же пост-обработкой либо мириться с тем что стиль сайта меняется. Правильное решение здесь - грузить картинки как они есть и реализовывать фильтры на CSS, тем более что здесь это делается элементарно через multi background или псевдо-класс с полупрозрачным фоном. Очевидно также что для таких тёмных картинок вполне можно использовать JPEG с меньшим качеством и тем самым существенно сэкономить пользователям трафик.

Ещё одна проблема связанная с фоновыми картинками - вы не подкладываете под них близкий по цвету solid color. Попробуйте включить в dev.tools "Network throttling", отключить кэш и перегрузить свою страницу - думаю вы поймёте что я имею в виду - белые блоки с белым текстом стоят довольно продолжительное время, постепенно заполняясь довольно тёмными картинками. Если бы background-color под ними был бы чёрным - проблемы бы не было.

Далее - логотип. Обычно логотипы разрабатываются отдельно и даже если он выглядит просто набранным шрифтом - это вовсе не значит что это не так. Логотип Google, Microsoft или Яндекс - тоже просто название, но, надеюсь вы не сверстаете их, написав надпись текстом? В общем логотип = картинка, лучше в векторе. Сейчас даже одно съезжание слогана на пиксель влево относительно названия уже рушит всю конструкцию логотипа.

Обратите внимание на то как вы работаете с формами. Все поля в форме являются <input type="text">, хотя часть названий явно намекает на date / time селекторы, а "Choose Vehicle" - на список выбора.

Хотелось бы отметить работу с иконками - их всё-таки лучше хранить в SVG и либо требовать с дизайнера либо подбирать на том же Icon Finder. При этом оформление (те пресловутые жёлтые кружки) лучше делать через CSS т.к. это позволяет вам существенно гибче работать с размерами элементов.

Есть всякие недочёты касающиеся responsive, к примеру, внимание как отображается блок "Our Tariffs" в размере чуть более 600px, в частности название тарифа и описание.

Пожалуйста обратите внимание на то что вы используете два разных меню для desktop и mobile представления. В целом в вашем случае меню довольно простое и можно было бы обойтись одним. Конечно две копии используют часто, но у этого решения есть свои недостатки (в частности отсутствие синхронизации состояния), так что вы должны осознанно принимать решение по таким вопросам. Кроме того inline обработчики onclick там явно могут быть заменены на элементарный

document.querySelectorAll('.menu a, .menu-hover a').addEventListener()

что явно сделает код более простым и поддерживаемым.

Ещё один важный момент который зачастую опускают при вёрстке - поведение макета с реальными данными. То что дизайнер в макете понапихал везде lorem ipsum и тексты примерно одинакового размера - отнюдь не означает что на реальном сайте эти условия будут соблюдаться. Отсутствие навыка проверять поведение макета в изменяющихся условиях ведёт к множеству ошибок которые не видны в условиях синтетических данных. К примеру попробуйте в блоке "We Do Best Than You Wish" (претензии по поводу английского языка оставим в стороне) в любом из элементов банально увеличить количество текста в 2-3 раза. В Chrome это приводит только к излому сетки, в Firefox - ещё и к изменению размера иконки. При этом я предполагаю что Firefox ведёт себя правильно т.к. пропорции элементов изменились, а ограничения размеров на картинки у вас не заданы.

В целом похоже что макет верстался и проверялся только в Chrome. К примеру посмотрите как ведёт себя картинка с рукой и телефоном в Firefox при изменении размеров. Опять же Firefox вполне корректен т.к. вы не обрезали картинку корректно, предпочитая выгрузить "как есть" и подгонять положение в CSS, но забыв при этом про overflow: hidden для контейнера.

Теперь перейдём к CSS:

Обратите внимание на то как вы подключаете внешний шрифт:

family=Lato:400,700,700i,900,900i&subset=latin-ext

. Возникают два вопроса:

1. Зачем вам subset=latin-ext на сайте где есть только базовая латиница?
   
2. Как вы выбирали начертания? У вас подключаются 5 начертаний (400, 700, 900 + два italic'а), при этом grep по CSS даёт значения font-weight 200, 300, 400, 500, 600, 800 и ни одного italic. Вам не кажется что эти множества почти не пересекаются?
   

Кроме того вы постоянно забываете про fallback шрифты что на медленном интернете и при отсутствии инструкций для font loading приводит к невидимому контенту страницы на период загрузки.

Отсутсвие ограничения по ширине для .wrapper приведёт к недопустимо широкому сайту на больших мониторах с высоким разрешением. Можете уменьшить масштаб страницы до 50% и полюбоваться результатом.

В стилях повсеместно используются достаточно общие названия классов в global namespace. К примеру кто бы мог подумать что стилизует селектор .text? Вы уверены что нигде больше на сайте подобный селектор не встретится? Даже при дальнейшем развитии сайта? Другими словами именование селекторов - важная часть работы, вы можете использовать любую методологию (тот же БЭМ или что-то ещё) или разработать свою, но ваш код не должен ломаться при добавлении ещё пары блоков, особенно если это будет делать другой человек.

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

Использование id в качестве CSS селектора - плохая практика, но у вас таких мест немало, 11 штук.

Уверен что мог бы найти ещё что-то, но надеюсь для затравки хватит, и так много получилось... :)

1. dart-sass - reference implementation языка т.е. является образцом того как должен работать язык. node-sass binding libsass (реализации спецификации языка на C++) к node.js.
   
   dart-sass содержит в себе все последние фичи языка, к примеру там уже есть поддержка sass modules, libsass отстаёт, а node-sass отстаёт от libsass. За пруфами - сюда и сюда
   
2. libsass производительнее, местами - существенно. К примеру в моих тестах интенсивная работа с sass maps в libsass примерно в 10 раз быстрее чем в dart sass. Насчёт микросекунд - у меня есть проекты которые по 15-20 секунд компилируют только стили на node-sass, на dart-sass всё намного медленнее
   
3. Приведённые ссылки - сравнение тёплого с мягким. Есть реализации языков, а есть плагины для их подключения к различным сборщикам. sass - сама реализация языка, gulp-sass - binding для Gulp, sass-loader - binding для Webpack
   

Спецификаций CSS занимается рабочая группа в составе W3C. Там же есть и информация о том, как принять участие / предложить свою идею.

К примеру вы можете создать issue в репозитории рабочей группы.

Однако вам стоит понимать, что работа над спецификацией уровня CSS Grid - это многолетний труд сотен людей для того, чтобы довести её до реального использования. Если вы предполагаете что за всё это время никто из них не додумался до этой идеи - то вам стоит подумать ещё раз.

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

За примерами далеко ходить не нужно: parent selector - мечта уже нескольких поколений разработчиков и тема постоянных вопросов. Однако его нет в спецификации (хотя он был в первых драфтах CSS 3 насколько я помню) и скорее всего не будет. Причину, если интересно, попробуйте поискать сами.

Или, к примеру, такое очевидное, казалось бы, опущение как отсутствие аналога :hover для "stuck" состояния элемента с position: sticky. Ведь его явно не хватает почти любому кто использовал этот стиль. Однако его не будет, о причинах (логичных, но далеко неочевидных) можно почитать в соответствующем issue.

Конечно, если вы внимательно и детально изучите все спецификации и проработаете и напишете своё предложение - оно, вероятно, будет рассмотрено. Но более вероятна ситуация что где-то здесь вы найдёте аналогичную или близкую идею.

Если у вас аккаунт организации - то там всё просто: На основной странице организации вкладка People, дальше слева выбираете либо Members либо Outside collaborators, там выбираете нужного человека и слева внизу будет кнопка "Remove from all repositories".

Если же у вас просто личный аккаунт - то там такого не предполагается (что естественно).

Возможно вам стоит рассмотреть вариант перевода вашего аккаунта в аккаунт организации (Settings -> Organisations -> Transform account) если по факту это всё равно организация. Конечно в этом случае поменяется схема биллинга, но GitHub недавно сильно снизил цены для GitHub for Teams так что вполне можно пользоваться.