Git

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.


$ git tag -a 1.2

RELEASE – ЗАКРЫТИЕШАГ ВТОРОЙ

Возвращение изменения обратно в develop



$ git merge --no-ff release-1.2



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


HOTFIX – ЗАКРЫТИЕШАГ ПЕРВЫЙ

Производятся нужные изменения для исправления ошибки

$ git commit -m "Fixed severe production problem"

[hotfix-1.2.1 abbe5d6] Fixed severe production problem


HOTFIX – ЗАКРЫТИЕШАГ ВТОРОЙ

Слив изменений в master и обновление тега

$ git checkout master

Switched to branch 'master'

$ git merge --no-ff hotfix-1.2.1



$ git tag -a 1.2.1

HOTFIX – ЗАКРЫТИЕШАГ ТРЕТИЙ

Занесение изменений в develop ветку



$ git merge --no-ff hotfix-1.2.1



HOTFIX – ЗАКРЫТИЕШАГ ЧЕТВЕРТЫЙ

Удаление ветки

$ git branch -d hotfix-1.2.1

Deleted branch hotfix-1.2.1 (was abbe5d6).

АВТОМАТИЗАЦИЯ• Методика уже автоматизирована.

• Существует готовый набор скриптов: https://github.com/nvie/gitflow

https://github.com/nvie/gitflow

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.

ВОПРОСЫ?

ВСЕМ СПАСИБО ЗА ВНИМАНИЕ (=

Git

Technology

Transcript of Git