ПРО GIT

МАРТ 2016

НЕМНОГО ТЕОРИИ

GIT

3

• Распределенная система управления версиями

• Локальные репозитории vs удаленные репозитории

• Настройки в текстовых файлах

• Ветки

• Набор утилит командной строки

• Ваша любимая графическая оболочка

• Ваш любимый веб-интерфейс (Gitlab, Stash, …)

ОБЪЕКТЫ GIT

4

• Blob — хранение содержимого файла

• Дерево — хранение списка файлов

• Коммит — хранение состояния файлов

• Тег — метка коммита

ИЗМЕНЕНИЯ, КОММИТЫ, УКАЗАТЕЛИ

5

• Любой снимок доступен по хешу коммита, в котором он был сделан

• Ветка — это просто указатель на верхний коммит в некоторой цепочке коммитов.

• HEAD — хранит указатель на текущую ветку

ТЕГИ

6

• Позволяют фиксировать важные моменты в истории репозитория

• Задавать названия релизов, версии библиотек и т. д.

• Пример: аннотированный тег может содержать release notes релиза, к которому он относится

ЛУЧШИЕ ПРАКТИКИ

КОДРЕВЬЮ: ЗАЧЕМ?

8

• Оценить изменения в ветке-кандидате относительно главной ветки

• Сообщить команде о предстоящих изменениях

• Найти потенциальные ошибки

• Оценить документацию

• Поправить codestyle

ОСМЫСЛЕННЫЕ COMMIT MESSAGES

9

• Отвечают на вопрос «что сделал?»

• Позволяют другим понять, зачем в код были внесены изменения

• Упрощают кодревью

• Помогают написать release notes

• Помогают интегрироваться с багтрекерами

• git commit -m ‘Summary’ -m ‘Description’

MERGE VS REBASE

10

• Задача: объединить изменения одной ветки с другой веткой. Например, влить в локальную ветку изменения из удаленной

• Узкое место: если делать git pull и git push, то при определенных условиях git будет создавать бессмысленные merge-коммиты

• Даже когда вы делаете git pull orgin master, git создаст мерж-коммит, если в удаленном master’е были чужие изменения

• Чем плохо? Загрязняет историю коммитов

• Что делать? Всегда git pull --rebase orgin master

MERGE VS REBASE: СЛИЯНИЕ ВЕТОК

11

• Аналогично: для того, чтобы слить разные ветки вместо git merge feature делаем git rebase feature

• Находясь в фича-ветке, вливаем в нее master: git rebase master

• Находясь в master’е, вливаем фича-ветку: git rebase feature

• После того, как был произведен rebase всех необходимых изменений, можно делать git push.

ИНТЕРАКТИВНЫЙ REBASE

12

• GIT — это не система создания бэкапов!

• Одно из правил хорошего тона — сквош коммитов, которые по одиночке не несут никакого смысла, но вместе представляют собой некоторое осмысленное действие

• Зачем? Проще разруливать конфликты между своей веткой и одним коммитом из другой, чем между своей веткой и пятьюдесятью коммитами

• Что еще? Поменять коммиты местами. Удалить коммиты, как будто их и не было

• Примечание 1. Будьте осторожны, производя rebase в удаленных репозиториях

• Примечание 2. Будьте осторожны при использовании --force

git rebase -i

ХУКИ

13

• Хуки — это скрипты, которые срабатывают при возникновении некоторых событий — commit, push, merge и т. д.

• Локальные (client-side) и удаленные (server-side)

• Как использовать:

• автопроверки (формат commit-message, codestyle и другие соглашения)

• оповещение внешних систем (коммент в багтрекере, запуск автотестов и т. д.)

.git/hooks

ЧТО ЧИТАТЬ

14

• Git How To: https://githowto.com/ru

• Pro Git: https://git-scm.com/book/ru/v2

• Правила хорошего тона при оформлении коммитов: https://habrahabr.ru/company/Voximplant/blog/276695/

• Как использовать git rebase: https://habrahabr.ru/post/161009/