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