• Что делать, если удалил ветку без удаления коммита?

    romesses
    @romesses
    Backend инженер
    Во-первых, удаление веток, меток и фиксаций (commits) не приводит к сокращению размера репозитория, т.к. git работает только на добавление.
    Во-вторых, если изменения уже синхронизированы на удаленный репозиторий git, тогда с этим нужно просто жить.

    И только если изменения локальны и не выполнен git push, тогда ветку откатить можно до нужной фиксации.

    Допустим, ветка origin/development находится на удаленном репозиторие git, а локально были добавлены 2 фиксации с ненужными изменениями (бинарями dll, допустим). Таким образом, ветка development опережает origin/development на 2 фиксации. Тогда выполняем:
    git reset --hard origin/development

    Добавлено:
    Есть еще деструктивная утилита bfg для удаления данных из истории git:
    https://rtyley.github.io/bfg-repo-cleaner/
    https://www.phase2technology.com/blog/removing-lar...
    Если изменения только локальные, то можно поработать с этой утилитой локально и тогда на удаленный репозиторий git ничего из ненужного не попадет.
    А если уже попали, тогда есть еще более опасная вещь: попытаться перевоссоздать репозиторий локально и перезалить его.
    Ответ написан
    3 комментария
  • Может ли реализация класса зависеть от внешних модулей?

    vabka
    @vabka
    Токсичный шарпист
    Всё верно. Лучше зависимости передавать через конструктор
    Ответ написан
    Комментировать
  • Пример развертывания проектов (CI/CD)?

    @vitaly_il1
    DevOps Consulting
    А вручную вы приложение умеете деплоить? Если да, то запишите по шагам как. Например:
    1) получить код из repository
    2) запустить static code analize
    3) security scanner
    4) unit tests

    И т.д.
    Если все прошло удачно - деплоим
    1) копируем
    2) конфигируем
    3) перегружаем
    4) проверяем

    Когда с этим разберетесь, читаете описания и примеры любой CI/CD и подгоняете под ваш сценарий.
    Ответ написан
    2 комментария
  • Стоит ли читать 2 книги по программированию параллельно?

    @d-sem
    Стоит. Даже более того. Со временем можно прийти к тому что на книжной полке с десяток книг с закладками, которые вначале бегло просматриваются, а потом читаются и перечитываются по мере необходимости. Очень интересно наблюдать профессоров старой школы с большими библиотеками. У них часто именно такой режим чтения: читать, делать пометки, возвращаться снова.

    А каша зависит от индивидуальной организации мышления. Кто-то может, кто-то нет. Из хорошего - это тренируется.
    Ответ написан
    Комментировать
  • Как запустить фоновый процесс Django?

    dimonchik2013
    @dimonchik2013
    non progredi est regredi
    Учу Python/Django и всё, что его сопровождает в веб разрабоке, например Django Rest Framework, Django Channels, PostgreSQL, Redis, Docker...

    добавьте в этот набор Celery
    но в Вашем случае достаточно и cron/systemd/supervisord
    Ответ написан
    2 комментария
  • Наилучшая структура Django-проекта?

    @rodion4dev
    Отвечая на вопрос, увы, таковой нету. Вы должны сами для себя решить и не спустя три месяца.

    Но если желаете более предметно, то вот Вам мои ощущения по поводу Вашей структуры, к которой вы пришли...

    Первое, что бросается в глаза - настройки. Да, Вы следуете идеологии Django, которая неявно шепчет всем нам как их компоновать: но это небезопасно. Почему в настройках у вас модули, два из которых отражает какое-то окружение (разработка, боевое и что-то общее между тем и тем)? Исходя из Вашей структуры сразу витает в воздухе вопрос: "А почему настройки боевого окружения вдруг должны быть в репозитории? А как быть с секретным ключом? А безопасно ли это?". Следующий логичный вопрос удобства: почему я, как разработчик, вдруг должен заставлять своих DevOps'ов компоновать и поддерживать за меня настройки в виде файлов (модулей)? Это ведь исполняемый файл и там бесчисленное количество возможностей; более того, это не безопасно. Сейчас бОльшая часть проектов поднимается средствами docker-compose, куберов и прочих прелестей: дико неудобно собирать и поддерживать настройки в виде файлов для каждого запускаемого контейнера (у нас ведь есть переменные окружения). Надеюсь, здесь понятен основной посыл: безопасность и удобство использования.

    (здесь я не сразу понял, что это именно проект, а не приложение; подробности в комментариях)
    Едем дальше - core. Почему именно такое название? Понятное дело, ядро, Django в своих исходниках делает и всё такое... Но зайдя в такой проект, сразу ли будет понятно за что отвечает это приложение? Нет. В общем-то даже в документации к Django в quick start название приложения опирается на её главную бизнес-потребность.

    Переходим к следующему: папка apps с приложениями. Для начала вроде всё удобно и логично: есть ядро проекта, а есть дополнения к нему а значит их нужно как-то отделить от этого ядра. А что делать если ядро будет всегда одно в проекте? А что делать если дополнительных приложений будет всего одно? А зачем тогда ему целая папка (приложению) если само приложение - и есть папка (или модуль в нашем случае)? Так оставлять или менять уровень вложенности? На самом деле что core, что appN - являются такими же Django приложениями (одинаковыми), а значит и уровень абстракции у них - один; один уровень абстракции говорит нам о том, что и appN нужно класть где-то рядом с core (здесь должно быть другое название как и писал). Часто я вижу в проектах, что core так и остаётся одой единственной core папкой без дальнейшей расширяемости. Вывод - преждевременная оптимизация - вещь нелогичная по сути своей.

    Папка template. Здесь я всегда доверяюсь Django и кладу шаблоны в папку приложения (делая ещё две папки - templates, а в ней - папку с названием приложения). Здесь, думаю, подойдёт правило класть то, что используется, ближе к тому месту, где это используется (но с поправкой на рекоммендации оф. документации Django).

    Папка static. В среде отладки её быть в принципе быть не должно; обычно вся статика всегда в первую очередь связана с приложением, куда мы её и стараемся класть (как с папкой templates), что является и советом из Django документации.

    Папка models. Вынося её куда-то в отличное от папки приложения место, мы сразу же забиваем на автономность самого приложения; приложение сразу же становится зависимым от внешнего кода (чего нужно избегать). Обычно каждое приложение имеет свои модели и не зависит от моделей другого приложения.

    venv. Актуально только на компьютере каждого разработчика; по-моему это неудачное решение класть платформо-зависимые файлы под контроль версий.
    Ответ написан
    5 комментариев