-
-
Notifications
You must be signed in to change notification settings - Fork 62
Development process (RU)
это скорее памятка по работе с git, чем полное руководство по процессу разработки
В связи с использованием git, предлагается использовать и рекомендуемый ими подход разработки. (Здесь есть хорошее описание: http://nvie.com/posts/a-successful-git-branching-model/)
Есть две основных ветки в репозитории:
- release - стабильная ветка (коммиты делают только разработчики, когда выпускают релиз)
- master - разрабатываем следующую версию (коммиты делают разработчики и сюда принимаются pull request-ы от других людей)
Помимо этих основных веток будут временные ветки следующих типов:
- Feature - фичи, задачи, баги
- Release - релизная ветка, на ней тестируем и проверяем, что всё работает, сюда заливаются срочные правки перед релизом
- Hotfix - если после релиза нашёлся критический баг
Рассмотрим эти ветки по отдельности.
- Делается с ветки:
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
Вот собственно и всё новая фича попала в основную ветку разработки.
- Делается с ветки:
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'.
- Делается с ветки:
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/