Git for dummies and git flow.

1. GIT IS YOUR FRIEND

2. ЧТО ТАКОЕ VCS?
Совсем для начинающих:
• Что такое системы управления версиями?
• Зачем они нужны?
• Как с ними работают?

3. ТЕРМИНОЛОГИЯ
• Репозиторий (repository);
• Рабочая копия (working copy);
• Ветка (branch);
• Набор изменений (changeset);
• «Голова» (head);
• Слияние (merge);
• Конфликт (conflict);
• Фиксация (commit);
• Перенос точки ветвления (rebase);
• Откладывание изменений (shelving);
• Ревизия (revision);
• Тег (tag);
• Синхронизация (sync).

4. SERVER OR NOT
• Централизованные системы управления версиями;
• Сильные и слабые стороны;
• Децентрализованные системы управления версиями;
• Сильные и слабые стороны;
• Чем выделяется Git, и почему он так хорош?

5. ОСОБЕННОСТИ GIT
• Git репозитории;
• Децентрализация;
• Git не о файлах, Git о патчах;
• Git не о копиях репозитория, Git о ветках;
• Кунг-фу Git, сильнее других.

6. ПРЕИМУЩЕСТВА
• Высокая производительность;
• Средства интеграции;
• Продуманная система команд;
• Качественный веб-интерфейс из коробки;
• Легкость настройки любой конфигурации и
встраивания в рабочий процесс.

7. НЕДОСТАТКИ
• Плохая переносимость не на Unix системы;
• Не отслеживает каталоги;
• У некоторых возникают проблемы с переносом
файлов;
• Плохо работает с большими объемами бинарных
данных;
• Многие просто не осилили (=

8. GIT EVERYDAY
БАЗОВЫЕ КОМАНДЫ
• init;
• branch;
• log;
• checkout;
• add и rm;
• diff;
• commit;
• reset;
• merge;
• rebase;
• tag.

9. GIT EVERYDAY
ДЛЯ КОМАНДЫ
• clone;
• pull и fetch;
• push;
• format-patch;
• am;
• pull;
• revert.

10. GIT FLOW
• A successful Git branching model;
• Была предложена Vincent Driessen;
• Проверена автором:
• использовалась модель в рабочих проектах;
• использовалась в рабочих проектах.

11. ВЗГЛЯД СВЕРХУ
Данная модель позволяет
максимально эффективно
использовать возможности
Git при разработке
программного
обеспечения, а также
организовать на основе
этой модели правильную
модель релизов и выкатки
на production.

12. ПОЧЕМУ GIT?
• CVS/SVN консервативны;
• Управление ветками – одна из сложнейших задач на
крупных проектах под управлением CVS/SVN;
• Git базируется на идее активного использования веток;
• Представленная модель не панацея и не открытие. Она
просто работает, и может работать у многих.
• Нашли свое лучшее решение? Используйте его.

13. GIT ЦЕНТРАЛИЗАЦИЯ
• Централизация условна;
• Команда сама принимает
соглашение по поводу
централизации и работы;
• Каждый разработчик может
обмениваться в
двустороннем порядке с
центральным
репозиторием;
• Каждый разработчик может
обмениваться в
двустороннем порядке с
репозиториями других
разработчиков, в обход
центрального.

14. ГЛАВНЫЕ ВЕТКИ
• Две центральные ветки:
• master;
• develop.
• Святая святых:
• origin/master;
• origin/develop.
• HEAD origin/master:
• production ready;
• только релизы.
• HEAD origin/develop:
• integration branch;
• ночные сборки.

15. ДОПОЛНИТЕЛЬНЫЕ
ВЕТКИ
• Три типа дополнительных веток:
• feature;
• release;
• hotfix.
• Каждая ветка для своих задач.
• Специальные – не технически, а логически.
• Используйте соглашения внутри команды.

16. FEATURE ВЕТКИ
• Наследуются только от
develop;
• Сливаются обратно только в
develop;
• Имя ветки может быть любым,
кроме master, develop, release-*,
hotfix-*;
• Рекомендую именовать:
• feature-name;
• feature-task-number.
• Не сливать в origin;
• Только в локальных
репозиториях.

17. 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

18. FEATURE - DEVELOP

19. RELEASE ВЕТКИ
• Ветвление этих веток может быть произведено только
от develop;
• Эти ветки должны сливаться обратно в develop и в
master;
• Имя ветки должно быть формата release-*;
• Предназначены для подготовки релиза продукта;
• Пока не выпущен релиз, весь оставшийся код ждет
окончания выпуска релиза;
• Релиз получает номер версии именно при создании
этих веток.

20. 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(-)

21. RELEASE
ЧТО ДЕЛАТЬ?
• Обновление версии во всем исходном коде, где она
есть;
• Тщательно проверяется исходный код, проводится
тестирование, исправляются недочеты;
• Никакого нового функционала не добавлять (!).

22. RELEASE - ЗАКРЫТИЕ
Закрытие ветки идет в три этапа:
• Выпуск релиза;
• Изменения из ветки возвращаются в develop ветку;
• Удаление ветки.

23. 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

24. RELEASE – ЗАКРЫТИЕ
ШАГ ВТОРОЙ
Возвращение изменения обратно в develop
$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff release-1.2
Merge made by recursive.
(Summary of changes)

25. RELEASE – ЗАКРЫТИЕ
ШАГ ТРЕТИЙ
Удаление ветки
$ git branch -d release-1.2
Deleted branch release-1.2 (was ff452fe).

26. HOTFIX ВЕТКИ
• Ветвление этих веток
может быть
произведено только от
master;
• Эти ветки должны
объединяться обратно
c master и develop;
• Имя ветки должно быть
формата hotfix-*;
• Это те же release-ветки,
только для выпуска
незапланированных
релизов (bugfix
релизов);

27. 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(-)

28. HOTFIX – ЗАКРЫТИЕ
ШАГ ПЕРВЫЙ
Производятся нужные изменения для исправления ошибки
$ git commit -m "Fixed severe production problem"
[hotfix-1.2.1 abbe5d6] Fixed severe production
problem
5 files changed, 32 insertions(+), 17 deletions(-)

29. 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

30. HOTFIX – ЗАКРЫТИЕ
ШАГ ТРЕТИЙ
Занесение изменений в develop ветку
$ git checkout develop
Switched to branch 'develop'
$ git merge --no-ff hotfix-1.2.1
Merge made by recursive.
(Summary of changes)

31. HOTFIX – ЗАКРЫТИЕ
ШАГ ЧЕТВЕРТЫЙ
Удаление ветки
$ git branch -d hotfix-1.2.1
Deleted branch hotfix-1.2.1 (was abbe5d6).

32. АВТОМАТИЗАЦИЯ
• Методика уже автоматизирована.
• Существует готовый набор скриптов:
https://github.com/nvie/gitflow

33. ИСПОЛЬЗОВАНИЕ
• 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>

34. GIT FLOW И DEPLOY
• На production сервер выкатываются версии только из
origin/master;
• На staging сервер выкатываются версии только из
origin/develop;
• Для автоматизации выкатки можно использовать git
hooks.

35. ВОПРОСЫ?
ВСЕМ СПАСИБО ЗА ВНИМАНИЕ (=