Подскажите как можно выкрутиться, или каку методологию работы с гитом

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

Ваши ограничения выглядят неразумными. Но в их рамках я бы выкинул ветку dev.

А зачем бот пушит что-то в main...? Что он делает 0_о

Ну тут суть не в дев ветке, а в том что мейн очень часто обновляется, может есть какие-то возможности по CI/CD, для авторазрешения конфликтов и тд?

Ну, если вкратце, то бот от shopify, и если заказчик чет меняет в визуальном редакторе, то это пихается в мейн, а меняет он часто)

Смотрите, типичная ситуация: есть ветка типа dev, от которой разработчики отпочковывают свои ветки для фич. К моменту завершения работы над фичей dev запросто может уйти вперед, это нормально. Обычно разработчик просто рибейсится периодически от основной ветки или подмерживает ее к себе, чтоб возможные конфликты решать по ходу и порционно, а не в самом конце один раз огромной кучей. Если же конфликты очень болючие, то начинают разбираться именно что в причинах.

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

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

Там уже ограничения по платформам

А какого рода конфликты? Если в них нужно тупо принять одну сторону, то для этого есть флаги. Вопрос в том, будет ли у вас работать проект после такого машинного разрешения конфликтов

Конфликты рода, кнопка влево на три пикселя, цвет чуть зеленее, и тд, в основном

Как это в коде выглядит? Конфликт возникает, когда в одном месте была сделана одна правка, а в другом месте другая правка.

Это json, один разраб менял струтуру жсона, а второй цвет кнопки в нем условно. Но тут желательно бы уточнить детальнее, да

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

Чуть вдался в детали, типичные комиты фронта, html блок передвинут, описание поменялось, цвет другой

Это малозначимая информация. Куда важнее, тем визуальным редактором пользуются как раз несколько людей в разных местах, раз конфликты появляются? Или кто-то пользуется визуальным редактором, а кто-то вручную правит еще файлы?

Один человек визуалкой, и несколько раз в день, и команда работает на полноценных правках

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

Да в этом все и дело, люди вообще без гита сиделиЮ буквально неделю назад подрубили)