Skip to content

Latest commit

 

History

History
111 lines (96 loc) · 10.4 KB

git.md

File metadata and controls

111 lines (96 loc) · 10.4 KB

Github and Team Workflow

Git Flow

Мы используем переработанный аналог git flow ( оригинал: A successful Git branching model)

Процесс работы над задачами, проведение code review, организация работы в команде, работа с ветками

1. Процесс создания задачи

  1. Задачи создаются в колонке To Do.
  2. Описание задачи должно быть максимально полным и понятным для понимания.
  3. Если задача является продолжением другой, то в описании к ней должна быть ссылка на предыдущую.
  4. Все задачи при создании в колонке To Do не имеют исполнителей. Исполнитель назначается при переносе задачи в колонку In progress.

2. Процесс начала работы над задачей

  1. Найти свободную задачу в колонке To Do. Поиск новых задач необходимо начинать сверху списка.
  2. После того, как задача выбрана, за ней необходимо закрепить исполнителя, т.е. себя.
  3. Перенести задачу в колонку In progress.
  4. Перед созданием ветки для задачи необходимо залить последнюю версию develop ветки.
  5. В своем локальном репозитории необходимо создать ветку для задачи. Формат названия ветки "task number"-"feature name". Пример: 123-important-feature.
  6. Приступить к работе над задачей.

3. В процесс работы над задачей

  1. Во время работы необходимо придерживаться Code Convention принятых в проекте.

  2. Сообщения в коммитах должны быть в формате #123: commit message.

  3. Покрытие тестами, проверка функционала.

    • (Back-End Team) На задачу должны быть обязательно написаны тесты:
      • 100% покрытие unit тестами.
      • Все критические моменты покрываем integration тестами.
      • Все эндпоинты покрываем по возможности integration тестами.
    • (Front-End Team) На задачу должны быть обязательно написаны тесты:
      • Проверка финальной сборки проекта
      • Запуск проекта в комплексе с back-end частью и проверка добавленного функционала

  4. После того, как работа закончена, необходимо залить ветку с задачей на github и сделать pull request в develop ветку.

    • Имя pull request должно быть в формате #123 important feature.
    • Pull request должен быть связан с задачей, это делается добавлением строки connect to #123 в поле с описанием.
    • После создания pull request, Travis CI автоматически запустит сборку проекта. Необходимо проверить, чтобы она прошла удачно. Если сборка не пройдет, необходимо изучить log travis и устранить ошибки. Увидеть, как прошла сборка, можно в github, если открыть pull request. Лог сборки можно посмотреть, кликнув на Details.

  5. После этого необходимо перенести задачу в колонку Needs Review.

  6. Для того, чтобы задача была добавлена в ветку разработки команды, необходимо наличие минимум 1 code review.

  7. Общее время работы над задачей не должно превышать 2 недели. Если разработчик не может решить задачу без объективных причин, необходимо отказаться от ее выполнения и вернуть в колонку To DO.

4. Если не удается решить задачу

  1. Попросить коллег про помощь в общем чате команды.
  2. Если для решения данной задачи нужно решение другой задачи, необходимо в исходном коде оставить комментарий //TODO или @todo c описанием того, что надо сделать и ссылкой на задачу, которая нужна. Если такой задачи нет, ее необходимо добавить в To Do проекта.

5. Если задача заблокирована другой задачей

(в процессе работы над задачей необходим функционал, которого еще нет и нет возможности это легко обойти)

  1. Добавить комментарий к своей задаче blocked with #123. Если эту задачу уже кто-то делает, необходимо связаться с ним и договориться о дальнейших шагах.
  2. Если решение блокирующей задачи затягивается, текущую необходимо вернуть в колонку To Do и вернуться к пункту 2.

6. Проведение review

  1. Делать review может любой желающий в команде.
  2. К review допускаются только задачи, для которых Travis успешно выполнил прогон тестов и собрал проект.
  3. Ревьювер должен придерживаться следующих правил:
    • В начале ревью необходимо начать этот процесс на github. Более подробно в документации.
    • Если замечаний нет, то завершить процесс review с отметкой Approved.
    • Если есть комментарии, оставить их, используя Comment.
    • Если есть существенные замечания, которые должны быть устранены до merge, необходимо оставить Request changes.
    • Статусы Comment и Request changes - не разрешают сделать merge pull request, пока не будет реакции владельца pull request и не будет выставлен статус Approved.
  4. После того, как условие по количеству ревью выполнено, владелец pull request должен уведомить team lead или человека у которого есть права на merge, провести финальное ревью и сделать merge в ветку разработки.
  5. После успешного принятия изменений задача передвигается в колонку Done и ответственный за нее разработчик переходит к пункту 2.
  6. Если в процессе ревью необходимы существенные доработки, задача возвращается в колонку In progress и разработчик переходит к пункту 3. Закрывать при этом pull request не нужно. Все изменения, которые будут попадать в ветку, с которой он был сделан, автоматически будут подтягиваться в pull request.

7. Разное

  1. Если условие задачи непонятно, необходимо запросить дополнительные сведения.
  2. Если задача слишком объемная и ее сложно сделать за 2 недели, необходимо обсудить с team lead пути, как разбить ее на несколько, и сделать эту операцию, используя пункт 1. После этого необходимо выбрать новую задачу, используя пункт 2.
  3. Добавлять изменения без кодревью в основную ветку проекта запрещается.

Линки на tutorial, для самых частых операции при работе с github

Following the GitHub flow
  1. Create a branch from the repository.
  2. Create, edit, rename, move, or delete files.
  3. Send a pull request from your branch with your proposed changes to kick off a discussion.
  4. Make changes on your branch as needed. Your pull request will update automatically.
  5. Merge the pull request once the branch is ready to be merged.
  6. Tidy up your branches using the delete button in the pull request or on the branches page.