Skip to content

Workflow

Jump to bottom
Alexander Zuev edited this page Jan 6, 2017 · 5 revisions

Workflow

Введение

Для удобной и продуктивной работы участников вводится Workflow - способ организации работы.

Он построен на системе Issues, Projects и Pull Requests, используемой GitHub.

Issue - задача, требующая решения. Issues доступны на вкладке "Issues" репозитория. Issue может быть Open или Closed. Open - задача требует решения, Closed - задача решена. Для Issue можно назначить Assignee.
Assignee - участник, которому назначена данная задача. Он отвечает за ее выполнение, закрытие, ее статус на вкладке Projects. При решении Issue участник создает Pull Request, в котором добавлены коммиты, решающие задачу.

Pull Request - запрос на слияние изменений с веткой в репозитории. Так же как и Issue может быть Open и Closed в зависимости от того, были ли изменения merged. Для Pull Request также можно назначить Assignee.
Для Pull Request, Assignee - участник, которому нужно проверить Pull Request. Если в качестве Assignee указан сам создатель Pull Request - значит Pull Request требует доработки автора, иначе Pull Request требует проверку другим участником.
Pull Request не используется в качестве карточки на вкладке Projects.

Projects - доска, для организации работы участников.

Содержит списки, соответствующие этапу выполнения задач:

  • Backlog - задачи требующие решения в ближайшее время.
  • TODO - задачи, работа над которыми начнется сразу при наличии времени у участника.
  • In Progress - задачи, работа над которыми ведется в настоящее время.
  • Code Review - задачи, которые ожидают проверки Pull Request другим участником. В качестве Assignee указан участник, выполнявший задачу.

Continuous Integration сервер осуществляет запуск тестов и уведомляет о результате: были ли тесты пройдены успешно или нет. Тесты запускаются автоматически при добавлении новых коммитов или при создании Pull Request-а.

Выбор задачи

Для просмотра списка своих задач нужно зайти на вкладку Issues, выбрать Filter > Everything assigned to you.

view-tasks

Среди них в первую очередь стоит уделить внимание Pull Request-ам.
Если Pull Request-ов нет - можно выбрать любую задачу:

  1. Открыть Issue
    read-task
  2. Прочитать подробное описание задачи (при его наличии).
  3. Перейти в Projects и переместить карточку в In Progress.
    move-in-progress
    Если карточка ранее не была создана, необходимо создать ее:
    add-card-if-not-exist add-card
  4. В git клиенте создать ветку с названием issues/issue-НомерIssue. Номер Issue можно узнать из карточки на вкладке Projects или из Issue: он указан после символа #.
    create-branch
  5. Запушить изменения.
    commit-changes push
  6. Создать Pull Request.
    new-pr title-and-desc
  7. Убедиться в том, что тесты на Continuous Integration сервере пройдены без ошибок.
    tests-pass
  8. Переназначить Pull Request на другого участника.
    assign-pr
  9. Переместить карточку на вкладке Projects в Code Review.
    move-to-code-review

При наличии решенных Issue в Code Review - удалить их карточки.
remove-from-project

При отсутствии задач можно зайти на вкладку Projects, выбрать задачу из списка Backlog, назначить ее на себя и перенести в In Progress или TODO.

Создание Pull Request-ов

Порядок создания:

  1. Нажать кнопку "New Pull Request" на вкладке Code или на вкладке Pull Request.
  2. В качестве ветки compare выбрать свою ветку с изменениями.
  3. Заполнить название в соответствии с Issue, в описании указать ссылку на закрытие Issue: closes #НомерIssue.
  4. Выбрать Assignee: любого другого участника (не себя).
    Если необходимо доработать Pull Request - название начать с [WIP] , в качестве Assignee - указать себя. Такие Pull Request-ы не должны быть приняты до удаления метки [WIP] .
  5. Нажать "Create Pull Request".

Проведение Code Review

  1. Выбрать Pull Request для review.
    click-pr
  2. Проверить наличие ссылки closes #НомерIssue. Перейти к Issue и проверить требования к задаче. При отсутствии ссылки - вернуть Pull Request создателю, указав в Review требование добавить ссылку.
    goto-issue
  3. Перейти к вкладке Files changed и при необходимости прокомментировать изменения. При необходимости изменений после комментария нажать на кнопку Start a review, при простом комментарии - нажать на Add single comment.
    comment-pr
  4. После завершения review, нажать Review changes. Далее Comment - простое комментирование, не влияет на Pull Request; Approve - одобрение изменений, разрешает merge; Request changes - запрос изменений, запрещает merge.
    approve-pr
  5. Если merge разрешен и тесты на Continuous Integration сервере пройдены без ошибок - нажать Merge pull request, Confirm merge, Delete branch.
    merge-pr confirm-merge-pr delete-branch
  6. Если merge запрещен - выбрать создателя в качестве Assignee.

Исправление Pull Request-ов

Если Pull Request был возвращен или тесты на Continuous Integration сервере не пройдены - значит требуется доработка Pull Request-а.
На скриншоте показаны не прошедшие тесты.
tests-failed

  1. Прочитать комментарии к Pull Request-у
  2. Допушить изменения в существующую ветку. Тесты на Continuous Integration сервере запускаются автоматически.
    commit-fix-tests sync
  3. Убедиться в том, что тесты на Continuous Integration сервере пройдены без ошибок.
    tests-pass
  4. Переназначить Pull Request на review.
    assign-pr
Clone this wiki locally