Правила работы с git (оформление commit)
Ветки в git:
Обычно работа в гите ведется в нескольких ветках
1) master/main создаваемая по умолчанию
2) develop куда все разработчики мержат свои коммиты
3) дополнительные ветки для каждой части подпроекта
4) дополнительные ветки для багфиксов
т.е. в гите вырастает большая древовидная структура, для упрощения понимания удобно использовать графическое отображение (есть в веб версии gitlab) или в git – клиентах
Правила оформления коммитов:
Для удобства работы настоятельно рекомендуется настроить свое имя и почту (в идеале чтобы ваше имя/ник был уникальным в рамках проекта) и оставлять коммиты в едином стиле подробно они расписаны в [conventional commits] подробнее можно ознакомиться тут https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines
В самом простом варианте:
type: “what happens”
Можно указать номер тикета в системе контроля производства/рабочего времени (bug tracker)
также можно дополнительно указать область где было применено изменение
type(logger): “what happens”
Поле <type> может быть одним из следующих:
- feat: (новая фича для пользователя)
- fix: (исправление ошибки для пользователей, а не исправление скрипта сборки)
- docs: (изменения в документации)
- refactor: (рефакторинг производственного кода, например, переименование переменной)
- perf: (изменение кода с целью повышения производительности)
- chore: (обновление рутинных задач и т. д.; без изменения производственного кода)
- style: (форматирование, отсутствующие точки с запятой и т. д .; без изменения производственного кода)
- build: (Изменения, влияющие на систему сборки или внешние зависимости (make/cmake))
- ci: (Изменения в файлах конфигурации CI и скриптах (примеры областей: Travis, Circle, BrowserStack, SauceLabs))
- test: (добавление недостающих тестов, рефакторинг тестов; без изменения производственного кода)
Система CI/CD continuous integration (CI) and continuous delivery/continuous deployment (CD)
Методология непрерывной интеграции и развертывания
Ситемы git (gitlab/github) позволяют использовать автоматизированную сборку проекта на сервере и прогон по тестам, ниже выскажу пару своих мыслей об этом:
Использование тестов и методология CI/CD — звучит идеально, но:
1-применимо на крупных проектах
2-сильно зависит от момента и качества покрытия тестами (если пишет разработчик кода — результат обычно не очень)
3-если делается в начале проекта — то претерпевает (как правило) много изменений
если делается в конце проекта — то зачастую по п.2