====== feature branch workflow ======

**Feature Branch Workflow** - это значит, что ''main''/''master''  всегда стабилен, а любая новая задача (фича / фикс / рефакторинг / и тд) разрабатывается в отдельной изолированной ветке.

Вот [[https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow|тут]] достаточно хорошо описано. 

===== Пошаговый процесс (Step-by-Step) =====

==== 1. Создание задачи (Issue) ====

  - Создать Issue с названием задачи (если такоей еще нет)
  - Хотя бы кратко, но лучше подробнее, описать задачу (можно копировать с РМ если там оно полное)
  - Назначить себя на Issue (Assignees)
  - Issue получит уникальный номер в этом репозитории (''#N'' напротив названия), можно запомнить, можно не запоминать (при написании ''#'' в описаниях/комментариях должен работать auto-suggestion)

==== 2. Создание локальной ветки ====

Перед началом создается локальная ветка на основе актуального состояния ''main''.
Название ветки дается в формате: ''<FeatureSubject>[-optional-feature-fescription]'' (например ''Packaging-0.0.1'', ''Packaging-fix-something'').

<code bash>
git checkout main
git pull origin main
git checkout -b <feature branch>
</code>

==== 3. Первый коммит и создание Pull Request (PR) ====

В нашей команде мы создаем PR как можно раньше, часто сразу после первого осмысленного коммита. (чтобы: сразу было видно над чем ведется задача, сразу можно было начать обсуждение по реализации и ссылаться на код из PR, в случае чего заметить что что-то не так с выбранным способом реализации как можно раньше)

Сообщение для коммита дается в формате: ''<CommitSubject> | <required-short-description>'' (например ''Packaging | add deb package build script'', просто ''add <filename>'' лучше не делать, эта информация и так доступна внутри коммита, и новой осмысленной информации не несет) 

Сделать первый коммит:
   <code bash>
   git add .
   git commit -m "<commit message>"
   git push -u origin <feature branch>
   </code>
   
Создать PR (в названии можно просто повторить названии issue).

В описании достаточно написать `Closes #<issue number>` (например `Closes #1`).

Если PR в `main` все остальное Gitea должен сделать сам. А именно: в Issue вместо `No Branch/Tag Specified` должно теперь быть название PR. Если нет, то лучше поставить вручную.

Назначить себя на PR (Assignees) и можно сразу назначить ревьювера (Reviewers).

Опционально, можно пометить PR как Draft (явно дать понять, что не готов к merge в `main`). Видимо на gitea это делается добавлением префикса ''WIP: '' к названию PR.

==== 4. Обсуждение и разработка ====

Теперь:
  - В **Issue** обсуждаем *бизнес-логику* и общие вопросы (что сделать? как можно сделать?).
  - В **PR** обсуждаем *реализацию* (как сделано?).

==== 5. Ревью и слияние (Merge) ====

Когда задача готова:
  - Снять статус Draft.
  - Запросить ревью (поискать кнопку).
  - Если после ревью были запрошены изменения, обсудить, внести и запушить эти изменения, запросить ревью опять. При необходимости повторить.
  - Когда замечаний больше нет и все доработки запушены слить в ''main'' (кнопка ''Create merge commit'').