mayton2019

Вот это правильно

develop (git pull)

зайти в свою ветку branchTaskName и смержить ее с develop (git merge develop) и продолжать с задачей

Остальное - опционально. Например нет смысле тебе обновлять локально мастер. Мастер тебе может понадобиться только для изготовления хот-фиксов на прод.

Большинству людей глубоко наплевать на то как выглядит код программиста. До тех пор пока он - одиночка-фрилансер.

Как только вы начинаете работать в паре с кем-то, или в команде, или просто хотите поделиться чем-то в форумах или в GitHub - вот с ЭТОГО момента начинается публичный дискурс вокруг внешнего вида.

Есть такое отдельное понятие - "Эстетика программного кода". Оно - неформализуемо и никто не может дать четких определений какой код эстетичен а какой - нет. Я считаю что только долгий опыт работы в команде с другими людьми позволяет определить для себя эстетику.

Но стартовой точкой в этом вопросе может быть чтение книги Роберта Мартина - Чистый код. Там описаны достаточно простые и очевидные вещи типа как оформить комментарии к коду или сколько строк должна иметь функция. Но начать с нее стоит. По крайней мере чтобы в приличном обществе выглядеть джентльменом.

Если оставить ключевую информацию то в массиве будет нечто вроде

const array = [
      ["1", "1", "1"],
      ["2", "2", "2"],
      ["1", "3", "3"]
  ....
    ];

А остальная логика будет просто view по отношению к этим данным. Туда-де пути к картинкам.

Postgresql - более консервативен. Его можно брать почти для любых проектов. Есть partitioning что свидетельствует о зрелости системы и об Enterprise-ready. Единственное что может быть не очень - это некий кумулятивный эффект от частых inserts/updates который требует вакуума. И со счетчиками транзакций там есть нюанс. Но скорее всего в твоём сегменте разработки PHP/Laravel - тебе будет просто безразлично сущестование вакуума.

MySQL это лейбл под которым на самом деле могут работать различные engines таблиц. И если анализировать какой-то performance-инцедент то нужно в первую очередь спрашивать с какой опцией таблица создавалась. MyISAM/Innodb/e.t.c. Потому что выбор этого двигателя влиял на какие-то опции скорости и транзакций. Я заменял например в создающих скриптах InnoDb на MyISAM для того чтобы просто быстрее прогрузить 1Тб CSV файл.

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

Что лично меня раздражает в диалекте My/SQL - так это странного вида кавычки-апострофы. Никогда не понимал зачем это.

RUN mkdir создает папку внутри docker-image.
Поэтому ее не видно невооруженным глазом.
Тоесть это подготовка артифакта дистрибутива а
не манипуляции с твоими каталогами.