git
DESCRIPTION
Git for dummies and git flow.TRANSCRIPT
GIT IS YOUR FRIEND
ЧТО ТАКОЕ VCS?
Совсем для начинающих:
• Что такое системы управления версиями?
• Зачем они нужны?
• Как с ними работают?
ТЕРМИНОЛОГИЯ• Репозиторий (repository);
• Рабочая копия (working copy);
• Ветка (branch);
• Набор изменений (changeset);
• «Голова» (head);
• Слияние (merge);
• Конфликт (conflict);
• Фиксация (commit);
• Перенос точки ветвления (rebase);
• Откладывание изменений (shelving);
• Ревизия (revision);
• Тег (tag);
• Синхронизация (sync).
SERVER OR NOT• Централизованные системы управления версиями;
• Сильные и слабые стороны;
• Децентрализованные системы управления версиями;
• Сильные и слабые стороны;
• Чем выделяется Git, и почему он так хорош?
ОСОБЕННОСТИ GIT• Git репозитории;
• Децентрализация;
• Git не о файлах, Git о патчах;
• Git не о копиях репозитория, Git о ветках;
• Кунг-фу Git, сильнее других.
ПРЕИМУЩЕСТВА• Высокая производительность;
• Средства интеграции;
• Продуманная система команд;
• Качественный веб-интерфейс из коробки;
• Легкость настройки любой конфигурации и встраивания в рабочий процесс.
НЕДОСТАТКИ• Плохая переносимость не на Unix системы;
• Не отслеживает каталоги;
• У некоторых возникают проблемы с переносом файлов;
• Плохо работает с большими объемами бинарных данных;
• Многие просто не осилили (=
GIT EVERYDAYБАЗОВЫЕ КОМАНДЫ• init;
• branch;
• log;
• checkout;
• add и rm;
• diff;
• commit;
• reset;
• merge;
• rebase;
• tag.
GIT EVERYDAYДЛЯ КОМАНДЫ• clone;
• pull и fetch;
• push;
• format-patch;
• am;
• pull;
• revert.
GIT FLOW• A successful Git branching model;
• Была предложена Vincent Driessen;
• Проверена автором:
• использовалась модель в рабочих проектах;• использовалась в рабочих проектах.
Данная модель позволяет максимально эффективно использовать возможности Git при разработке программного обеспечения, а также организовать на основе этой модели правильную модель релизов и выкатки на production.
ВЗГЛЯД СВЕРХУ
ПОЧЕМУ GIT?• CVS/SVN консервативны;
• Управление ветками – одна из сложнейших задач на крупных проектах под управлением CVS/SVN;
• Git базируется на идее активного использования веток;
• Представленная модель не панацея и не открытие. Она просто работает, и может работать у многих.
• Нашли свое лучшее решение? Используйте его.
GIT ЦЕНТРАЛИЗАЦИЯ• Централизация условна;
• Команда сама принимает соглашение по поводу централизации и работы;
• Каждый разработчик может обмениваться в двустороннем порядке с центральным репозиторием;
• Каждый разработчик может обмениваться в двустороннем порядке с репозиториями других разработчиков, в обход центрального.
ГЛАВНЫЕ ВЕТКИ• Две центральные ветки:
• master;• develop.
• Святая святых:
• origin/master;• origin/develop.
• HEAD origin/master:
• production ready;• только релизы.
• HEAD origin/develop:
• integration branch;• ночные сборки.
ДОПОЛНИТЕЛЬНЫЕ ВЕТКИ• Три типа дополнительных веток:
• feature;• release;• hotfix.
• Каждая ветка для своих задач.
• Специальные – не технически, а логически.
• Используйте соглашения внутри команды.
FEATURE ВЕТКИ• Наследуются только от
develop;
• Сливаются обратно только в develop;
• Имя ветки может быть любым, кроме master, develop, release-*, hotfix-*;
• Рекомендую именовать:
• feature-name;• feature-task-number.
• Не сливать в origin;
• Только в локальных репозиториях.
FEATURE LIFE CYCLEСоздание ветки:
$ git checkout -b myfeature develop
Switched to a new branch "myfeature»
Конец жизненного цикла ветки:
$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff myfeature
Updating ea1b82a..05e9557
(Summary of changes)
$ git branch -d myfeature
Deleted branch myfeature (was 05e9557).
$ git push origin develop
FEATURE - DEVELOP
RELEASE ВЕТКИ• Ветвление этих веток может быть произведено только
от develop;
• Эти ветки должны сливаться обратно в develop и в master;
• Имя ветки должно быть формата release-*;
• Предназначены для подготовки релиза продукта;
• Пока не выпущен релиз, весь оставшийся код ждет окончания выпуска релиза;
• Релиз получает номер версии именно при создании этих веток.
RELEASE - СОЗДАНИЕ
Создание release ветки
$ git checkout -b release-1.2 develop
Switched to a new branch "release-1.2"
$ ./bump-version.sh 1.2
Files modified successfully, version bumped to 1.2.
$ git commit -a -m "Bumped version number to 1.2"
[release-1.2 74d9424] Bumped version number to 1.2
1 files changed, 1 insertions(+), 1 deletions(-)
RELEASE ЧТО ДЕЛАТЬ?• Обновление версии во всем исходном коде, где она
есть;
• Тщательно проверяется исходный код, проводится тестирование, исправляются недочеты;
• Никакого нового функционала не добавлять (!).
RELEASE - ЗАКРЫТИЕ
Закрытие ветки идет в три этапа:
• Выпуск релиза;
• Изменения из ветки возвращаются в develop ветку;
• Удаление ветки.
RELEASE – ЗАКРЫТИЕШАГ ПЕРВЫЙ
Производится выпуск релиза
$ git checkout master
Switched to branch 'master'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2
RELEASE – ЗАКРЫТИЕШАГ ВТОРОЙ
Возвращение изменения обратно в develop
$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)
RELEASE – ЗАКРЫТИЕШАГ ТРЕТИЙ
Удаление ветки
$ git branch -d release-1.2
Deleted branch release-1.2 (was ff452fe).
HOTFIX ВЕТКИ• Ветвление этих веток
может быть произведено только от master;
• Эти ветки должны объединяться обратно c master и develop;
• Имя ветки должно быть формата hotfix-*;
• Это те же release-ветки, только для выпуска незапланированных релизов (bugfix релизов);
HOTFIX - СОЗДАНИЕ
Ветка создается ветвлением от ветки master
$ git checkout -b hotfix-1.2.1 master
Switched to a new branch "hotfix-1.2.1"
$ ./bump-version.sh 1.2.1
Files modified successfully, version bumped to 1.2.1.
$ git commit -a -m "Bumped version number to 1.2.1"
[hotfix-1.2.1 41e61bb] Bumped version number to 1.2.1
1 files changed, 1 insertions(+), 1 deletions(-)
HOTFIX – ЗАКРЫТИЕШАГ ПЕРВЫЙ
Производятся нужные изменения для исправления ошибки
$ git commit -m "Fixed severe production problem"
[hotfix-1.2.1 abbe5d6] Fixed severe production problem
5 files changed, 32 insertions(+), 17 deletions(-)
HOTFIX – ЗАКРЫТИЕШАГ ВТОРОЙ
Слив изменений в master и обновление тега
$ git checkout master
Switched to branch 'master'
$ git merge --no-ff hotfix-1.2.1
Merge made by recursive.
(Summary of changes)
$ git tag -a 1.2.1
HOTFIX – ЗАКРЫТИЕШАГ ТРЕТИЙ
Занесение изменений в develop ветку
$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff hotfix-1.2.1
Merge made by recursive.
(Summary of changes)
HOTFIX – ЗАКРЫТИЕШАГ ЧЕТВЕРТЫЙ
Удаление ветки
$ git branch -d hotfix-1.2.1
Deleted branch hotfix-1.2.1 (was abbe5d6).
АВТОМАТИЗАЦИЯ• Методика уже автоматизирована.
• Существует готовый набор скриптов: https://github.com/nvie/gitflow
ИСПОЛЬЗОВАНИЕ• git flow init [-d] (-d применяет дефолтные настройки);
• git flow feature
• git flow feature start <name> [<base>]
• git flow feature finish <name>
• git flow feature publish <name>
• git flow feature pull <remote> <name>
• git flow release
• git flow release start <release> [<base>]
• git flow release finish <release>
• git flow hotfix
• git flow hotfix start <release> [<base>]
• git flow hotfix finish <release>
• git flow support
• git flow support start <release> <base>
GIT FLOW И DEPLOY• На production сервер выкатываются версии только из
origin/master;
• На staging сервер выкатываются версии только из origin/develop;
• Для автоматизации выкатки можно использовать git hooks.
ВОПРОСЫ?
ВСЕМ СПАСИБО ЗА ВНИМАНИЕ (=