Александр Ананьев

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

Вот вы говорите:

Нужно будет выполнять много запросов к БД

Важная быстрая скорость работы нашего сайта

Много/быстро это сколько? 100 запросов в час? 1000 в минуту? 1М в секунду? Загрузка страницы за 30/10/1с или даже 100мс? А к какой именно БД? Какая характеристика самих данных и какого типа запросы? На какое количество соединений? В каком регионе? Есть ли там тяжелые или еще какие-то вычисления? Медиа файлы - картинки, видео? Тут очень много нюансов. В идеале следует определиться с конкретными значениями/параметрами и их описать в ТЗ. Ну или определить примерное, а фактическое значение определить на стадии прототипа/MVP и/или провести какое-то исследование/тестирование. Можно потратить десяток лямов на написание крутого кода на го/расте/С++/ассемблере в течении года и все будет летать на простейшем сервере. А можно купить свой сервер за лям (ну, условно, конечно), нанять питонщика или PHP-ника за 300к и он за пару-тройку недель добьется такого же результата. Большинство веб-задач сегодня достаточно просто или с минимальными усилиями решаются абсолютным большинством решений для веба. Да, у всех решений есть свои плюсы и минусы.

Безопасность от всяческих XSS и SQL атак.

Вот с этим проще: использовать популярные OpenSource решения, регулярно проводить тесты, нанять отдельно опытного разработчика, красноглазика и пентестера - и тратить на них деньги, пока деньги не кончатся или не будет достигнут необходимый уровень безопасности. Безопасность противоположна удобству, защита отстает на шаг от атак. Риск есть всегда и надо просто быть готовым к последствиям и иметь запасной плат хотя бы в общих чертах.

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

Это невозможно, либо отказаться от такой идеи, либо сделать окно вообще без границ и верхней панели (QtCore.Qt.FramelessWindowHint), и сделать свою верхнюю панель.

Нет, рекурсия работать не будет. Гит увидит, что внутри каталога лежит вложенный репозиторий и проигнорирует его. А в своей базе пометит этот подкаталог как поддерево (subtree), чтобы не сломать.

Вы пытаетесь соорудить какой-то жуткий костыль только лишь потому, что поленились изучить инструмент, в котором работаете. Поэтому для вас Git сейчас представляется как некая шайтан-машина, которой вы скармливаете команды, которые не понимаете, и в результате получаете ещё более непонятные «неожиданные результаты». Просто потратьте несколько дней, чтобы изучить азы. Не зубрите непонятные команды, а постарайтесь понять логику гита. А она — эта логика предельно проста и гениальна.

не является сложной задачей что-либо сломать в своем проекте

Сломать что-то в гите довольно сложно. Вам может только показаться что всё сломалось, но это лишь потому, что вы не понимаете, что делаете.

каким-то образом снес половину коммитов

Коммиты в гите — это неизменяемые сущности. Можно лишь создать новые «на замену», но старые не исчезают. Коммиты невозможно удалить без специальных команд очистки мусора.
Вам показалось что коммиты исчезли, но на самом деле они все остались в репозитории, вы просто их не видите в текущей ветке. Но всё легко откатывается назад, используя журнал Reflog.

Поэтому было бы неплохо как-либо сохранять прошлые версии Git репозитория

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

Мой вам совет: Пройдите 16 коротких бесплатных уроков и полу́чите просветление.

Цифр больше 9 в десятичной системе не бывает.
А ваш код выдаёт числа от 1 до 10, как вы в нём и написали.

Быстро изучить просто.
Придумывайте любой проект и начинаете его делать.
И самое главное, вы должны делать это самостоятельно, без всяких тостеров.
Книги вам помогут любые где есть просто базовые знания, а вот всякие ютуб каналы особо не помогут, может только чуть разобраться в фреймворках, но всё равно документация рулит.
Если хотите создавать игры, то копайте движок Unity и его документацию.

Сам процесс простой.
1. Пишите как знаете проект, главное чтобы заработало как планируете, на сам код не обращайте особого внимания.
2. Начинаете переписывать проект с полученным опытом из 1 пункта с использование новых знаний из прочтения книг по всяким архитектурам и паттернам.
3. Повторяете в цикле первые 2 пункта до 11 класса каждый день тратя по 4 часа минимум.

Весь ваш прогресс заносите через git на гитхаб, пригодится, когда будете искать работу.

https://syncthing.net/
на ютубе полно гайдов по его настройке

Я тоже до конца не понимаю цели и задачи которые ставились для winsock2 но вот можно
почитать аннотацию здесь https://learn.microsoft.com/en-us/windows/win32/wi...

С моей точки зрения было время большого разлада между лагерем Microsoft и Unix. И вместо того
чтобы просто позаимстовать сетевые библиотеки или купить лицензии, MS как всегда стал делать
что-то свое, "сумчатое" и ни на что не похожее. Яркий пример Component-Object Model (COM).
Нигде такого нет.

Для чего создаватьtypedef struct addrinfo{}? Только ради того, чтобы не писать struct в Си?

Да все верно. Именно для такого юзкейса typedef и создавался. Плюс еще можно примитивы определять.

Для чего определять *PADDRINFOA

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

Где-то спокойно используется int, а где-то используетсяtypedef unsigned __int64 UINT_PTR, опять же вместо того, чтобы просто писать unsigned __int64.

Это очень старый технический долг языка С++ и его уже нельзя исправить. Дело в том
что спецификация языка не объясняет какой разрядности должен быть int. Он может быть
16, 32 бит в зависимости от целевого железа. По сути он - синоним регистра процессора.
И когда мы делаем цикл от 1 до 10 и нам по сути неважна разрядность параметра цикла - мы просто заказываем
int чтоб долго не думать. И компиллятор собирает очень быстрый и оптимальный код.
sizeof(int), или константы в в limits.h могут дать подсказку по вашей текущей архитектуре.

typedef unsigned __int64 UINT_PTR

Здесь идет форсирование разрядности в 64 бита. Такие потребности возникают
в момент когда у нас есть например жестко заданный формат (сетевой протокол
или дисковый формат файла) и мы должны гарантировать что другие архитектуры
микрокотноллеры, мобилы и прочее правильно смогут интерпретировать эту структуру.
Тут еще и порядок байтов внутри слова тоже важен. В наше время даже есть сет
стандартов на описание таких структур ASN, AVRO, Protobuf, Thrift.