Путь Github. Цикл разработки

Я расскажу о цикле разработки через Github, который я использую. Он был проверен в течении года на командах разного размера: 3 — 14 человек.

Существует 2 основных ветки: master и dev.

• master — стабильная ветка, готовая к выкатыванию на production сервер в любой момент.
• dev — ветка, над которой в данный момент работает команда.

Итак, в начале разработки master и dev ветки идентичны. При дальнейшем чтении следует помнить, что Git - это распределенная система контроля версий. Поэтому, формально, каждая копия репозитария - что на сервере, что у разработчика - является отдельным полноценным репозитерием, которым можно крутить как угодно.

1. Когда программист начинает работу над новым дефектом / функционалом, он должен переключиться на ветку dev и получить ее последнюю версию.

git checkout dev

git pull origin dev

2. К примеру, разработчик хочет начать исправлять дефект страницы аутентификации. Номер ошибки на Github — 1234. Разработчик должен создать новую ветку из dev:

git checkout -b 1234-bug-login

Название новой ветки 1234-bug-login - это только пример. У нас в компании первым словом должен быть номер дефекта, вторым — bug / feature, а дальше — описание проблемы.

3. Далее разработчик продолжает работу локально: делает изменения, коммиты и т.д., но не делает команду push. Commit-cообщения должны содержать номер ошибки и техническое описание

git add ...list of files...

git commit -m "#1234 changing backbone model url"

4. Итак, разработка окончена, и теперь необходимо отправить изменения на Github (через команду push):

git push origin 1234-bug-login

Эта команда перекинет в репозитерий на Github ветку с именем 1234-bug-login. Все изменения теперь в репозитории на Github. После этого разработчику необходимо обновить свою ветку из dev, чтобы иметь возможность слить ее без конфликтов (ведь пока он разрабатывал свои изменения, другие разработчики могли успеть внести изменения в ветку dev).

Сперва необходимо получить последнюю версию ветки dev:

git checkout dev

git pull origin dev

И затем нужно влить все изменения, которые произошли в dev ветке, в свою ветку (1234-bug-login):

git checkout 1234-bug-login

git rebase dev

После чего надо разрешить все конфликты, если они возникли, закоммитить изменения. А затем нужно снова залить на GitHub ветку 1234-bug-login, в которой произошло "слияние" ветки dev и 1234-bug-login:

git push -f origin 1234-bug-login

5. Отлично! Ветка с решенными конфликтами в репозитории. Но пока что все изменения находятся в отдельной ветке и не включены в ветку dev. Для того, чтобы поместить изменения в ветку dev, разработчик делает Сreate Pull Request из 1234-bug-login в dev ветку при помощи Github. Так же необходимо разместить ссылку на задачу (#1234) в описании Pull Request.

6. Pull Request отправлен, любой разработчик может сделать code review, написать комментарии, уточнения и т.д. Исправления кода, согласно комментариям должны быть отправлены на Github обычным способом (вот тут неясно, что значит "обычный способ"). Pull Request обновится автоматически.

7. Иногда, исправления занимают некоторое время, и другие разработчики уже слили свои ветки с dev. В этом случае есть 2 варианта:

• кнопка Merge pull request на Github активна. Это означает, что изменения других разработчиков не конфликтуют с текущими изменениями, и ничего дополнительного делать не требуется.
• кнопка Merge pull request неактивна. Необходимо вернуться к пункту 4) и заново слить и отправить изменения из dev ветки в 1234-bug-login.

git checkout dev

git pull origin dev

git checkout 1234-bug-login

git rebase dev

git push -f origin 1234-bug-login

8. Отлично! Все изменения сделаны, и кто-то написал комментарий «merge it» в Pull Request. Пора нажимать кнопку Merge pull request, чтобы влить изменения 1234-bug-login в ветку dev.

Тестирование

9. Как только 1234-bug-login попадает в dev, Jenkins (система непрерывной интеграции, используемая в нашей компании) автоматически обновляет dev-сервер из ветки dev. QA могут начинать тестировать и как итог подтвердить или переоткрыть задачу.

10. Если Pull Request вносит много изменений, разработчик может при помощи Jenkins загрузить свою ветку на qa-сервер для проверки тестерами.

Релиз

11. Перед обновлением production сервера необходимо влить ветку dev в ветку master. Для этого мы создаем Pull Request из dev в master при помощи Github и нажимаем Merge pull request, вот и все. При выполнении предыдущих пунктов, никаких конфликтов быть не должно.

12. Если регрессионное тестирование успешно закончено, можно обновлять production сервер, при этом берется последний пакет (тот, на котором проходило тестирование), и именно он устанавливается на production сервер.

13. Иногда QA находят ошибки во время регрессионного тестирования. В этом случае исправления выполняются по стандартной схеме, за исключением того, что ветка создается и сливается не из dev, а из master. После релиза необходимо влить исправления из master в dev.

git checkout master

git pull origin master

git checkout dev

git pull origin dev

git merge master

git push origin dev