Версионирование

Каждый рабочий проект должен иметь текущую рабочую версию перед тем как будет предоставлен пользователям.

Текущую версию проекта удобно хранить в отдельном файле, например version.h, version.py и т.п. Это удобно при настройке автоматизаций (CI/CD).

Придерживаемся семантическому версионированию ПО (МАЖОРНАЯ.МИНОРНАЯ.ПАТЧ).

• МАЖОРНУЮ версию, когда сделаны обратно несовместимые изменения API.
• МИНОРНУЮ версию, когда вы добавляете новую функциональность, не нарушая обратной совместимости.
• ПАТЧ-версию, когда вы делаете обратно совместимые исправления.

GIT-репозиторий

Основное

• В main ветке всегда находится РАБОЧАЯ версия проекта. Изменения вносимые в основную ветку не должны ухудшать работу программы (в норме), т.е. все тесты должны быть пройдены, изменения в коде проверены коллегами.
• Основная ветка и все релизные ветки должны иметь флаг protected.
• Над отдельной задачей работает один разработчик, в своей ветке. Вносить изменения в чужие ветки ЗАПРЕЩЕНО! Совместная работа осуществляется ТОЛЬКО через защищённые ветки, с помощью merge request.
• Тэги используются только для пометки релизов (например, v0.1.0).
• В конце рабочего дня, если задача не была завершена, коммитим и грузим изменения на сервер (wip:*).

  Рабочий процесс

• Перед тем как браться за выполнение задачи, нужно завести на неё issue в GitLab, если её ещё там нет, и описать решаемую задачу (проблему). Затем, в созданном issue по задаче необходимо создать новую ветку для работы над задачей (смотри раздел "Наименование веток").
  Созданную таким образом ветку можно найти в терминале с помощью:

  git fetch && git branch -a

• Взяв задачу в работу, необходимо установить ей метку (Lable) = In progress.
• Все предложения по проекту, обсуждения, замечания, баги и прочее предлагается вести в issue.
• При создании запроса на слияние (merge request) необходимо указать минимум одного коллегу в качестве ревьюера.

  Наименование веток

• feature/issue-{ISSUE_ID}-* - новый функционал. Возможен вариант feature/*.
• bugfix/issue-{ISSUE_ID}-* - исправление багов. Возможен вариант bugfix/*.
• docs/issue-{ISSUE_ID}-* - для документации. Возможен вариант docs/*.
• chore/issue-{ISSUE_ID}-* - для прочих задач. Возможен вариант chore/*.

• release/v*.*.* (всегда protected).

  {ISSUE_ID} - это номер после символа # выбранного вами issue (возможно потребуется открыть его на весь экран, чтобы точно его увидеть).

  Именование коммитов

• feat:* - был добавлен или убран исходный код (src). Код не покрыт тестами, либо тесты сломались.
• fix:* - был исправлен баг. Если был добавлен тест воспроизводящий этот баг, то данный коммит должен успешно проходить этот тест.
• refactore:* - был изменён исходный код (src), но в отличие от feat тесты проходят успешно и покрытие кода тестами не уменьшилось.
• perf:* - похоже на refactore, тоже изменён исходный код, но увеличена производительность.
• style:* - похоже на refactore, тоже изменён исходный код, но вместо "реальных" изменений внесены правки в форматировании кода.
• docs:* - внесены изменения в документацию и/или комментарии в коде.
• test:* - изменения в тестах.
• ci:* - изменения связанные с CI.
• build:* - изменения связанные с процессом сборки проекта и его зависимостями.

• chore:* - всё остальное...

  В "своих" ветках рекомендуется делать коммиты типа wip:* (например, wip: daily save, чтобы сохранить прогресс за день. Далее можно переименовать его или откатить.

• Отменить предыдущий коммит, а также отменить отслеживание изменений сделанных в нём (unstage the changes):

  git reset HEAD^ --soft && git reset

• Завершив работу над кодом сделав нужные коммиты, отправить их на сервер можно с помощью:

  git push origin your-branch-name --force

  Именование Merge Request'ов

  Аналогично коммитам.

  Использование меток (Labels)

• Bug - описанная проблема считается багом, требующим решения.
• Hold - задача на паузе (изменились приоритеты, ожидает решения другой задачи и т.п.).
• In Progress - задача взята в работу.
• In Review - задача ожидает проверки/подтверждения.

  Подлежит дополнению.

  Решение конфликтов

  При запросе на слияние возможно возникновение конфликтов (main ветка убежала вперёд). Для решения конфликта предлагается перебазировать вашу ветку на последний коммит main ветки, решить возможные конфликты в своей ветки и затем уже повторно сделать merge request.

• Перебазировать ветку на main можно с помощью:

  git fetch && git checkout your-branch-name && git rebase main

• Разрешите конфликт и продолжите перебазирование:

  git rebase --continue

• Обновите ветку на удалённом репозитории:

  git push --force