Skip to content

Development process (RU)

Dmitrii Sukhomlinov edited this page Mar 22, 2021 · 10 revisions

Работа с git в UGENE

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

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

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

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

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

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

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

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

Feature

  • Делается с ветки: master
  • Должна влиться в ветку: master
  • Называться ветка должна: хоть как, кроме release, master, 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
  • Должна влиться в ветки: master и release
  • Называться ветка должна: release-*

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

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

git checkout -b release-1.22.0 master

Из файла src/ugene_version.pri удаляем постфикс -dev - если этого не сделать, то некоторые скрипты могут работать некорректно.

Скачиваем предыдущую версию с ugene.net и запоминаем версию текущего дистрибутива. Если нужно то меняем версию в исходном коде (ugene_version.pri) и коммитим изменения:

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

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

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

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

Идем на страницу ugene в GitHub и создаем Pull Request по вливанию ветки release-0.2 в ветку master. Дождитесь approve от codeowner'ов. Слейте ветки, удалите ветку release-0.2. Теперь нужно поправить файл src/ugene_vesrions.pri - указатьтам нужную версию и выставить постфикс '-dev'.

Hotfix

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

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

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

git checkout -b hotfix-1.22.1 release

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

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

Так же как и обыным релизом, из файла src/ugene_version.pri удаляем постфикс -dev.

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

git commit -m "Fixed severe production problem"

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

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

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

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

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

git branch -d hotfix-1.22.1

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

git push
git push origin --tags

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