VBO Wiki

Use case and examples

5 min read

RU | EN | DE

Сценарий использования

1. Задачи в системе

В Jira или GitHub Projects создаются задачи:

  • TASK-101: Реализовать логин
  • TASK-102: Добавить оплату
  • TASK-103: Исправить валидацию email Каждая задача имеет ID (например, TASK-101), название, описание, критерии приёмки.

2. Создание ветки под задачу

Когда разработчик берёт задачу, он создаёт ветку с этим ID:

# Программист №1 (логин)
git checkout -b feature/TASK-101-login
# Программист №2 (оплата)
git checkout -b feature/TASK-102-payments
# Программист №3 (валидация email)
git checkout -b bugfix/TASK-103-email-validation

👉 Название ветки = тип работы + ID задачи + краткое описание.

3. Работа над задачей

Разработчик делает коммиты, где указывает ID задачи в сообщении:

git commit -m "TASK-101: добавлен контроллер логина"
git commit -m "TASK-101: валидация данных пользователя"

Это удобно, потому что:

  • Git история сразу связывается с задачей.
  • В Jira и GitHub коммиты и PR автоматически прикрепляются к задаче.

4. Pull Request / Merge Request

Когда задача сделана:

git push origin feature/TASK-101-login

Открывается Pull Request (PR) в main или develop.
Название PR:

[TASK-101] Реализовать логин

В PR видны:

  • изменения в коде,
  • ссылка на задачу в Jira/GitHub Projects,
  • обсуждение и комментарии команды.

5. Code Review и Merge

  • Другие разработчики проверяют код.
  • Если всё ок — жмут Approve.
  • Ветка вливается в main.

6. Автоматизация (CI/CD)

  • Jira и GitHub автоматически ставят задачу в статус “In Review” или “Done”, когда PR смержен.
  • CI запускает тесты.
  • При успехе — код деплоится.

Визуальная схема (3 разработчика)

main ──●────────────────────●────────────────────●────────────────────────►
        \                    \                    \
 feature/TASK-101-login       \                    \
                               \                    \
                      feature/TASK-102-payments      \
                                                      \
                                            bugfix/TASK-103-email-validation

Каждая задача → своя ветка → свой PR → merge в main.

📌Итог:

  • Каждая задача живёт в своей ветке.
  • Названия веток и коммитов связаны с ID задачи.
  • Jira/GitHub Projects автоматически связывают задачи ↔ ветки ↔ коммиты ↔ PR.
  • История чистая и прозрачная: видно, кто сделал какую задачу и когда.

Примеры

Пример 1: Одна задача одного разработчика в Jira

TASK-101: Реализовать логин Описание: пользователь должен вводить email + пароль, система проверяет данные и пускает в систему.

1. Задача в Jira

В Jira задача создана и назначена на разработчика.Статус: To Do → In Progress.

2. Создание ветки в Git**

Разработчик берёт задачу в работу:

Обновляем локальную main до актуальной версии
git checkout main
git fetch origin
git rebase origin/main
Создаём ветку под задачу
git checkout -b feature/TASK-101-login

Теперь у разработчика своя изолированная ветка.

3. Работа над задачей

Программист пишет код и фиксирует изменения коммитами:

git add src/login_controller.java
git commit -m "TASK-101: добавлен контроллер логина"
git add src/login_service.java
git commit -m "TASK-101: реализована проверка email и пароля"
git add src/tests/login_test.java
git commit -m "TASK-101: добавлены unit-тесты для логина"

👉 Обрати внимание: в каждом сообщении указан TASK-101, чтобы Jira и GitHub могли связать коммит с задачей.

4. Публикация ветки

Когда задача готова:

git push origin feature/TASK-101-login

Теперь ветка появилась на GitHub/GitLab.

5. Создание Pull Request

На GitHub создаётся Pull Request:

  • Ветка: feature/TASK-101-login → в main
  • Заголовок: [TASK-101] Реализовать логин
  • Описание: ссылка на задачу в Jira (https://jira.company.com/browse/TASK-101) PR автоматически привязывается к задаче в Jira.

6. Code Review

  • Другие 2 разработчика смотрят изменения.
  • Оставляют комментарии (например, «вынести метод в отдельный сервис»).
  • Автор дорабатывает код → пушит новые коммиты:
git add src/login_service.java
git commit -m "TASK-101: рефакторинг сервиса логина"
git push origin feature/TASK-101-login

PR обновляется автоматически.

7. Merge

После одобрения (Approve):

  • PR вливается в main (через Squash или Rebase and merge, чтобы история была чистой).
  • CI запускает тесты, билд и деплой.

8. Завершение задачи

  • Jira переводит задачу в статус Done автоматически (по хуку из GitHub).
  • В истории видно: коммиты, PR, кто ревьюил, кто мерджил.

Визуальная схема

main ────●───────────────●─────────────────●───────────────►
          \                                      /
           \                                    /
 feature/TASK-101-login ──●──●──●──●───────────● (merge)
                          (код, тесты, фиксы)

📌 Итог:

  • Jira → хранит задачу (ID, описание, статус).
  • Git → хранит ветку и коммиты.
  • GitHub/GitLab → связывает PR с задачей.
  • CI/CD → проверяет и деплоит код. Каждый шаг прозрачен: сразу видно, какой код относится к какой задаче.

Пример 2:

Задачи в Jira:

  • TASK-101 — логин (Программист №1)
  • TASK-102 — оплата (Программист №2)
  • TASK-103 — баг в email (Программист №3)

1. Каждый создаёт ветку под задачу

# Программист №1
git checkout -b feature/TASK-101-login
# Программист №2
git checkout -b feature/TASK-102-payments
# Программист №3
git checkout -b bugfix/TASK-103-email-validation

2. Каждый делает коммиты локально

Программист №1 (логин):
git commit -m "TASK-101: контроллер логина"
Программист №2 (оплата):
git commit -m "TASK-102: сервис оплаты"
Программист №3 (валидация email):
git commit -m "TASK-103: исправлена валидация email"

3. Каждый пушит свою ветку

git push origin feature/TASK-101-login
git push origin feature/TASK-102-payments
git push origin bugfix/TASK-103-email-validation

Теперь в origin есть три новые ветки.

4. PR (Pull Request)

  • №1 открывает PR [TASK-101] Реализовать логин
  • №2 открывает PR [TASK-102] Добавить оплату
  • №3 открывает PR [TASK-103] Фикс email Все PR направлены в main.

5. Code Review и Merge

Представим, что PR идут последовательно.

Первый merge (TASK-101):

main ───A──B──C─────────●──────●──────●──────────────►
         \
          feature/TASK-101-login (merge → ●)

Второй merge (TASK-102):

main ───A──B──C─────────●──────●──────●──────────────►
          \                      /
           feature/TASK-101-login
                          \
                           feature/TASK-102-payments (merge → ●)

Третий merge (TASK-103):

main ───A──B──C─────────●──────●──────●──────────────►
          \                /              /
           feature/TASK-101-login        /
                          \             /
                           feature/TASK-102-payments
                                         \
                             bugfix/TASK-103-email-validation (merge → ●)

6. Что получает команда

  • В main теперь лежит код всех трёх задач.
  • Каждая задача прошла через отдельный PR и code review.
  • Jira автоматически закрыла задачи в статус Done.

Важный момент — конфликты Если два программиста правят один и тот же файл (например, UserService.java):

  • Второй, кто делает merge, получит merge conflict.
  • Решается так:
git fetch origin
git rebase origin/main   # или git merge origin/main

Решаем конфликты

git add .
git rebase --continue
git push origin feature/TASK-102-payments

После этого PR снова готов к слиянию.

7. 📌 Итого:

  • Каждая задача = отдельная ветка = отдельный PR.
  • Ветки живут недолго (1–5 дней).
  • В main попадает только проверенный код.
  • Конфликты решаются до merge.

Backlinks