Tony Soloveyv

А давайте не пользоваться жаргонизмами. Заказывайте просто услугу
Статический внешний IP-адрес
если на него нельзя достучаться снаружи то это уже какая-то фигня а не услуга.
Так как статику заказывают для доступа из вне.

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

Можно. Не открывать много вкладок

этот вопрос у меня относится к удобству чтения кода и просмотра сайта другими пользователями, чтобы они удостоверились в разработке на React.

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

Либо, чтобы из репы можно было скопировать лишь dist/ и сразу опубликовать это как приложение в любом месте, без дополнительных команд.

От такого способа не будет видно, что применялся Реакт?

Слепой не увидит ничего, в остальном - все чекается на раз-два.

Рекомендую изучить крупные репы и обратить внимание на то, что там в рамках одной репы имеются исходники (src), сборки разных видов (dist/build), опубликованы все необходимые команды так, чтобы даже не зрячая обезьянка могла скопировать и выполнить эту команду, чтобы получить желаемый результат.

Устанавливай .NET Core и разрабатывай на здоровье.
Разница с Windows разве что в отсутствии оконных приложений, а остальные типы проектов есть.

P.S. Visual Studio придется забросить и перейти либо на VS Code либо на Rider

Хранение файлов в бд - самый хреновый вариант из имеющихся. По многим причинам, но основная - файлы должны лежать в файловой системе. Это их естественное состояние. Это быстро, не затратно, не потребляет лишнюю память/процессор и просто удобно. В зависимости от необходимости давать к ним доступ всем или по авторизации, будет либо работа напрямую с статикой через какой-нить нжинкс, либо программно сформированный поток байт через что-то типа пхпшного readfile...

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

Почему C# не кроссплатформенный?

На этот вопрос нельзя ответить сразу по двум причинам:
1. C# - это язык, а язык не может быть кросс-платформенным, так как платформы в разрезе языка и нет.
2. .NET уже много лет как кросс-платформенный.
Начиная с уже мейнстримного .NET 8, заканчивая mono и всякой экзотикой типа nano framework

но при этом, это не так

Ничто нельзя запустить на "чём угодно"

но в неё вопрос кроссплатформенности решена абсолютно полностью

Если вопрос "абсолютно полностью" решён, то почему я не могу запускать программы, написанные на Java, на любом железе?

Ну вангую что у тебя там в корне какие то файлы или пути с кириллическими названиями Винда не сильно любит UTF а темболее mingw

file_get_contents сложновато передавать и получать куки и др заголовки. file_get_contents для POST запроса тоже выглядит многословно, уже наравне с curl. Не очень хорошее поведение при 4xx 5xx ошибках и тд. Хорошей практикой будет использовать file_get_contents только для локальных файлов.

Довольно часто предлагают тестовое задание, на которое у меня нет времени.

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

Разумно ли написать проект с нуля, скажем, интернет магазин, залить все это на гитхаб и давать ссылку работодателям каждый раз когда просят пройти тестовое задание?

Специально - нет, не нужно. Разве что по результатам прохождения курса учебного какого - можно выложить. Ну и пет-проекты никто не отменял - вот их да, можно и нужно выкладывать на гитхаб и периодически подкармливать.

Разработчики должны иметь свое изолированное окружение, обычно локальное
Дальше неплохо иметь промежуточный dev сервер, как для последнего прогона тестов, так и для интеграционных тестов
Далее dev копируется в продакшн, или снепшот из продакшена копируется в дев и они меняются ( если что можно мгновенно переключиться в старый )
Заливка из VCS только в дев.

Можно ли ставить дев и продакшн в одной среде зависит от того когда тестируется производительность и прочие нагрузочные вещи. Если до заливки в дев, то можно, иначе — нельзя — есть риск завалить тестами или кривыми изменениями.

Я бы сделал один сервер в продакшн, второй в реплику и третий дев. При сем дев и продакшн менял местами и бекапил бы их вдруг в друга, а реплика имела бы два контейнера или набора серверов соответствующие двум другим машинам.

Мне кажется, вы не совсем корректно поняли совет. Нужно было использовать Linux(без иксов) только для запуска докеров, а не перебираться работать в виртуалку.
Ни разу схему выстраивать такую не приходилось, но раз в нативном докере работает, то и так тоже должно завестись.
Можно сетевые карты мака и линухи объединить в бридж, а контейнеры в линухе запускать сеть в режиме Host.
Возможно это излишне и из контейнеров можно ходить на мак по его ip, а не через loclahost. По крайней мере так делает нативный докер

Контейнеры данных

Они не нужны, используйте named volumes вместо этого (с версии 1.9 докера).

Исходный код и локальные npm-модули (или лучше это в предыдущий контейнер, и при старте выполнять

Нет, npm install надо выполнять ДО сборки образа. Когда контейнер стартует - внутри у него уже все должно быть. Опять же я лично против того, что бы выносить исходники проекта в отдельный контейнер-пустышку. У вас есть контейнер с нодой - исходники для ноды должны быть там. Есть некоторые нюансы связанные со сборкой контейнера но это так.

На файловой системе хоста

Ничего.

Логи прокидываются в stdout/stderr контейнера и собираются на хосте через докер любым подходящим драйвером (читаем документацию).

Конфигурация - все что в конфигах от окружения к окружению меняется - в ENV переменные. Все остальное - не меняется и потому просто вшито внутрь контейнера.