Git

860 views

Published on

Git for dummies and git flow.

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
860
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
24
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Git

  1. 1. GIT IS YOUR FRIEND
  2. 2. ЧТО ТАКОЕ VCS?Совсем для начинающих:• Что такое системы управления версиями?• Зачем они нужны?• Как с ними работают?
  3. 3. ТЕРМИНОЛОГИЯ• Репозиторий (repository);• Рабочая копия (working copy);• Ветка (branch);• Набор изменений (changeset);• «Голова» (head);• Слияние (merge);• Конфликт (conflict);• Фиксация (commit);• Перенос точки ветвления (rebase);• Откладывание изменений (shelving);• Ревизия (revision);• Тег (tag);• Синхронизация (sync).
  4. 4. SERVER OR NOT• Централизованные системы управления версиями;• Сильные и слабые стороны;• Децентрализованные системы управления версиями;• Сильные и слабые стороны;• Чем выделяется Git, и почему он так хорош?
  5. 5. ОСОБЕННОСТИ GIT• Git репозитории;• Децентрализация;• Git не о файлах, Git о патчах;• Git не о копиях репозитория, Git о ветках;• Кунг-фу Git, сильнее других.
  6. 6. ПРЕИМУЩЕСТВА• Высокая производительность;• Средства интеграции;• Продуманная система команд;• Качественный веб-интерфейс из коробки;• Легкость настройки любой конфигурации и встраивания в рабочий процесс.
  7. 7. НЕДОСТАТКИ• Плохая переносимость не на Unix системы;• Не отслеживает каталоги;• У некоторых возникают проблемы с переносом файлов;• Плохо работает с большими объемами бинарных данных;• Многие просто не осилили (=
  8. 8. GIT EVERYDAYБАЗОВЫЕ КОМАНДЫ• init;• branch;• log;• checkout;• add и rm;• diff;• commit;• reset;• merge;• rebase;• tag.
  9. 9. GIT EVERYDAYДЛЯ КОМАНДЫ• clone;• pull и fetch;• push;• format-patch;• am;• pull;• revert.
  10. 10. GIT FLOW• A successful Git branching model;• Была предложена Vincent Driessen;• Проверена автором: • использовалась модель в рабочих проектах; • использовалась в рабочих проектах.
  11. 11. ВЗГЛЯД СВЕРХУДанная модель позволяетмаксимально эффективноиспользовать возможностиGit при разработкепрограммногообеспечения, а такжеорганизовать на основеэтой модели правильнуюмодель релизов и выкаткина production.
  12. 12. ПОЧЕМУ GIT?• CVS/SVN консервативны;• Управление ветками – одна из сложнейших задач на крупных проектах под управлением CVS/SVN;• Git базируется на идее активного использования веток;• Представленная модель не панацея и не открытие. Она просто работает, и может работать у многих.• Нашли свое лучшее решение? Используйте его.
  13. 13. GIT ЦЕНТРАЛИЗАЦИЯ • Централизация условна; • Команда сама принимает соглашение по поводу централизации и работы; • Каждый разработчик может обмениваться в двустороннем порядке с центральным репозиторием; • Каждый разработчик может обмениваться в двустороннем порядке с репозиториями других разработчиков, в обход центрального.
  14. 14. ГЛАВНЫЕ ВЕТКИ • Две центральные ветки: • master; • develop. • Святая святых: • origin/master; • origin/develop. • HEAD origin/master: • production ready; • только релизы. • HEAD origin/develop: • integration branch; • ночные сборки.
  15. 15. ДОПОЛНИТЕЛЬНЫЕВЕТКИ• Три типа дополнительных веток: • feature; • release; • hotfix.• Каждая ветка для своих задач.• Специальные – не технически, а логически.• Используйте соглашения внутри команды.
  16. 16. FEATURE ВЕТКИ • Наследуются только от develop; • Сливаются обратно только в develop; • Имя ветки может быть любым, кроме master, develop, release-*, hotfix-*; • Рекомендую именовать: • feature-name; • feature-task-number. • Не сливать в origin; • Только в локальных репозиториях.
  17. 17. FEATURELIFE CYCLEСоздание ветки:$ git checkout -b myfeature developSwitched to a new branch "myfeature»Конец жизненного цикла ветки:$ git checkout developSwitched to branch develop$ git merge --no-ff myfeatureUpdating ea1b82a..05e9557(Summary of changes)$ git branch -d myfeatureDeleted branch myfeature (was 05e9557).$ git push origin develop
  18. 18. FEATURE - DEVELOP
  19. 19. RELEASE ВЕТКИ• Ветвление этих веток может быть произведено только от develop;• Эти ветки должны сливаться обратно в develop и в master;• Имя ветки должно быть формата release-*;• Предназначены для подготовки релиза продукта;• Пока не выпущен релиз, весь оставшийся код ждет окончания выпуска релиза;• Релиз получает номер версии именно при создании этих веток.
  20. 20. RELEASE - СОЗДАНИЕСоздание release ветки$ git checkout -b release-1.2 developSwitched to a new branch "release-1.2"$ ./bump-version.sh 1.2Files 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.21 files changed, 1 insertions(+), 1 deletions(-)
  21. 21. RELEASEЧТО ДЕЛАТЬ?• Обновление версии во всем исходном коде, где она есть;• Тщательно проверяется исходный код, проводится тестирование, исправляются недочеты;• Никакого нового функционала не добавлять (!).
  22. 22. RELEASE - ЗАКРЫТИЕЗакрытие ветки идет в три этапа:• Выпуск релиза;• Изменения из ветки возвращаются в develop ветку;• Удаление ветки.
  23. 23. RELEASE – ЗАКРЫТИЕШАГ ПЕРВЫЙПроизводится выпуск релиза$ git checkout masterSwitched to branch master$ git merge --no-ff release-1.2Merge made by recursive.(Summary of changes)$ git tag -a 1.2
  24. 24. RELEASE – ЗАКРЫТИЕШАГ ВТОРОЙВозвращение изменения обратно в develop$ git checkout developSwitched to branch develop$ git merge --no-ff release-1.2Merge made by recursive.(Summary of changes)
  25. 25. RELEASE – ЗАКРЫТИЕШАГ ТРЕТИЙУдаление ветки$ git branch -d release-1.2Deleted branch release-1.2 (was ff452fe).
  26. 26. HOTFIX ВЕТКИ • Ветвление этих веток может быть произведено только от master; • Эти ветки должны объединяться обратно c master и develop; • Имя ветки должно быть формата hotfix-*; • Это те же release-ветки, только для выпуска незапланированных релизов (bugfix релизов);
  27. 27. HOTFIX - СОЗДАНИЕВетка создается ветвлением от ветки master$ git checkout -b hotfix-1.2.1 masterSwitched to a new branch "hotfix-1.2.1"$ ./bump-version.sh 1.2.1Files 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.11 files changed, 1 insertions(+), 1 deletions(-)
  28. 28. HOTFIX – ЗАКРЫТИЕШАГ ПЕРВЫЙПроизводятся нужные изменения для исправления ошибки$ git commit -m "Fixed severe production problem"[hotfix-1.2.1 abbe5d6] Fixed severe productionproblem5 files changed, 32 insertions(+), 17 deletions(-)
  29. 29. HOTFIX – ЗАКРЫТИЕШАГ ВТОРОЙСлив изменений в master и обновление тега$ git checkout masterSwitched to branch master$ git merge --no-ff hotfix-1.2.1Merge made by recursive.(Summary of changes)$ git tag -a 1.2.1
  30. 30. HOTFIX – ЗАКРЫТИЕШАГ ТРЕТИЙЗанесение изменений в develop ветку$ git checkout developSwitched to branch develop$ git merge --no-ff hotfix-1.2.1Merge made by recursive.(Summary of changes)
  31. 31. HOTFIX – ЗАКРЫТИЕШАГ ЧЕТВЕРТЫЙУдаление ветки$ git branch -d hotfix-1.2.1Deleted branch hotfix-1.2.1 (was abbe5d6).
  32. 32. АВТОМАТИЗАЦИЯ• Методика уже автоматизирована.• Существует готовый набор скриптов: https://github.com/nvie/gitflow
  33. 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. 34. GIT FLOW И DEPLOY• На production сервер выкатываются версии только из origin/master;• На staging сервер выкатываются версии только из origin/develop;• Для автоматизации выкатки можно использовать git hooks.
  35. 35. ВОПРОСЫ?ВСЕМ СПАСИБО ЗА ВНИМАНИЕ (=

×