Есть много нюансов помимо экспертности.
Рерайтно-копирайтный сайт на одну из естественно-научных тем потерял меньше трафа, чем сайт по языку программирования.
Можно было бы сказать, что рулят правильная вставка картинок и хорошее оформление. Это не умеет ЖПТ.
Однако чтобы траф это оценил, он должен доходить до сайта. Хотя по идее ЖПТ должен его "не пускать", давая ответы.
При анализе ответов ЖПТ там много ляпов в простых вопросах. Каламбур. Видимо траф это все еще способен понять и пока еще идет на сайты читать тру-инфу.
Что касается контента, то его дофига на английском. Если у Яндекса переводчик норм, то русскоязычные сайты ему в принципе не особо нужны. Тырь по всему миру, переводи и воспроизводи через Алису.
В инфошках код бэкенда - это хорошо если 10% от всей разработки.
Для инфо-сайтов "Грамотная архитектура" нелепо звучит. Там ее в принципе не особо. Вот грамотный адаптивный дизайн, продуманная структура сайта и тп. - это реалии.
Я не храню. Но есть CMS, когда разделить проблема.
Все ваши рассуждения говорят о том, что в продакшене у вас ничего. Потому что в реале всегда есть много нюансов. Любой инфо-продукт со временем обвешивается костылями.
Может у вас уровень вопросов таков, что для ответа на них достаточно интеллекта ЖПТ.
Ты точно разраб? Бывает, что в сайты-проекты льют файлы пользователи. И эти файлы надо включить в проект.
Проблему я себе не предумал. Это распространенный мануал - делать баре-репо на серваке. Но только в редких описаниях тебе однозначно дают понять, что гонять ты будешь только в одну сторону. Если проект сложнее двух притопов, делай через гитхаб и не костыли. Это можно понять только самому, ИИ тут только путает.
Нет. Ответ можно вывести либо сильно подумав без ИИ и хорошо зная Git, либо глубоко ковыряться в поиске. Вот чел решает подобную. Ему эксперт дает костыль: qna.habr.com/q/1349358 . По хорошему, если делаешь баре, то нефиг там править. Или не делай баре. Если уж что-то изменилось на сервере, то вытягивай руками (утилитой scp например и коммит делай на локальном).
Нейросеть тупа. Она не различает коммит и правку проекта. Проект править можно. Коммиты делать в баре-репо нельзя. Он только фиксирует их при пушах в него.
А теперь думаем без ИИ. Баре-репо не следит за файлами. Ему неоткуда знать, какой изменился, а какой нет. Поэтому ни пул, ни фетч работать не могут.
Тот факт, что каталог с файлами git не в том же где рабочий проект, тут особо не при делах.
На сервере баре-репо находится в отдельном каталоге. А проект - в другом. Рабочая директория прописывается в хуках. Проект можно править. А вот коммиты сделать нельзя.
Так что это очевидно, что каталог с баре-репо править смысла не имеет.
Нафига мне это полотно с банальными командами.
Если я сделал изменения в bare на серваке, pull на локальном не закачивает. fetch тоже.
Чтобы оно работало, надо делать на серваке обычный репо.
Если я буду пулить на локалку из обычного репо, то пушить на сервак напрямую уже нельзя.
Схема всегда будет сложнее.
Так там и не важно. Главная копия - на локальном. Если грохнется локальный, есть на серваке. Отсутствие у того репо возможности откатывать коммиты, не важно в данном контексте. Гит используется только для быстрого слива файлов из разных подкаталогов. История вообще не важна.
Скрипт можно написать. Но тут задача - не делать лишних телодвижений.
У ЖПТ было спрошено: можно ли выполнить pull с bare-репозитория. Она должна была ответить нет. Но я не уверен на 100%, что нет. Я не спрашивал, как мне сделать pull и как организовывать обмен файлами туда-сюда. Сложных путей несколько. Суть вопроса была - есть ли простое решение. Простого нет. Если надо туда-сюда, то действительно через гитхаб, либо создание веток.
