Skip to content

Development process (RU)

Jump to bottom
Denis Kandrov edited this page Aug 15, 2016 · 2 revisions

#Работа с git в QSpec

это скорее памятка по работе с git, чем полное руководство по процессу разработки

В связи с использованием git, предлагается использовать и рекомендуемый ими подход разработки. (Здесь есть хорошее описание: http://nvie.com/posts/a-successful-git-branching-model/)

Структура репозитория

Есть три основных ветки в репозитории:

  • release - стабильная ветка (коммиты делают только разработчики, когда выпускают релиз)
  • master - разрабатываем следующую версию (коммиты делают разработчики и сюда принимабтся pull request-ы от других людей)
  • ugene - release + правки, которые относятся к проетку ugene. Проверенные правки добавляются в master (принимаются pull request-ы от разработчиков проекта ugene).

Помимо этих основных веток будут временные ветки следующих типов:

  • Feature - фичи, задачи, баги
  • Release - релизная ветка, на ней тестируем и проверяем, что всё работает, сюда заливаются срочные правки перед релизом
  • Hotfix - если после релиза нашёлся критический баг

Рассмотрим эти ветки по отдельности.

Feature

  • Делается с ветки: master
  • Должна влиться в ветку: master
  • Называться ветка должна: хоть как, кроме master, release, release-*, или hotfix-*

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

Эти ветки живут в основном только на компьютерах разработчиков. Шаги разработки в командах git-а будут выглядеть следующим образом. Сначала создаём свою ветку для новой задачи и переключаемся на неё для работы:

git checkout -b myfeature master

После того как закончили работу над задачей и закоммитили в эту ветку изменения, можно залить решение в ветку разработки:

git checkout master  //переключаемся на ветку разработки
git merge --no-ff myfeature //сливаем свои изменения с веткой разработки
git branch -d myfeature //удаляем ненужную ветку
git push origin master //отправляем изменения на сервер GitHub

Вот собственно и всё новая фича попала в основную ветку разработки.

Release

  • Делается с ветки: master
  • Должна влиться в ветки: mastre и release
  • Называться ветка должна: release-*

Эта ветка создаётся, когда решаем, что можно сделать очередной релиз.

Шаги для такой ветки в командах git-а будут выглядеть следующим образом. Сначала создаём ветку для нового релиза и переключаемся на неё для работы:

git checkout -b release-0.2 master

Меняем версию в исходном коде(у нас пока её нет) и коммитим изменения:

git commit -a -m "Bumped version number to 0.2"

Если нужно проводим ещё дополнительные изменения, после надо залить эти изменения в стабильную ветку:

git checkout release //переключаемся на стабильную ветку
git merge --no-ff release-0.2 //сливаем изменения в стабильную ветку
git tag -a 0.2 //выставляем тег с номером версии
git push origin --tags //заливаем изменения на сервер

Теперь надо залить эти же изменения из релизной ветки в ветку разработки:

git checkout master //переключаемся на ветку разработки
git merge --no-ff release-0.2 //сливаем свои изменения с веткой разработки
git branch -d release-0.2 //удаляем уже ненужную ветку

Hotfix

  • Делается с ветки: release
  • Должна влиться в ветки: master и release
  • Называться ветка должна: hotfix-*

Эта ветка создается, когда найден критический баг и его срочно надо поправить.

Шаги для такой ветки в командах git-а будут выглядеть следующим образом. Сначала создаём ветку для нового релиза и переключаемся на неё для работы:

git checkout -b hotfix-0.2.1 release

Меняем версию в исходном коде и коммитим изменения:

git commit -a -m "Bumped version number to 0.2.1"

Правим баг и коммитим:

git commit -m "Fixed severe production problem"

Заливаем эти изменения в стабильную ветку:

git checkout release
git merge --no-ff hotfix-0.2.1
git tag -a 0.2.1

Заливаем эти исправление в ветку разработки:

git checkout master
git merge --no-ff hotfix-0.2.1

Удаляем ненужную ветку:

git branch -d hotfix-0.2.1

На забываем залить изменения на сервер:

git push
git push origin --tags

Описанное выше - это выжимка из статьи http://nvie.com/posts/a-successful-git-branching-model/

Про ветку ugene

Обновление делается с ветки release после релиза. Изменения должны вливаться в ветку master.

Clone this wiki locally