Vitsliputsli

Прочитайте мануал, вообще это всегда нужно делать при возникновении вопросов.
Если открыть https://www.php.net/manual/ru/language.basic-synta... там прямо указано:

Комментарии в стиле языка C заканчиваются, когда обнаруживается первая последовательность */

Вполне четко и однозначно.

Например, // перекрывает /*, но не перекрывает */

Никто никого не "перекрывает". Если у вас однострочный комментарий, то в мануале об это сказано так:

Однострочные комментарии распространяются только до конца строки PHP-кода или на текущий блок PHP-кода в HTML-строке, в зависимости от того, что идёт первым.

Открыли комментарий конструкцией // и уже не важно, что там будет дальше до конца строки.
Открыли комментарий конструкцией /* и уже не важно, что там будет дальше до закрывающей конструкции */.

Правильнее merge.
Merge создаст новый коммит в котором объединит 2 ветки.
Rebase удалит все ваши коммиты из ветки, перенесет ветку в другое место и создаст новые коммиты с новым родителем.

Т.е. если чтото не так смержили при ребейзе выковыривать придется из удаленных. Плюсом ребейза считается более "красивая" картинка, по-факту это просто уничтожение истории, а сам факт уничтожения истории в системе контроля версий порождает вопрос, а зачем тогда вообще контроль версий?
Поэтому ребейз не применим, если вы не один пользуетесь веткой. А если один, то все на вашей совести. На практике, конечно не всегда все так катастрофично, поэтому есть предпочитающие ребейз. Специально ради таких вредителей основные ветки проекта делают защищенными от переписывания.
Есть редкие ситуации, когда ребейз предпочтительней, например вы мержите в ветку, но забыли сделать пулл, смысла этот смерженный коммит держать в параллельной ветке нет, лучше при таком мерже выбрать ребейз, т.к. такое переписывание истории будет только локальным.

apk del icu-data-en
apk add icu-data-full

Мне нужно отделить фичу размазанную по веткам в отдельную ветку

Создаете ветку W в HEAD ветки M. С помощью git checkout затягиваете в нее нужные файлы. Проще конечно это сделать в какомнибудь gui (в IDEA IDE это называется get from Revision).

Как переместить в новую ветку W файл m.txt и его историю из 8 коммитов?

Довольно сомнительная хотелка, придется создать много новых коммитов.
Создаете ветку W в HEAD ветки X, затем удаляете все ненужное
git filter-branch --tree-filter 'rm -f x.txt' X
Создаете ветку W2 в HEAD ветки Y, затем
git filter-branch --tree-filter 'rm -f y.txt' Y
затем мержите W и W2. Разумеется можно и в другом порядке.

Указанные обращения вполне корректны. Даже без явного указания замыкания, php свяжет this с текщим объектом класса WorkermanWebSocketController. И все обращения (в том числе и запись) внутри анонимных функций в инстансах класса Worker будут замыкаться на него.
Почему не работает, потому что приведенный код нисколько не говорит о том, в каком порядке будут выполняться эти анонимные функции.

Если проблема только в usb.
Стартануть grub (с диска или с флеш). Скопировать образ с флеш в оперативу, и запустить его.

Почему PHP считает int числа после математических операций как float?

Потому что именно такое поведение описано в документации. Вообще, чтение документации отвечает на большинство вопросов. Очень рекомендую всегда начинать с нее.

возможно ли будет увеличить скорость, если тянуть два интернет кабеля?

как уже написано, если провайдер обеспечит на каждом кабеле по 100, то возможно.

Какое оборудование для этого лучше использовать?

Проще всего 2 железки, способные подключиться к интернету провайдера и раздать на 10 машин каждая. Будет 2 подсети, если надо можно и локальный доступ сделать между ними.
В случае 1 железки придется хитро маршрутизировать, или задавать каждой машине свою подсеть со своим шлюзом.

Интернета не хватает (20+ компьютеров).

Не факт, что после увеличения скорости интернета будет хватать. Ктото 5Мб фалик не может по почте получить, а у когото фильмец медленно через торрент льется. Вполне возможно, что вам нужно смотреть в сторону шейперов.

Основное требование: востребованность в будущем этих навыков.

Для разработки бд в будущем как и сейчас будет востребован навык разработки бд. А где вы схему нарисуете, да хоть на бумажке, это вообще дело десятое.
Если расчет, что инструмент както сам большую часть сделает, то нет, не сделает. А что сделает, то и самому легко написать.

Это не просто подсказки, это контроль типов. То, что зная какой тип возвращается Шторм может подсказать варианты это побочное удобство. Основное же должно быть то, что конкретная переменная имеет определенный тип, а значит не нужны дополнительные проверки и методы будут лаконичны и конкретны. У вас пока, то ли объект, то ли массив, то есть каждый раз нужно проверять что это. Лучше бы сделать объект-коллекцию.
Чтобы указать Шторму, что в конкретной переменной лежит только этот тип используется хинт, типа такого:
/** @var User $user */
но разумеется, он должен быть только в том коде где в $user лежит обязательно объект класса User и ни что иное.

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

1Гб это очень мало для современных дистрибутивов, тем более для сервера с СУБД. apt check в Ubuntu (не знаю как в других) любит жрать память без причины, просто так, и никто это не чинит уже более 10 лет. А когда память заканчивается неизвестно, что попадет "под нож", вполне может и СУБД, как самый жирный процесс. Поэтому проверьте когда в последний раз запускали СУБД.
Если увеличить память никак нельзя, попробуйте полностью отключить запуск apt-check. Если у вас обновления автоматические, то перевести их на cron.

сбрасывается индексное значение (auto_increment) до 1

Таблица постоянно чистится, и в этот момент она пуста?

На практике не делал, но чисто теоретически, поле id подразумевает что для него построен индекс primary key (иначе зачем оно нужно). В PostgreSQL primary key в партиционированной таблице - это индексы каждой отдельной партиции, т.е. если мы партиционировали не по полю id (а скорее всего так и есть), то при попытке обращения по полю id нам нужно отдельно пройтись по каждому индексу каждой партиции, а это уже не так весело как по одному индексу. А если партиции сделаны достаточно маленькими и их много, то фуллскан одной партиции скорее всего будет быстрее. А если контроль уникальности вынесен в приложение, то можно обойтись вообще без primary key, даже натурального, тогда и при вставке не нужно сканить все эти индексы.

При применении миграций после переключения на новый код вам придется постоянно в коде проверять версию базы и держать код работы с разными версиями. Иначе - постоянная некорректная работа во время деплоев.
Гораздо проще применить миграции и переключиться новый код. Обратную совместимость базы данных поддерживать легче (если база - это данные, а не хранимые процедуры), поэтому откатить код можно будет без проблем, а откатывать миграции скорее всего даже не потребуется.
Самый простой способ тестирования для отката - это контроль ошибок реальной работы и скрипты health check по основным метрикам, их будет достаточно.

чтобы мне такого почитать про оценку времени вообще и про декомпозицию задач в частности?

Я бы посоветовал ничего не читать и не тратить впустую время. Оценка времени разработки никогда не бывает точной и с этим нужно смириться. Декомпозиция вещь хорошая, но тут теория вряд ли поможет, только опыт разработки.
Любая попытка более точной оценки - это устранение неопределенностей, для этого, например, разбивают на более мелкие задачи в которых точно уже известно что делать и кажется что все контролируешь. Но, оценка никуда не делась и она всегда строится на "похожих" задачах, которые уже делались. Только вот если мы говорим про нормальную разработку, то там это не работает, совсем... Если действительно похожая задача реализована, значит основной функционал уже есть и нужны только минимальные правки, а значит вторая задача будет стоить несравнимо меньше. Другой момент, действительно со стороны может показаться что есть похожие задачи и на них всегда тратится похожее кол-во времени, но в какойто момент времени окажется что следующая "похожая" обойдется в 10 раз дороже. Поэтому если где-то похожие задачи всегда стабильно стоят одинаково, то скорее там не разработка, а набор текста.
Если про правки "в сильно незнакомом коде", то даже не пытайтесь, здесь неопределенность зашкаливает. Такой код требует предварительно изучения, и не важно какая задача, она может решаться как добавлением 2 строчек, так и переписыванием всего и вся.
"возможно предварительно поисследовав", как только вы употребили слово исследование, никакие оценки здесь уже не применимы. Исследования не оценивают, на них выделяют время, когда время закончилось решают нужно ли еще время или бессмысленно копать в эту сторону.
Это все, конечно, несколько утрировано, но, на мой взгляд все что требуется со стороны разработчика (а я так понял вопрос именно с этой стороны) это просто давать оценку задачам, а затем обращать внимание на аспекты которые потребовали много времени, но которые упустили при планировании.

Прям очень по-разному, но чаще очень редко или никогда.
Вообще, нагрузочное бывает 2х видов:
1) тестирование релиза на возможную деградацию производительности;
2) тестирование запаса прочности приложения (это когда повышаем нагрузку, пока все не упадет).
И еще важно где применяется:
а) где деплой полностью контролируется, т.е. на свои серверы;
б) где сборка разворачивается где-то на удаленных серверах 3ми лицами.
Нагрузочное 1 типа для варианта "б" проводят для каждого билда, вряд ли есть исключения, иначе чревато. Для варианта "а" часто "забивают" вообще на этот тип тестирования. Причины просты, прям какаято сильная деградация будет заметна при прогоне обычных тестов, просто по их замедлению. А если тесты еще идут параллельными потоками, то и некоторые блокировки можно отловить. С другой стороны, если чтото не так, то деплой полностью контролируется и можно всегда откатиться. И тут реально в первую очередь лучше озаботиться blue-green серверами и плавным переключением трафика, а потом уже нагрузочным тестированием. Да и чаще, это будут какието медленные деградации, которые отловит мониторинг и опять же либо будет время поправить, либо можно откатиться.
Нагрузочное типа 2 делают очень редко (например 1-2 раза в год), т.к. штука затратная, и опять же мало где его вообще встретишь, только там где стабильность очень важна и/или пиковая нагрузка может в разы отличаться от стандартной.